November 20, 2024

Antminer S9 board - round 3 - unexpected surprises

In the last episode, I found I could create a bootable SD card by partitioning it, creating a vfat32 filesystem on the first partition, and copying boot.bin into it.

I then put this freshly minted disk into the slot on my "board C" Antminer S9 and was surprised that it used my custom U-boot setup to network boot Kyu (or bare metal demos).

I figured that this config was somehow inside of boot.bin (which I obtained by copying it from the one bootable SD card I had at the time). But I tracked down the original boot.bin, used linux "cmp" to compare the files and was shocked that they compared OK.

More experiments

I drag out another Antminer board (my board "D"). This board with no SD card installed, boots linux just fine, and I have done the trick to get into it and clear the root password. I boot it up and verify that this is so.

Now I insert the 32G SD card I just did nothing but put boot.bin onto in the board, move jumper JP4 to the left so it will boot from SD and see what that does. It tries to boot from SD, but of course fails because there is no uImage file. No surprise there. It drops me into the U-boot "shell". I use printenv to examine the variables, and it lacks things like "bootkyu" that I added.

I am going to avoid "saveenv" which I know will brick the board. I type this: 

setenv zapadillo xyz
I used printenv to verify that it is now in the environment (and using a name beginning with "z" puts it at the end where I can easy check it. Now I cycle power. That variable does not persist. Remember that it would persist when I did this on my C board.

Analysis and theorizing

My guess is this. I did do a saveenv once, long ago on my C board and this saved the env to NAND (and bricked the board in the process). Apparently U-boot looks at a fixed offset in NAND and does something to decide if what is there is env info or not. If it is, it pulls it in without making any noise about it. (I wonder if it also looks for uEnv.txt in the vfat.)

Also apparently it remembers that it is working with env info from NAND and when I do a "setenv", it makes the change to the saved info. (But for some weird reason, if you do a U-boot reset you don't get that info).

Experiments with Board "C"

I am putting board D away before I do something stupid and brick it. It network boots Kyu right now unless I am alert and stop it. I can type R in Kyu, and it reboots so I can then pay attention and get into U-boot.

I try the same business with "zapadillo". I can set it, but if I do a U-boot reset, it goes away. If I set it, then type "boot" to boot to Kyu, then type R, it is also gone. The only way to get it to stick is to set it, then pull the power cord. Very strange, but handy. And now I can't even get that to work.

Conclusions

I should count myself lucky to have once been able to create a board that will network boot for me.

Another experiment

I dig up my original SD card that does network boot and add this command in a new file uEnv.txt in the fat partition: 
setenv zznew xyz
This new variable does not appear in the U-Boot environment, but when I type: 
run sdboot
It does tell me: 
reading uEnv.txt
17 bytes read in 8 ms (2 KiB/s)
Loaded environment from uEnv.txt
Importing environment from SD ...
But after this, printenv does not show me zznew in the environment. I add some echo commands, but I see no output from them when I "run sdboot". My idea about this file may be all wrong. I see an example online and it just has value settings like: 
zznew=xyz
zznew2=xyz
I don't see these settings on startup, but after I try "run sdboot" they do appear in printenv output -- well this is progress of a sort

Get to the kernel

I can use "run nandboot" to launch linux that is on the board itself. My original interest in all of this was to get linux on an SD card, then use dd to copy the first part of NAND memory and then find out where the U-boot environment had stomped on things -- then examine a healthy board and extract what is needed to put things back. dd could be used to do all of this.

But I don't want to do this just yet. That stomped on environment holds the setup to do network booting. What would be good to work on would be to build U-boot from source, then generate a boot.bin without the nasty bug that stomps on NAND. What would really be nice would be to save the environment in a file on vfat like uEnv.txt!

Copy a NAND image

There are 3 mtd device in /dev (mtd0, mtd1, mtd2) with sizes 32M, 144m, 80M. I find out the sizes via: 
dd if=/dev/mtd0 of=/dev/null bs=1M
I make a copy of the first: 
dd if=/dev/mtd0 of=/nand.img bs=1M
32+0 records in
32+0 records out
33554432 bytes (32.0MB) copied, 3.876648 seconds, 8.3MB/s
Now I am faced with a Fedora problem -- namely that with Fedora 41, the key exchange methods supported by this old Antminer board are no longer supported.
Feedback? Questions? Drop me a line!

Tom's Computer Info / [email protected]