>> 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?

The attempt in which I changed the MSR, I added a line of assembly in
initppc() just before the for loop which sets the trap vectors.  I then
compiled the kernel, and converted it to an xcoff to boot it directly (w/o
ofwboot).

That ofwboot died even before outputting anything tells me something is
REALLY wierd here.


>> 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 :-(.

Ahh.  I was reading the specification a little last night and firmworks
said their implementation provided a nice method for debugging assembly
startup code...but somehow I'm not surprised Apple missed that.


>> 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.


So, let me clarify something.  If a default catch were to come up, by the
kernel doing whatever it's doing, would your open firmware print "DEFAULT
CATCH 00000400" (right address?) and continue?  In which case just gotta
play with it some more - perhaps init that vector in locore instead of
initppc....


>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.


To my inexperienced eye, yes, it should.


>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?


Hmm.


>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.


Seems unlikely....


Now, here's the thing.  In the special .note section in ofwmagic.S, I seem
to recall a setting that was supposed to force the OF into using the proper
mode.  Is Apple ignoring that?



Also.  Where can I find a good piece of Open Firmware documentation?
Besides linuxppc that is.  I would like to play around with this but I
can't even remember the command to check the properties of a device in the
user interface...Apple DOES do at least that much.


I'm going to check their tech notes meanwhile - I recall their's nothing
useful, though.



Well, linuxppc can do it - so can we!


Dan.

---------------------------------------------------------------------
| Dan Jacobowitz                 | drow@drow.net                    |
|  Administrator Extraordinaire  | Web site coming someday          |
| My opinions are my own -       | Day Job: http://www.wwwcomm.com  |
| My mistakes are someone else's |                                  |
---------------------------------------------------------------------