Re: PATCH/RFC: bzImage payload as compressed ELF file.

From: Jeremy Fitzhardinge
Date: Tue Jan 29 2008 - 12:54:29 EST


Ian Campbell wrote:
If you strip of setup_sects (+1?) from a bzImage, which I think is what
you are referring above, then you end up with essentially
arch/x86/boot/compressed/vmlinux (at address 0x100000 from one of the
bzImage header fields) which can still be jumped to by a 32 bit
bootloader. It will decompress and process the ELF bits correctly. I
think this is where my patch differs from your previous version, you
made the actual compressor portion an ELF file within the bzImage.

Yes, that's right. The changes to make it work were a fair bit more complex than your's.

The thing which no longer works here is scanning the whole image looking
for a gzip header just past setup_sects and extracting that expecting to
find a raw binary because you will actually find an ELF file. I'm not
sure that's an "interface" which could be expected to continue to work
for all time anyway.

Who does that?

That's what I figured. There will be some build system pain to extract
those offsets from boot/compressed/vmlinux and incorporate them into
boot/bzImage but I'll figure something out.

I solved that with some linker magic. One of the things I did was get rid of tools/build and did everything in the linker. And I worked out a trick where you can get the setup code to refer to vmlinux's symbols without actually linking it in (no, wait, was that to solve something else?).

In the xenbits repo, you can see a series of patches guarded with +pvboot, which was my patchset when I last worked on it. i386-cleanup-image-generation.patch is particularly interesting (though it could definitely do with being broken into smaller patches). (xen-paravirt-boot.patch was fun to get going too, though I don't think it will be useful overall.)


J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/