Re: [Fastboot] [CFT] ELF Relocatable x86 and x86_64 bzImages

From: H. Peter Anvin
Date: Mon Aug 14 2006 - 15:30:30 EST

Vivek Goyal wrote:
On Mon, Aug 14, 2006 at 10:04:29AM -0700, H. Peter Anvin wrote:
Vivek Goyal wrote:
On Thu, Aug 10, 2006 at 02:09:58PM -0600, Eric W. Biederman wrote:
I just reserved memory at non 2MB aligned location 65MB@15MB so that
kernel is loaded at 16MB and other smaller segments below the compressed
image, then I can successfully booted into the kdump kernel.

So basically kexec on panic path seems to be clean except stomping issue.
May be bzImage program header should reflect right "MemSize" which
takes into account extra memory space calculations.
Yes. That sounds like the right thing to do.

I remember trying to compute a good memsize when I created the bzImage
header but it is completely possible I missed some part of the
calculation or assumed that the kernels .bss section would always be
larger than what I needed for decompression.

Could someone please describe the intended semantics of this MemSize header, *and* its intended usage?

Now and ELF header(attached to bzImage) is being used to describe
the kernel executable. One program header of PT_LOAD type is being
created. The "p_filesz" field of program header is basically describing the vmlinux file size and "p_memsz" is giving how
much memory will be consumed by kernel image at load time.

Ideally "p_memsz" should be "p_memsz" summation of all the program
headers of vmlinux file but I guess in this case we are stretching the
ELF specification a little bit and also taking into the account the
additional memory which will be used by decompressor and decompression
logic by the time execution is transferred to the actual kernel.

What about once the kernel is booted?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at