Tom's computer pages

April 21, 2024

EBAZ4205 Bitcoin miner board - "cgminer" software (part 3)

So, now that I have taken a quick look at the cgminer software, I have an idea. I want to replace the chpasswd program with a shell script that looks like this:

#!/bin/sh

while read dog ; do
    echo " -- Tucson chpass: " $dog
done

echo " -- Tucson chpass: DONE"
exit 0

I just use "Tucson" in my messages so that I can find them easily in all the chatter that ensues when I start cgminer.

First I want to replace it in /bin, so I do:

cd /bin
mv chpasswd chpasswdXX
cp /home/root/chp chpasswd
chmod a+x chpasswd

And if you remember what we did in part 2, we how have a "miner" directory with the cgminer tarball expanded. Lets make some adjustments to it.

cd /home/root/miner
mv chpasswd chpasswdXX
cp /bin/chpasswd .
rm -rf zyp

I get rid of the "zyp" directory as it is contained in the HKDW.tar.gz tarball and gets expanded from there every time the miner starts up.
Now I do this:

cd /opt/work0
mv btc_upgrade.tar.gz xyz_upgrade.tar.gz
cd /home/root/miner
tar czvf /opt/work0/btc_upgrade.tar.gz .

And now we are ready to go.

cd /etc/rcS.d
./K95cgminer.sh

Yes, I am running the K95 script to start cgminer. It doesn't know any better and doesn't care whether it is named K95cgminer.sh like it is now, or whether it is named S95cgminer.sh like it would be on a system from the factory.

In the midst of all the chatter that follows, I see:

 -- Tucson chpass:  root:e2893c3b
 -- Tucson chpass: DONE

Aha! Here we have the answer to the great mystery; the root password that is embedded within the cgminer code.

now that the miner code is running it has reconfigured the IP address ( to 192.168.36.97 ), so I cannot ping it or try using ssh. To get the system back under my control, I do this:

cd /etc/rcS.d
rm S95cgminer.sh
reboot

And indeed, my system boots up now without the root password being changed, and with my static IP as I wish. So I am back to where I was before this experiment. But we have accomplished two things:

We have replaced the chpasswd program
We have learned what the cgminer root password is

Changing the chpasswd program within the miner tarball accomplishes our goal of being able to run the miner without having the root password getting reset every time. Note that if for whatever reason your system uses the tarball in /opt/work1, you would need to change it instead (or go through the trouble of changing it in both /opt/work0 and /opt/work1).

I have no idea if the password "e2893c3b" is what is used on every Ebaz board. Someday I will power up another board and find out.

Also note that I have serveral extra copies of the miner tarball using up valuable "disk space". I could clean that up.

Disk space

We have a 128 Mbyte Nand flash. 64M is allocated for our root drive, of which about half (32M) is used by the system. We could delete all of the miner files and recover a significant amount of space (and I will do that someday).

But we are only using half (64M) of our 128M flash drive for the root filesystem. There is another 64M "going to waste". Here is the diagram of how the nand "chunks" are laid out.

mtd0: 00300000 3M   "nand-fsbl-uboot"
mtd1: 00500000 5M   "nand-linux"
mtd2: 00020000 128K "nand-device-tree"
mtd3: 00a00000 10M  "nand-rootfs"
mtd4: 01000000 16M  "nand-jffs2"
mtd5: 00800000 8M   "nand-bitstream"
mtd6: 04000000 64M  "nand-allrootfs"
mtd7: 013e0000 20M- "nand-release"
mtd8: 00200000 2M   "nand-reserve"

We certainly need to leave mtd0 (u-boot), mtd1 (linux), and mtd5 (bitstream) alone. I see no reason why we could not build filesystems on these three, mount them, and gain an extra 46M of space:

mtd3: 00a00000 10M  "nand-rootfs"
mtd4: 01000000 16M  "nand-jffs2"
mtd7: 013e0000 20M- "nand-release"

Likewise for the last (mtd8), but it is only 2M and hardly worth bothering with.
I can do this:

mount -t jffs2 /dev/mtdblock4 /mnt
mount -t vfat /dev/mtdblock3 /mnt

This gets us an extra 16M.

I have tried mounting "chunk" 3 and 7 with type jffs2 and vfat, but it does not work. Also, sad to say, the mkfs.jffs2 utility is not available on the ebaz. And lastly, the nand "partition scheme" is (as far as I know) compiled into the mtd driver. Maybe not. I see "/usr/sbin/mtdpart". I can type "mtdpart -help" and it says it will add or remove a partition from an MTD device. There is also mtd_debug.

I search my desktop linux system using "locate mkfs.jffs2" and find several copies of it from among other projects. It may be available via Petalinux. The whole business of importing executables into the Ebaz is a topic for another page.

NAND memory and JTAG

A curious person should be asking: "how do they put the system on these Ebaz boards at the factory?". My bet is that the NAND chip can be accessed via JTAG and that is how they do things. Of course we can use JTAG as well as they can to both read and write NAND (if this be the case) -- I have notes on JTAG elsewhere, and that is a topic for a whole 'nuther page and another time.

Feedback? Questions? Drop me a line!

Tom's Computer Info / tom@mmto.org