[U-Boot] SPL support and secondary image size
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?
On 11/03/2011 05:20 PM, jonsmirl@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
Hi Jon,
On Friday 04 November 2011 04:30 AM, Scott Wood wrote:
On 11/03/2011 05:20 PM, jonsmirl@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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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@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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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 #
participants (3)
-
Aneesh V -
jonsmirl＠gmail.com -
Scott Wood