> It certainly did help, and I've been looking/poking at it...
> Following later suggestions in this thread I tried the over-simplistic
> solution of just changing that bit in the MSR; probably obviously, it
> failed, although not quite so obviously it got the exact same error.
> 
> One thing here is REALLY confusing me, though.  ofwboot dies with the same
> default catch, supporting my growing hunch that it is happening before the
> part of initppc() that changes the trap vectors.  ofwboot does not do this
> at all yet dies anyway, apparently before reaching main().  Presumably
> _start() gets called, and setup() dies - or perhaps the first printf() in
> main().

So where did you change the MSR bit?  In ofwboot or in the kernel itself?
In what place did you change it?

> First of all, any way to examine when it died?  I'm going to poke around

Hmm, capabilities for examination of things is quite limited on Macs :-(.
Contrary to those other deficiencies in their OF implementation this is not
in violation of the OpenFirmware specification.

Actually, the IEEE1275 standard (the specification of OpenFirmware) specifies
that OpenFirmware consists of three parts, an interface mainly to be used
for ROMs on interface cards, an interface used by client programs (our
bootcode and kernel), and a user interface.  An implementation of OpenFirmware
is only required to implement one of those interfaces to be compliant.

Apart from this, the user interface has several optional parts, among them
a forth debugger and an assembler debugger.  Both of those are not implemented
(or at least, I didn't find them in the short time I did take a look) by
Apple's firmware :-(.

> for some documentation now and see if I can turn up anything...
> Also, what the heck do you think is happening?  It's quite confused me,
> because the default catch is apparently coming out of nowhere.  Does
> "normal" OF also die with a default catch if left to its own trap vectors?

No, OF works ok on my machine (if only my machine would work again) when
leaving the trap vectors alone.  Only in the kernel are the trap vectors
changed.

Now thinking about it a bit more, there is some other assumptions in the
boot code that I mostly forgot about (sorry about that :-().  The problem is
whether the booted code is run in virtual or real mode and where the machine
has memory (free or in use).

In order to get the most of control over the machine, NetBSD/powerpc assumes
that it gets started in real mode.

(As an aside, actually this isn't true on my machine.  However, when booted
the firmware maps the memory of the machine 1-1 from real to virtual
addresses, so it's relatively close. The code in ofwreal.S compensates for
this).

Now the firmware in the Mac seems to start client programs in virtual mode
instead (but not mapping memory 1-1, so the above hack probably doesn't work).

In order to compensate for this, you probably have to study how the mapping is
set up by the firmware.

On the other hand, looking at it again, I think that the boot code should
work independent from the setting of virtual vs. real mode, and even from
the setting of the IP bit in the MSR.  It should only matter for the kernel
itself.

Since the boot code doesn't output anything to the console (does it?), it
looks more like it dies way before the place where this comes into play.
Thinking about it, it might be a different way for a client program to call
into the firmware?

You probably should try to somehow get into the firmware just after loading
ofwboot, or better yet, just after ofwboot has stored its arguments somewhere
known.  Not sure how to do that with Mac's firmware though.

Sorry for not being more help here :-(.

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