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.
cd /dev dd if=mtd0 of=/home/root/boot.img count=16I 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)
relocaddr = 0x0FF29000 reloc off = 0x0BF29000 irq_sp = 0x0F305A60 sp start = 0x0F305A50Other 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 .....
Tom's Computer Info / [email protected]