[U-Boot] [PATCH 0/2] Add support for the 32 bit boot protocol to the x86 zboot command.

[Graeme Russ]

Hi Gabe,

On 30/11/11 17:25, Gabe Black wrote:
> 
> 
> On Tue, Nov 29, 2011 at 7:48 PM, Graeme Russ <graeme.russ at gmail.com
> <mailto:graeme.russ at gmail.com>> wrote:
> 
>     Hi Gabe,
> 
>     On Wed, Nov 30, 2011 at 2:11 PM, Gabe Black <gabeblack at chromium.org
>     <mailto:gabeblack at chromium.org>> wrote:
>     > These two patches add support for the 32 bit Linux boot protocol to the
>     > zboot command.
> 
>     Going by our previous offline correspondence, I assume this approach still
>     uses the bzImage's decompression stub?
> 
>     Also, as I discussion offline previously, I'm going through the boot_params
>     with a fine-tooth comb to get a complete picture of what the Linux kernel
>     actually requires to be filled out in the boot_params structure - I expect
>     this will result in a 'built_boot_params()' function which is called by
>     zboot and bootm - possibly with some weak stubs to helper functions
> 
>     Regards,
> 
>     Graeme
> 
> 
> Yes, this supports the 32 bit protocol which includes the decompression
> stub. I don't think a build_boot_params function which actually builds the
> bootstub would work for a number of reasons. First, that's not how the boot
> protocol works. The kernel provides information there that u-boot needs to
> read, and u-boot shouldn't just make it up. An example of this is what boot
> protocol is expected. Second, you might find all the things a particular
> version of the kernel wants right now, but that could easy change at any
> time and break booting. Third, the boot_params structure isn't compressed
> (because otherwise the bootloader couldn't fill it out) and building our
> own wouldn't serve any purpose.
> 
> If you mean consolidating the existing boot_params code so that both zboot
> and bootm can use it, that seems reasonable. I'd point out, though, that
> filling out the table takes a trivial amount of time, so trying to cut
> corners and not fill it out completely would not only be dangerous, it
> would very likely not be worth the effort.

I've been playing around tonight and have managed to embed a gzip'd vmlinux
and raw header (stripped from the associated bzImage) into my U-Boot image
but I end up getting the same results - No RAM :(

So proof of concept is good

Regards

Graeme