LKML Archive on
help / color / mirror / Atom feed
From: Etienne Lorrain <>
Cc: "H. Peter Anvin" <>,,
	"Eric W. Biederman" <>
Subject: Re : Re : [PATCH] Compressed ia32 ELF file generation for loading by Gujin 1/3
Date: Wed, 7 Feb 2007 14:55:39 +0000 (GMT)	[thread overview]
Message-ID: <> (raw)

Vivek Goyal wrote:
>How do I know which program header is real mode code and the boot loader
> is not supposed to load it? May be PT_LOAD header with physical addr 0?
> What happens if changes happen and down the line we start compiling 
> real mode code for non-zero address?

 Yes, any PT_LOAD below 64 Kbytes can only be real mode, and real-mode
cannot be loaded higher, and cannot be bigger than 640 Kbytes, anything
different (like with virtual address at 0xC0000000) is Linux protected mode.
Considering the linker used it is always the 4th program header, before there
were only 3 program header,third one stay the NOTE one.

> Hence I think keeping real mode code out of vmlinux might prove to be a good idea.

 Well, ELF is a format made to describe what to load, at which addres, and I assume
everyone recognise that some ELF section shall not be loaded, like the debug information.
Gujin accepts having the real-mode treated like a program text and so in the program header,
or like extra memory block with content like the symbol table used by a debugger, I do not
know what is best so have implemented the two.

> Secondly, if you compile real mode code with vmlinux, what would be the
> entry point for this ELF file? Real mode entry? Then I have not way to
> find out from ELF headers where is the protected mode entry point and
> I can not do use this vmlinux with kexec/kdump.

 I did not touch the kernel entry point, the real mode entry point is at offset zero
in the real-mode program header/section table.

> OTOH, now bzImage is relocatable. Is this image going to be relocatable?
> How do we take care of that?

 Just I did not completely understand why you need relocation (and the announce
was when I was in holidays far away). I know a simple kernel is needed to do
some debugging when the main kernel has crashed, this kernel is better loaded
at for instance 16 Mbytes. You probably do not want the same kernel as the main
one because it may crash the same way, and you start a loop - and even then
if you have exactly the same kernel it is easier to use the same write-protected
block of memory with different data sections.
 But I probably do not understand the problem so do not know what to write.



Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! 
Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses

             reply	other threads:[~2007-02-07 14:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-07 14:55 Etienne Lorrain [this message]
2007-02-08  4:45 ` Vivek Goyal
  -- strict thread matches above, loose matches on Subject: below --
2007-02-06 18:39 Etienne Lorrain
2007-02-06 18:57 ` Eric W. Biederman
2007-02-06 17:59 Etienne Lorrain

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \
    --subject='Re: Re : Re : [PATCH] Compressed ia32 ELF file generation for loading by Gujin 1/3' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).