Skip to content

Add support for the 32 bit boot protocol to the x86 zboot command.

Graeme Russ u-boot 1 version New

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest0 of 2 patches 0 repliesNew

Patches in v1 No applies recorded yet

None of the 2 patches the cover letter announces are in this archive.

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

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

Hi Gabe,

Quoted 37 lines · Gabe Black

On Tue, Nov 29, 2011 at 7:48 PM, Graeme Russ <[email protected] <mailto:[email protected]>> wrote:

Hi Gabe,

On Wed, Nov 30, 2011 at 2:11 PM, Gabe Black <[email protected] <mailto:[email protected]>> 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.

Quoted 5 lines

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