January 19, 2025

Antminer S9 board - rebuild U-boot

I built this back in June, 2024 but am unsure about all that I did back then, so I am going to revisit this and redo it.

I have a clone of u-boot-xlnx, I do not try to pull any updates and just do this: 

cd u-boot-xlnx
make
As near as I can tell this uses the generic "xilinx_zynq_virt_defconfig". In other words back in June, I must have done "make xilinx_zynq_virt_defconfig".
This file contains the following two lines: 
CONFIG_OF_BOARD=y
CONFIG_OF_LIST="zynq-zc702 zynq-zc706 zynq-zc770-xm010 zynq-zc770-xm011 zynq-zc770-xm011-x16
zynq-zc770-xm012 zynq-zc770-xm013 zynq-cc108 zynq-microzed zynq-minized zynq-picozed zynq-zed
zynq-zturn zynq-zturn-v5 zynq-zybo zynq-zybo-z7 zynq-dlc20-rev1.0"

How can this work?

Take a look at doc/README.multi-dtb-fit -- which explains the idea. A routine called board_fit_config_name_match() figures out which DTB to actually use. There are two related options: U-Boot itself uses (CONFIG_MULTI_DTB_FIT). The SPL uses (CONFIG_SPL_MULTI_DTB_FIT).

Also look at doc/usage/fit/howto.rst which explains even more in detail.

Consider another board that doesn't use this scheme, such as omap3_beagle_defconfig. Here there are no CONFIG_OF options like the zynq has and the dtb is specified by: 

CONFIG_DEFAULT_FDT_FILE="omap3-beagle.dtb"

Issue with OpenSSL engine

The build fails at: "fatal error: openssl/engine.h: No such file or directory". Apparently the Fedora folks are deprecating this, but have not (yet) removed it. I do this: 

su
dnf install openssl-devel-engine
This is not used for the actual build of U-boot, but for something in the "tools" directory that I probably don't need. Hopefully somebody is maintaining whatever it is and planning to use whatever new API replaces the "engine".

Finish the build

After this, the build ran clean. Then I did this: 
make clean
make &> build.log
make clean
make V=1 &> buildV.log
This gives full details of all the commands. I won't keep it all, but I am particularly interested in the last commands that pull out binary images and such.

The "spl" directory

This has interesting stuff, in particular u-boot-spl.bin which is 133244 bytes. the limit is 3*64K, which is 196608 (0x30000). There is also, of all things, a "boot.bin" file which has a valid Zynq bootrom header. This was produced by "MKIMAGE" via this command: 
./tools/mkimage -T zynqimage -R ./"" -d spl/u-boot-spl-align.bin spl/boot.bin >/dev/null  && cat /dev/null
This tool is used for even fancier tricks.

Try some of these

There is a giant BOOT.BIN from June. I copy it into the FAT partition on the flash card I have been using and try to boot it. Nothing happens.

I also try spl/boot.bin, but it also does nothing when booted (at least no output on the serial port). Being curious, I fire up the JTAG again and see what is up: 

halt
zynq.cpu0: MPIDR level2 0, cluster 0, core 0, multi core, no SMT
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x400001f3 pc: 0xfffffd5c
MMU: disabled, D-Cache: disabled, I-Cache: enabled
Being in Thumb state at this odd address hardly seems right. 
arm disassemble 0xfffffd00 64
0xfffffd54  0000 0000	andeq	r0, r0, r0
0xfffffd58  0000 0000	andeq	r0, r0, r0
0xfffffd5c  0000 0000	andeq	r0, r0, r0
0xfffffd60  0000 0000	andeq	r0, r0, r0
0xfffffd64  0000 0000	andeq	r0, r0, r0
To just display memory with OpenOCD, use this: 
mdw 0xfffff000 512
0xfffff000: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0xfffff020: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0xfffff040: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
....
Apparently "md" is for "memory display" and the "w" says to show 32 bit words. Instead of "w", you can use d, h, or b for 64 bit "double", 16 bit half, or bytes. Typing "reg" shows registers.
Feedback? Questions? Drop me a line!

Tom's Computer Info / tom@mmto.org