Ronald G Minnich <[EMAIL PROTECTED]> writes:
> On Sun, 3 Jun 2001, Eric Seppanen wrote:
>
> > By the way, it isn't terribly hard to get rid of "mkrom" entirely, using
> > only the linker to construct the rom image. I've been doing it that way
> > for a while. In my opinion, this is more flexible and allows more exotic
> > mappings than "mkrom" does, and just seems... cleaner.
>
>
> works for me. I would love to see mkrom disappear. I am sure it was needed
> at some point, but who cares now.
>
> I'd be happy to take in an improved linker script or whatever it takes.
I hadn't even thought about that. I'll take a look it should be
pretty simple to build.
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.
The real advantage of considering stage1 and stage2 seperately
is that stage1 must not be compessed in ROM, and it is all
about doing things in assembly. At least unless I get really
frustrated and write a minimal C compiler, that can work in
that kind of environment.
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.
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.
Eric
