Hi Gabe, On Fri, Dec 2, 2011 at 8:26 AM, Gabe Black <[email protected]> wrote: > > > On Thu, Dec 1, 2011 at 7:47 AM, Graeme Russ <[email protected]> wrote: >> >> Hi Gabe, >> >> On 30/11/11 17:25, Gabe Black wrote: >> > >> > >> > 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. >> > >> > 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 _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
