Working Example of IVT, DCD, Boot Data, Application?

[ChrisNielsen]

I've read Tech Ref section 20.6 Program Image several times, hunted the web, and read the postings here and can't put all the details together to fully explain the complete boot process.  I think the heart of it is that there isn't a description of what MOVES are happening during the process (from boot device to Dest Memory).

Figure 20-19 is the heart of everything happening here.  A good diagram to be sure but it doesn't show the SEQUENCE of operations and the cause of the operation.

I'm building a bare-metal system.  Questions regarding 20.6:

- IVT, DCD: This made complete sense to me until I saw a DCD copy in Dest Memory.  My understanding is that the DCD is read and executed then discarded so why is a copy placed in Dest Memory?

- IVT, boot data: I mostly want to believe this is the absolute address in the boot device but then I see a copy in Dest Memory which doesn't seem to make sense because it seems to me that boot data sould just be read once from the boot device, acted upon, and discarded

- IVT, self: if I'm SPI FLASH boot, is this 0x00000400?

- IVT: why is there a copy of the IVT shown in Dest Memory?  Shouldn't this too be read only from the boot device and discarded?

- Boot Data, start: is this absolute address in the boot device or Dest Memory?  It seems like it must be in the boot device or the boot code wouldn't know where it is.  However, if this is the case, how does the boot code know what address to use in Dest Memory?

Or, is is the first 4K of boot device blindly copied over then interpreted?  If so, where does the 4K go in Dest Memory?  Fixed address or set by me?

Thanks, Chris

[billpringlemeir · Accepted solution]

Have you looked at Figure 19-20 in the Vybrid Reference manual (Rev5)?^{I guess this is what you reference.}  In some case (NAND flash), the boot device is not directly accessible by the CPU.  In some cases, the first 4K memory may not be contiguous when read from a boot device.  It is copied, so the verification code can be independent of the boot device.

So the data is copied from the device to internal SRAM at a fixed address; sometimes Freescale gives this information.  Ask your FAE,Rep, etc.  I am not sure why they keep details secretive.  Usually it is due to some US export control laws, etc.  The security reference manual gives some additional details.  They are not strictly needed to get things to work, but they are definitely helpful in understanding.  There is also AN4581, HABv4 secure boot  ^{Esp: Fig 1}which I believe is useful for the Vybrid.

As well, the MQX 4.0.2 has a boot code examples and there is the u-boot  source with includes an mkimage which can format a binary with the headers.  The imximage.c is useful.

[ozu]

Hi,

Is this discussion applicable in the case of IMX6 SoloX SABRE board or is it only limited Vybrid?

if I understood you correctly, boot ROM ALWAYS copies the first 4k to the internal SRAM, is that correct?

If this is true, I am assuming the IVT should always point to addresses in SRAM then, is that correct?

Do we need to change the IVT addresses when we change the boot device? I mean, should IVT 'self' pointer and 'boot_data' pointer point to the boot device at which IVT is actually placed or should it always point to the RAM, because Boot ROM will copy it there?

Please help, any hint, clue will be appreciated :smileyhappy:

Thanks!!

[kef2]

DS-5 working example for QSPI boot is in Sample Code for Vybrid Controller Tower System here:

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=TWR-VF65GS10&fpsp=1&tab=Design_Tools_...#

Try compiling hello_word project for QSPI target, then use quadspi_load project to flash code to QSPI, and finally boot in QSPI mode.