Ollie Lho <[EMAIL PROTECTED]> writes:
> "Eric W. Biederman" wrote:
> >
> >
> > It occurs to me that we really have three stages of booting.
> > stage1: Startup and turn on ram, branch to stage2. (It's in assembly)
> > stage2: In C enable built in devices, and setup tables describing
> > the hardware, branch to stage3.
> > stage3: A kernel or a firmware bootloader.
> >
>
> Yea, for DoC + SiS630:
> stage1 -> ipl.S
> stage2 -> LinuxBIOS
> stage3 -> Linux Kernel
Exactly. If we adopt this model we should match existing practice
much better.
On alpha we have:
stage1 -> vendor supplied SROM
stage2 -> LinuxBIOS
stage3 -> Linux Kernel
> > stage2 can be compressed. It can be relocated. It is where we
> > start doing interesting things because we are in C and we do have
> > memory turned on. Any interesting failsafe booting logic probably
> > belongs here.
> >
>
> I am a litte bit confused with your mail about -fPIC -static,
> can you make it more specific ??
First spliting linuxBIOS into a stage1 & and a stage2 probably handle
Tyson needs better than my suggestion.
The gcc C compiler appears to support code that we can relocate with
impunity and without much work. This reuses standard support for
shared libraries but compiling statically instead of dynically.
O.k. This howto do this is still work in progress but:
If you add -fPIC to CFLAGS then the C compiler produces position
indpendant code. %ebx is used as an index register, and is calculated
at the start of each function. So for most things all addresses are
calculated relative to %ebx. Some things need a table lookup. So the
linker creates a .got section which is a table of pointers. When
compiled statically only the .got section has any absolute addresses.
To relocate such code you just copy (keeping all sections the same
relative distance from each other), adjust the values in the .got
section by the amount the code moved, and you are done.
> > stage3 is the payload. The kernel or the firmware bootloader,
> > and definentily should be compressed. stage3 should be shared
> > between multiple hardware architectures.
> >
> > Though for stage3 we probably have:
> > stage3/1 Do hardware initialization that stage3/2 doesn't yet
> > know how to do, it's machine independant so somtimes
> > it takes a while to get the latest drivers.
> > stage3/2 The actual kernel of firmware bootloader.
> >
> > An interesting question is can we do partitions on the flash
> > devices so we can safely update (at least stage3) indepenently
> > of the others.
> >
>
> Gerenally speaking, this can be done. But most flash device have
> different "erase region" size which makes a "uniform interface"
> very diffcult.
Agreed. Still I think investigating it at least for the stage3 is
worthwhile. As replacing the kernel is something that happens.
It's on my wish list we will see what happens.
Eric
