[U-Boot] SPL support and secondary image size

[U-Boot] SPL support and secondary image size

[jonsmirl at gmail.com]

My primary SPL image needs the size of the secondary image built into
it. How do I access that size while building the primary SPL image?

-- 
Jon Smirl
jonsmirl at gmail.com

[U-Boot] SPL support and secondary image size

[Scott Wood]

On 11/03/2011 05:20 PM, jonsmirl at gmail.com wrote:
> My primary SPL image needs the size of the secondary image built into
> it. How do I access that size while building the primary SPL image?

Does it need to be exact?  Usually we just hardcode something that
should be big enough.

-Scott

[U-Boot] SPL support and secondary image size

[jonsmirl at gmail.com]

On Thu, Nov 3, 2011 at 7:08 PM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
> On Thu, Nov 3, 2011 at 7:00 PM, Scott Wood <scottwood@freescale.com> wrote:
>> On 11/03/2011 05:20 PM, jonsmirl at gmail.com wrote:
>>> My primary SPL image needs the size of the secondary image built into
>>> it. How do I access that size while building the primary SPL image?
>>
>> Does it need to be exact? ?Usually we just hardcode something that
>> should be big enough.
>
> NXP has written custom out of tree support for SPL on the lpc3130/31.
> I am reworking it to use the in-tree SPL code. ?lpc3130 supports six
> boot modes but I have 64K of SRAM to work with. ?One of those modes is
> to read the next image over the serial line, the existing NXP code
> wants to know the length to read.
>
> http://git.lpclinux.com/?p=uboot-2009.11-lpc313x.git;a=summary
>
> The way they implemented SPL was to build it and main uboot into a
> single image file. Then they used dd to cut it into two pieces.
> Building it as a single image allows the initial loader to get at
> things like the length of the second image.
>
> I will have to go through all of their code to see if the length
> require is exact.
>
>
>>
>> -Scott
>>
>>
>
>
>
> --
> Jon Smirl
> jonsmirl at gmail.com
>



-- 
Jon Smirl
jonsmirl at gmail.com

[U-Boot] SPL support and secondary image size

[jonsmirl at gmail.com]

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

-- 
Jon Smirl
jonsmirl at gmail.com

[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@gmail.com> wrote:
> On Thu, Nov 3, 2011 at 4:27 PM, jonsmirl at gmail.com <jonsmirl@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

[U-Boot] SPL support and secondary image size

[Aneesh V]

Hi Jon,

On Friday 04 November 2011 04:30 AM, Scott Wood wrote:
> On 11/03/2011 05:20 PM, jonsmirl at gmail.com wrote:

Looks like I am not seeing some mails in this thread. I didn't get your
first mail, neither Tom Rini's mails.

>> My primary SPL image needs the size of the secondary image built into
>> it. How do I access that size while building the primary SPL image?

For OMAP we find this run-time by loading u-boot.img instead of
u-boot.bin. u-boot.img has a 64 byte header with all necessary
information such as size, load address, image type etc. The OMAP SPL
can in fact load any image that has a standard u-boot header(mkimage
header), including a uImage. This scheme was suggested by Wolfgang.

>
> Does it need to be exact?  Usually we just hardcode something that
> should be big enough.
>
> -Scott
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] SPL support and secondary image size

[jonsmirl at gmail.com]

On Thu, Nov 3, 2011 at 10:11 PM, Aneesh V <aneesh@ti.com> wrote:
> Hi Jon,
>
> On Friday 04 November 2011 04:30 AM, Scott Wood wrote:
>>
>> On 11/03/2011 05:20 PM, jonsmirl at gmail.com wrote:
>
> Looks like I am not seeing some mails in this thread. I didn't get your
> first mail, neither Tom Rini's mails.
>
>>> My primary SPL image needs the size of the secondary image built into
>>> it. How do I access that size while building the primary SPL image?
>
> For OMAP we find this run-time by loading u-boot.img instead of
> u-boot.bin. u-boot.img has a 64 byte header with all necessary
> information such as size, load address, image type etc. The OMAP SPL
> can in fact load any image that has a standard u-boot header(mkimage
> header), including a uImage. This scheme was suggested by Wolfgang.

I was starting to think along those lines too. I could have the SPL
boot straight to Linux when booting from NAND. Then if I use a DFU USB
stick have it boot to full u-boot.  It could be modified to give some
options on the touch screen to rewrite the NAND since there is no
keyboard.




>
>>
>> Does it need to be exact? ?Usually we just hardcode something that
>> should be big enough.
>>
>> -Scott
>>
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>
>



-- 
Jon Smirl
jonsmirl at gmail.com

[U-Boot] SPL support and secondary image size

[jonsmirl at gmail.com]

On Thu, Nov 3, 2011 at 10:11 PM, Aneesh V <aneesh@ti.com> wrote:
> Hi Jon,
>
> For OMAP we find this run-time by loading u-boot.img instead of
> u-boot.bin. u-boot.img has a 64 byte header with all necessary
> information such as size, load address, image type etc. The OMAP SPL
> can in fact load any image that has a standard u-boot header(mkimage
> header), including a uImage. This scheme was suggested by Wolfgang.

Once I get the image file into memory, is there a uboot function I can
call to run it? One that copies it to the correct location, does
fixups, etc

I tried running it from the command line:

EA3131-NXP # bootm 0x31000000
## Booting kernel from Legacy Image at 31000000 ...
   Image Name:   U-Boot 2011.09-00285-gc0d0576 fo
   Image Type:   ARM U-Boot Firmware (uncompressed)
   Data Size:    240496 Bytes = 234.9 kB
   Load Address: 31200000
   Entry Point:  00000000
   Verifying Checksum ... OK
Wrong Image Type for bootm command
ERROR: can't get kernel image!
EA3131-NXP #

-- 
Jon Smirl
jonsmirl at gmail.com