[U-Boot] SPL support and secondary image size

[jonsmirl at gmail.com]

On Thu, Nov 3, 2011 at 9:37 PM, Tom Rini <tom.rini at gmail.com> wrote:
> On Thu, Nov 3, 2011 at 4:27 PM, jonsmirl at gmail.com <jonsmirl at gmail.com> wrote:
>> Some more info on the out of tree NXP code...   I didn't write it, I
>> am just trying to get it working on a current uboot since the NXP
>> u-boot code is too old for ARM device tree support.
>>
>> Most u-boot images are around 250KB.
>>
>> lpc3130 has 96K of SRAM. The ARM ROM on the chip can IPL from six
>> sources: NAND, SPI, DFU USB, SD, NOR FLASH, UART. A header at the
>> front of the IPL image tells the ROM how much to load.
>>
>> 96KB is large enough to build a single SPL image that can then
>> continue loading from all six different sources. I have ported enough
>> of the code to the new SPL system to build a SPL image derived off
>> from the NXP code. For my application I want NAND and USB DFU. I am
>> testing with UART.
>>
>> The secondary NXP loaders all want to know the length of what they are
>> loading. NXP was able to get this length by building both the SPL and
>> the main u-boot into a single image file. They then used dd to chop it
>> up into the two files: u-boot-spl.bin and u-boot.bin
>
> OK, but this is new and you aren't restrained by that really, yes?
> Are you able to tell at run time what the next source should be?  What

After the SPL program gets control it can reread the GPIO pins telling
what the boot mode is. There is not restriction on how the boot can
proceed, I can ignore the pins if I want to.

I added a minor hack to the Makefile to get the file size passed into
the SPL build.
CFLAGS += -DUBOOT_FILESIZE=$(shell stat -c%s $(TOPDIR)/u-boot.bin)

I can now load the SPL via UART, then load the real uboot via UART
(straight binary) and then it doesn't work right so I have to debug
it.

> I mean is that on OMAP3/4/am335x if we load via UART, we load the SPL
> binary via UART and it is told by the rom that UART was what it was
> loaded by so SPL then expects to be given U-Boot by UART.  But the rom
> code isn't responsible, U-Boot SPL is and doesn't care (we added
> ymodem support which needs pushing back to the community).  Same deal
> with SD or NAND.  romcode loads one, tells us what loaded us, then
> U-Boot SPL is loading the next part.
>
> --
> Tom
>



-- 
Jon Smirl
jonsmirl at gmail.com