Hoping there is a kind soul out there that understands this
machine a bit better than I do and is willing to shed some light. :-)
Albeit a bit off-topic, this seemed like a better place than netbsd-users.

I am trying to write an OpenFirmware client program to muck around
with the OFW device tree, so I simply had a look at sparc64/locore.s
and the ofwboot bootloader and imitated early NetBSD bootstrap.

After first initializing %pstate and making sure I have a v9 stack
I save the PROM entry vector. It ought to be in %o1 on entry; locore.s
says it's in %o0 but all the code assumes it's in %o4, so I saved %o4
too which does appear to contain an address which according to param.h
is where the PROM is usually located. I clear my BSS and jump to C-code
which calls a bunch of openfirmware client functions via an asm stub. I
pretty much copied the openfirmware function from locore.s. The result
is "Fast Instruction Access MMU miss". So I dump the registers and
notice PC is at address zero. I check the locals and see that
%i4 (which I jmpl to) does indeed contain zero. This is very odd,
since I do:

OpenFirmWare:   
        setx    __ofwbase, %o4, %o5
        ldx     [%o5], %o4
        save    %sp, -CC64FSZ, %sp

Now, %o4 should be %i4 after the save, but the code behaves as if
the ldx had a delay slot which of course it doesn't. Since I wasn't
sure what the PROM does to cpu state when I get a MMU miss trap
(this is well before I have installed any traphandlers of my own or
 even touched the MMU) I inserted an "unimp" instruction just after
the save, reasoning that this should at least guarantee that I am
still in the same register window, and the result is the same. %i4
is 0 and %o4 is f00535bc (or something...).

How the heck do I bootstrap this thingy (SUN U1/143, OpenBoot3.5)
far enough that I can call into the PROM? Judging from the
NetBSD locore.s (which -- since I'm typing this without problems --
appears to work just fine) I should be able to call into it as soon as I
enter the arena; bootstrap in autoconf.c initialises the PROM console for
printf before pmap_bootstrap and there are prom_printf:s while remapping
the kernel itself in order to install permanent mappings, so I assume
there's nothing special to it -- the prom should already be mapped
by the time the client program starts executing.


-- 
/ali
:wq