[LinuxBIOS] Patch for vmlinux amd64 with mkelfImage

Eric W. Biederman ebiederm at xmission.com
Sun Nov 5 16:05:09 CET 2006

yhlu <yinghailu at gmail.com> writes:

> On 11/4/06, Eric W. Biederman <ebiederm at xmission.com> wrote:
>> 1M for bzImage remains fine.  All bootloaders would break if you
>> changed that.  But for vmlinux you pretty much have it nailed.
> Actually, we only mkelfImage with bzImage before we are trying to use
> lzma to compress elf (tiny kernel vmlinux + uncompressed). lzma can
> get 5% more space than bz2.

First a decode of letters, in bzImage the b stands for big and the
z stands for gzip.  We don't have a bzip2 decompressor in there.

An interesting question is if we make a bImage target that does everything
except the decompression (because nothing would be compressed) would that
suit your needs?

> I hope you can keep startup_32 in your new arch/x86_64/kernel/head.S.
> then we don't need to switch from 32bit mode to 64 bit mode in head.s
> of mkelfImage.  and still convert 64elf to 32bit elf. Also it would
> make other 32 bit bootloader still can load vmlinux64.
> Then we only need to make sure head.s of mkelfImage can get correct entry_point.

Hacks like that are a support pain.   I don't have a problem with weird
magic compatibility glue in the bzImage format but I don't want to introduce
another one.

> Or we need to make elfboot in LinuxBIOS to be 64elf aware, and it need
> to switch 64bit before load 64bit elf.

At least before we jump to the 64bit elf.  For size the 32bit kernel should
be smaller, so I don't understand the interest in the 64bit kernel at this
point.  If we do the 32/64bit transition at the last moment like etherboot
does this requires about 100-200 extra lines of code.


More information about the coreboot mailing list