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

[Graeme Russ]

Hi Gabe,

On Fri, Dec 2, 2011 at 8:26 AM, Gabe Black <gabeblack at google.com> wrote:
>
>
> 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.

Yep, done that - And when you boot a raw vmlinux, there is no 16-bit
protocol as there is no 'setup.bin' stub

There is something else going on with the e820 - Any chance you could
provide a dump of a typical e820 array passed into the kernel by your
coreboot patches?

Regards,

Graeme