[LinuxBIOS] Patch for vmlinux amd64 with mkelfImage

yhlu yinghailu at gmail.com
Sun Nov 5 18:09:49 CET 2006

On 11/5/06, Eric W. Biederman <ebiederm at xmission.com> wrote:
> 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.

Thanks for the explanation...
> 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?

That could be good for us.
> 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.

But it seems that current boot loader only use first program header's p_addr?

> 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.
that 256 byte code could be done in elfboot, or head.s of mkelfImage.
A: elfboot (not 64bit aware) ---> 32bit elf --->64 bit kernel (head.S
startup_32 then startup_64)
B: elfboot (not 64bit aware) ---> 32bit elf ( elf do the 32->64
transition) --->64 bit kernel (startup_64)
C: elfboot (64bit aware, switch to 64bit) ---> 64bit elf --->64 bit
kernel (startup_64)

the A is less work in all.

the reason for using 64bit kernel:
1. don't want to dig i386 arch together with final x86_64
2. for 64bit resource support, the 32bit kernel will ignore or clear
that resource.


More information about the coreboot mailing list