Hi there,
While getting acquainted with possible u-Boot development issues, I read FAQ "14.2.1. Can U-Boot be configured such that it can be started in RAM?" and was puzzled to learn that u-Boot cannot run from RAM.
Considering a custom platform, using i.MX536, I understand that the i.MX53x processor has its own ROM-based code that performs boot time essential devices initialisation, etc. In the case when NAND flash is the program-image medium at the boot stage, first, the ROM-based code checks for Discovered Bad Blocks Table (DBBT) presence and searches for valid Firmware Configuration Block (FCB) on external NAND Flash.
If FCB is found that points to the NAND Flash page(s) that contain the first 4K of initial firmware to be loaded from NAND Flash. Then, it loads the 4K of data, pointed by FCB, into the NFC RAM buffer. These data contain a valid Image Vector Table (IVT). Then, the ROM-based code processes IVT, executes the Device Configuration Data (DCD) sequences to initialize boot-related integrated peripherals (typically, these are IOMUX, SDRAM controller and boot memory controller), then copies the application code, also contained in IVT, to target memory (typically, SDRAM) and jumps to it. Typically, this application code is the custom primary bootloader that completes loading the application code (e.g. main OS bootloader) and passes the control to it.
If FCB is not found the ROM-based code starts executing a download protocol over UART or USB port in an attempt to get a valid IVT from a host. If the IVT is eventually obtained it is processed as before.
So the question is can this "custom primary bootloader" role, in fact, be played by u-Boot. Reading your text of FAQ 14.2.1., it seems to me that it cannot. On the other hand I know of some Freescale i.MX53x demo boards (e.g. ARD, LOCO) that use u-Boot.
I wonder what I'm missing here.
Regards,
Bud