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

[Graeme Russ]

On Wed, Nov 30, 2011 at 5:25 PM, Gabe Black <gabeblack at google.com> wrote:
>
>
> On Tue, Nov 29, 2011 at 7:48 PM, Graeme Russ <graeme.russ at gmail.com> wrote:
>>
>> Hi Gabe,
>>
>> On Wed, Nov 30, 2011 at 2:11 PM, Gabe Black <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

Well actually, the kernel does not provide that information - That
information is generated during the compilation of the kernel

> 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

Correct - The kernel build process files in a few important pieces of
information for the bootloader - Particularly, this information lets the
bootloader know where it can physically place the kernel, if the kernel
is relocatable, what the minimum and optimum alignments of a relocatable
kernel are, where the command line arguments can be stored, how big the
command line can be, etc, etc,

> 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

But once a location in the boot_params structure has been given a defined
purpose, it is never re-allocated (only deprecated) so using the latest
version of boot_params guarantees that we will have all the fields for all
kernels. The 'Protocol Version' field tells us what fields are required

> (because otherwise the bootloader couldn't fill it out) and building our own
> wouldn't serve any purpose.

Correct. What I'm suggesting is that we take the boot_params structure
created during the kernel build process and include it in the uImage so
we would have a uImage containing (vmlinux + boot_params + initrd). We
extract the boot_params, use the info contained within to load the kernel
into the correct location in memory, fill out the bits of boot_params that
the kernel needs from us (command line and e820 map mostly, but I think
there may be one or two others) and jump into the kernel.

> 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'm not suggesting cutting corners - If we have a centralised function
which gets passed a boot_params and it fills out all the required info,
then we only have one code location that needs updating for any new Linux
kernel. This is essentially all that the 16-bit 'setup.bin' which sits at
the start of bzImage does.

Regards,

Graeme