Few days back looking at OMAP3430 Public TRM I found the section 26.4.8.2(page 3427), it was exciting to see what possibilities lay here.. a little more digging later and few hours of coding later, figured out that by adding a certain data as a prefix to the real image, we can boot u-boot or for that matter any image straight from NAND flash into sdram.. essentially this is what x-loader does, only that OMAP3430 ROMCode already has that feature..
What exactly is Configuration Header(CH)?
CH is a set of register values to the critical OMAP registers that define how the clocks, sdram controller, gpmc controller, mmc controllers are configured.. it is more like an array of register values - you fill them up with the correct values, and store the load address you would like the resultant image to load up, bingo, we have the image booting off that location.. There are few of these structures that are defined in the TRM which has a detailed description on the real sequence of operation..
What does Configuration Header save us?
Time :)! Traditional NAND boot has always been:
- ROMCode takes x-loader from NAND, put it in SRAM and boot it.
- x-loader goes ahead and configures clock, sdram etc.. then proceeds to load u-boot from NAND to SDRAM and execute it
- ROMCode takes u-boot from NAND, put it in SDRAM and boots it.
Aaah.. I am excited with Configuration Header and want to use it.. How do I do it?
You are in luck :).. my recent commit to omap u-boot-utils has the required code for signing a u-boot to use configuration header in a GP device.. there is even a sample.cfg file with the settings that worked for me on beagleboard :)..
Do a "gpsign -c conf/sample.cfg -f u-boot.bin" will generate a u-boot.bin.ift file. flash this image using h/w ecc (the "nandecc hw" command in u-boot) to offset 0x0 in nand and reset the board.. viola, it should boot straight into u-boot skipping the x-loader step :)
Apologies that I do not (at the time of this post) have a prebuilt omap-uboot-utils binaries, but hope to do it for v3.0 tag in the future, esp if folks have some further fixes or improvements -> for the time being it requires a git pull and a host machine build :(..
Caveat: there is somesort of a 128KiB limitation on MLO file signed like this for MMC Card with FAT filesystem, so I generally use x-loader still in MMC boot..
By the way, this feature is not available in the previous OMAP2 or OMAP1 devices..
3 comments:
Thanks Nishanth for this very helpful info!
By using your omap-u-boot-utils I managed to boot the kernel directly on beagleboard-C4(OMAP3530).
I still have this issue. For some reason the image is loaded from NAND only when the USR button is pressed & no MMC/SD card attached.
As I've read in the TRM & BB-HwRef, the boot seq (according to sys_boot) should be NAND first.
I assume the CH doesn't have the right values, or this is a known issue ?
Thank you,
Nishanth,
This information was very useful.
Currently I am working on WinCE 6.0 BSP for a custom OMAP3530 board and I have a strange issue to report you and see if you can give us any information related to that.
As mentioned, I have downloaded RBL CH generation tool and generated CH for our wince x-loader with DDR settings intact (as present in tool). This CH is prefixed to x-loader binary (x-loader does not initialize DDR). Put x-loader, bootloader and OS image in SD card then boot the system several times. We have observed a very strange issue that OS image hangs for some iterations. But if we revert back to our original x-loader (where CH is missing and DDR is initialized in x-loader) board always boot up without any issues. I feel that RBL is not initializing DDR settings properly. I remember DDR requires delays during initialization and I have a doubt that RBL is not taking care of this. ANy input in this regard will be very helpful to us.
One more question.. Is it possible to access RBL source code?
Hi,
Actually, I'm also experiencing similar behavior.. I use just the CH & sty code on top of kernel (zImage), but for some reason sometimes (for different kernel config) won't go beyond
"40WUncompressing Linux... done, booting the kernel."
on the serial console.
If I boot the same kernel the standard way (RBL->xloader->uboot->kernel) - no problem.
Currently I'm checking with earlyprintk (CONFIG_DEBUG_LL). I'll come back with more info.
Post a Comment