Hi,
I'm investigating booting from ROM where the rom is larger than the LPC mmapped area of the superio. In the 'stream' methods used by elfboot, there is an option to use compressed payloads, where the stream takes care of the decompression. But what I've seen is that the payload used when booting linux kernel directly (Kernel/LAB), the elf payload itself (kernel-payload.elf as created by buildrom) is already a compressed image, so the kernel-payload.elf.lzma is not smaller, but bigger than the non .lzma one.
So my conclusion is that the original kernel decompression is still used in coreboot, and choosing lzma compression for the elf payload is only a superfluous extra copy step. Is this correct? Or is this specific to a 64bit kernel, as the elf file holding the 64 bit kernel seems to be a 32 bit elf file.
Regards, Ronald.
On 21.01.2008 01:03, Ronald Hoogenboom wrote:
Hi,
I'm investigating booting from ROM where the rom is larger than the LPC mmapped area of the superio. In the 'stream' methods used by elfboot, there is an option to use compressed payloads, where the stream takes care of the decompression. But what I've seen is that the payload used when booting linux kernel directly (Kernel/LAB), the elf payload itself (kernel-payload.elf as created by buildrom) is already a compressed image, so the kernel-payload.elf.lzma is not smaller, but bigger than the non .lzma one.
So my conclusion is that the original kernel decompression is still used in coreboot, and choosing lzma compression for the elf payload is only a superfluous extra copy step.
That would be a bug. For early OLPC models, I made sure that the LAB payload was created by compiling a normal uncompressed ELF kernel image, which was then compressed by buildrom with lzma. However, OLPC was never good at feeding code changes back upstream, so I don't know the current state.
Is this correct? Or is this specific to a 64bit kernel, as the elf file holding the 64 bit kernel seems to be a 32 bit elf file.
ELF files holding 64bit Linux kernels are strange beasts for backward compatibility reasons.
Regards, Carl-Daniel
-
Carl-Daniel Hailfinger -
Ronald Hoogenboom