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

[Gabe Black]

On Thu, Dec 1, 2011 at 7:47 AM, Graeme Russ <graeme.russ at gmail.com> wrote:

> 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
>


You have to make sure you're using the 32 bit protocol. The 16 bit protocol
should still work and is the default, but then the kernel tries to use
other means to figure out what memory looks like. To use the 32 bit
protocol, you need to define CONFIG_ZBOOT_32.

Gabe