> I have been examining the linuxppc code a bit, and a few discrepencies have
> turned up - nothing that seems to be the cause of our problem, though.
> 
> For instance - they do not use OF_claim in their bootloader the way we do
> in ofwboot/boot.c, as far as I can tell.  They simply load the kernel in
> low core (0x0000).  Also, they are more rigid about setting the return
> value slot in each open firmware call to -1, which we skip - probably,
> safely.

Well, you can get away without OF_claiming the memory for the kernel (and
in fact, the kernel itself uses the rest of the free memory without claiming
it (don't ask, it's due to another bug)).  The "correct" way however would be
to claim the memory from the firmware in order to tell it not to use it for
something else (especially since we want the firmware to coexist with our
kernel).

> I also noticed one oddity in our locore.S.  This is right above
> ENTRY(ofw_stack):

[ code deleted for brevity ]

> Is this not yet an issue in ofwboot? Does it have to do with the kernel's
> own stack? It is called religiously in openfirm.c but not in
> ofwboot/Locore.c.

This code is neccessary since the kernel itself runs in virtual mode,
but it has to call the firmware in real mode (remember, that the firmware is
assumed to be run in real mode).  It therefor cannot use a virtual mode stack
to run on and has to switch stacks.

During ofwboot however, there is no switch in modes.  So this code isn't
neccessary here.

> In case no one else mentioned this...
> After the first boot fails with a default catch, if I try again, instead of:
> loading .text...
> loading .data...
> clearing .bss...
> 
> I get:
> loading .textCLAIM FAILED

That's because the firmware actually claims the memory where it loads the
code.  So the second time around the memory isn't available any more.

Ciao,
Wolfgang
-- 
ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) 	+49-228-985800