November 19, 2024

Antminer S9 board - run linux from SD card

From some prior adventures I have this:
-rw-r--r-- 1 tom tom 3904897024 Jun  6  2016 S9-20160607-recovery-sd.img
I get a 16G SanDisk card, remove it from packaging, and put it into a USB card reader. I have been told that cards bigger than 16G will not work, so I cannot use one of the 32G cards I have in a bundle. Perhaps I should try one someday and verify the rumor.
Then, as usual, I do this:
dd if=S9-20160607-recovery-sd.img of=/dev/sde bs=16M
This finishes and linux automounts two partitions:
/dev/sde1 on /run/media/tom/DE43-0C25 type vfat (315M)
/dev/sde2 on /run/media/tom/c3bcdf22-8cf4-489d-8a62-53f4125f8e9a type ext3 (1.3G)
fdisk -l /dev/sde
/dev/sde1          2048  616448  614401  300M  b W95 FAT32
/dev/sde2        616449 3074049 2457601  1.2G 83 Linux
/dev/sde3       3074050 3094530   20481   10M a2 unknown
I put this into one of my Antminer boards and get absolutely nothing.

add BOOT.BIN and get a surprise

My notes from my previous adventures state that I got this (from somewhere), and put it onto the card that booted. I find that card, stick it into the USB card reader. Sure enough, there is a BOOT.bin file. I copy it from that card to the same directory where I have the "img" file stashed (/u1/Projects/Zynq/Antminer/SDcard). Then my copy with the "recovery SD image" goes back into the card reader and I copy BOOT.bin to that card.

Much to my amusement this now runs U-boot, and the U-boot that has a modified environment set up to network boot bare-metal or my latest Kyu images! Ha ha. The joke is on me, but now I know how to generate any more diskless boot cards I might need. I can interrupt this and look at the U-boot environment and contemplate what I might need to do to make it try to boot linux. I use "printenv" from the U-boot "shell" and I see that it has both "nandboot" and "sdboot" commands. The bootcmd is "bootcmd=run boot_tftp", so what I might do is to try "run sdboot" This gives me the following (among other messages) and then fails.

reading uEnv.txt
** Unable to read file uEnv.txt **
Copying Linux from SD to RAM...
reading uImage
** Unable to read file uImage **
I wonder what the concept was with these S9 recovery images.

Experiments with a 32G card

So I am going to try two things at once, and if things don't work I may not know which was the issue. I get one of my brand new refurb 32G micro SD cards. Into the card reader it goes. I run fdisk, delete the single linux partition I find on it, and create a new partition 320M in size. I change the partiton type to 0x0b (Win95 FAT32). Next I do:
mkfs -t vfat /dev/sde1
mount /dev/sde1 /mnt
cd /u1/Projects/Zynq/Antminer/SDcard/
cp BOOT.bin /mnt
umount /mnt
And this works just fine -- I get my network boot, it finds Kyu and boots it. So who knows what this rumor is that 32G cards won't work. Maybe you can't set up a bit linux partition on one.

So, I have learned a few things, but have not made much progress in my goal of getting linux running from an SD card.

Make that SD card boot from NAND

I was scrutinizing the output from U-boot printenv and I see nandboot, so why not see what it will do. It works!!

It boots linux from NAND and I get to the linux I have hacked on already with the root password cleared. So I can log right in! It has the network all set up (via DHCP) and even has the correct time via ntp. I do "sync; reboot" and get back to the U-boot shell. Here is what it did:

nandboot=echo Copying Linux from NAND flash to RAM... 
nand read 0x2000000 0x1100000 ${kernel_size}
nand read 0x3000000 0x1020000 ${devicetree_size}
bootm 0x2000000 - 0x3000000
So it isn't looking for these things in in the VFAT like SD card boot was:
uImage
devicetree.dtb
uramdisk.image.gz
What about uEnv.txt that was missing when we tried the SD card boot?
bootenv=uEnv.txt
importbootenv=echo Importing environment from SD ...; env import -t ${loadbootenv_addr} $filesize
It is not clear to me why Uboot would be looking for this. Maybe it always looks for this when there is a VFAT filesystem and just mentions that it didn't find it then continues with the boot. Maybe.

Try saveenv

zynq-uboot> saveenv
Saving Environment to NAND...
Erasing NAND...
Erasing at 0xe0000 -- 100% complete.
Writing to NAND... OK
This is what bricked my board in the first place. Not good.

Note: I can set a new variable using "setenv zz3 fish" and then cycle power and I still have it. However, if I do a U-boot "reset" command to reboot, the new variable does not persist.

It is odd, but very handy that setting a variable is persistent after a power cycle, and even more odd that if this works, using a U-boot reset clears it.

Where did this BOOT.bin come from?

It looks like this:
-rw-r--r-- 1 tom tom 2559872 Nov 19 21:39 BOOT.bin
I use "locate" to find all the BOOT.bin files on my system, then write a little python script to run "ls -l" on all of them. I find one with a size that matches:
/u1/Projects/Zynq/Antminer/SDcard/Firmware/fw/xilinx/BOOT.bin

Feedback? Questions? Drop me a line!

Tom's Computer Info / [email protected]