[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
> 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