April 19, 2024

EBAZ4205 Bitcoin miner board - Booting (part 3 - bootrom)

We know that the first "chunk" of NAND is labeled "nand-fsbl-uboot". This is a 3M section -- plenty of space for ye olde U-boot.

The TRM talks about booting in chapter 6 (pages 148-224) and it talks about OCM (on chip memory) in chapter 29. What I call the TRM (the Technical Reference Manual) is the 1843 page document ug585-Zynq-7000-TRM.pdf.

The Zynq chip contains 256K bytes of "on chip memory" and you can bet your bottom dollar that the bootrom will load a first state loader in here and run it. It is possible (a slim chance) that all of U-boot will fit here. If not, this will be a first stage loader that sets up the DRAM clocks and then loads U-boot into DRAM to run it. We shall see.

The TRM says that once you have your software running in OCM you should refer to UG821 for details about how to write it. This document (UG821) is only 68 pages. Chapter 3 is entitled "boot and configuration". It refers to the on chip bootrom code as "stage 0 boot code" and refers you back to the TRM (UG585) for details about it.

Various sorts of flash memory (NOR, NAND, or SD) as well as JTAG can supply the first stage boot loader that goes into OCM and runs.

Flash memory holds a boot image, which consists of a "boot header" and the FSBL (first stage boot loader). Now things get interesting as we find out what this boot header looks like. It is described in detail in section 6.3.2 of the TRM. This is what is great about working with chips designed in the USA, and in particular Xilinx. You generally get superb documentation. My hat is off to Xilinx in this regard.

Examine our boot header

I do this:
cd /dev
dd if=mtd0 of=/home/root/boot.img count=16
I then copy it to my linux desktop, where I have lots of tools to examine it.
scp root@ebaz:boot.img .
Here is a hex dump of the first part of what we get:
00000000 feff ffea feff ffea feff ffea feff ffea
00000010 feff ffea feff ffea feff ffea feff ffea
00000020 6655 99aa 584e 4c58 0000 0000 0000 0101   fU  XNLX
00000030 0017 0000 1080 0100 0000 0000 0000 0000
00000040 1080 0100 0100 0000 2045 16fc 0000 0000            E
00000050 0000 0000 0000 0000 0000 0000 0000 0000
00000060 0000 0000 0000 0000 0000 0000 0000 0000
00000070 0000 0000 0000 0000 0000 0000 0000 0000
00000080 0000 0000 0000 0000 0000 0000 0000 0000
00000090 0000 0000 0000 0000 c008 0000 800c 0000
000000a0 ffff ffff 0000 0000 ffff ffff 0000 0000
000000b0 ffff ffff 0000 0000 ffff ffff 0000 0000
...
...
00000880 ffff ffff 0000 0000 ffff ffff 0000 0000
00000890 ffff ffff 0000 0000 ffff ffff 0000 0000
000008a0 ffff ffff ffff ffff ffff ffff ffff ffff
000008b0 ffff ffff ffff ffff ffff ffff ffff ffff
000008c0 0000 0201 0300 0000 2003 0000 4002 0000               @
000008d0 0000 0000 ffff ffff ffff ffff ffff ffff
000008e0 ffff ffff ffff ffff ffff ffff ffff ffff
000008f0 ffff ffff ffff ffff ffff ffff ffff ffff
00000900 5002 0000 2003 0000 0000 0000 0100 0000   P
00000910 7473 6574 6c62 7366 666c 652e 0000 0000   tsetlbsffle.
00000920 0000 0000 ffff ffff ffff ffff ffff ffff
00000930 ffff ffff ffff ffff ffff ffff ffff ffff
00000940 6002 0000 3003 0000 0000 0000 0100 0000   `   0
00000950 5f70 6f74 6c72 7463 7469 622e 0000 0000   _potlrtctib.

Offset 0x24 is described as "image identification", so finding XLNX in ascii here seems plausable. Offset 0xa0 begins a section called "register initialization" which continues to 0x89f -- and that is what I see.

The image itself begins at 0x900. We see two strings. I take the characters in groups of 4 and reverse the order to get what I show in parenthesis:

tsetlbsffle.  (testfsbl.elf)
_potlrtctib.  (top_ctrl.bit)

Where is U-boot running

I use 'd' to interrupt the boot and try some things from the U-boot prompt.
bdinfo shows me:
relocaddr   = 0x0FF29000
reloc off   = 0x0BF29000
irq_sp      = 0x0F305A60
sp start    = 0x0F305A50
Other significant addresses are 0x0208_0000 for the kernel and 0x0200_0000 for the fdt.

The TRM says there is DDR from 0010_0000 to 3FFF_FFFF (or there can be).

My bare metal experiments have worked loaded to 0x2000_0000

I can dump memory using U-boot -- Here is OCM

md 0
00000000: e59f0000 e12fff10 00101400 aeb8becb    ....../.........
00000010: be9fbcba baeb3a1f 9eadfffc b6ef86db    .....:..........
00000020: fdeebfba 7aabb97f ebfbfbaf fffeebff    .......z........
00000030: e6ad5efa dcdd97ff b6febef9 3365b4ff    .^............e3
00000040: eb66bfed fbe7bfd1 9efebfdf 7feb0bee    ..f.............
I don't know how to make sense of all this .....
Feedback? Questions? Drop me a line!

Tom's Computer Info / tom@mmto.org