[rescue] SPARCstation 1 boot woes

[Ethan Hawke]

> Alright, I'm not entirely sure what I'm looking at in this call trace.
> I've attached a text document with the output as well as hex dumps at
> address 4000 and the beginning of the boot program file on the tftp
> server.
So ctrace shows each time a new stack frame is allocated after some kind 
of call/jmp
instruction.

Last leaf: jmpl  40    from 3826f4
      0 w  %o0-%o5: (   37fe18   38f400        1       40 ffffffff 
ffffffff )

"Last leaf" indicates this is a leaf instruction (so it cannot call any 
other function),
the address of this function is "40", it was caused by a "jmpl" 
instruction that was
at address "3826f4" from the previous function, it then lists the 6 
registers that
make up the function parameters, although not all 6 have to be used, any 
more
arguments will have to be passed via the stack, which is not shown by 
ctrace.

While the client program starts at 4000, the NetBSD bootloader 
(boot.net) will
copy itself to 380000, which is why the addresses start with 38xxxx.

The addresses starting with ffe are OBP functions.

The call to "40" is invalid and that's why the program is crashing.

> Do you have any guidance for me for following this call trace? I don't
> know sparc assembly, but I'm familiar with the basics of assembly
> languages, so I can follow a little bit. I'm guessing these are some
> register dumps down the calling stack, but these addresses are
> meaningless to me.
I don't have a SPARCStation 1, but I do have an IPC which is pretty similar
(running version 2.4 "Release 2.4 Version 362 created 91/04/30 10:59:04").
Mouse' 1.4T boot.net does work correctly on this machine.

However, my trace does not have the call to ffe80e8, in fact that 
function does
not exist at all on my OBP version, also (perhaps just coincidence) that 
call has
40 as it's first argument, the same value that the bootloader mistakenly 
jumps
to causing the crash.

In my case, the call to 381cc8 and 3816c0 also occur on my IPC, but the 
call to
381570 never happens in my case. And of course there is never a call to 
ffe800e8.

I am very dubious that there is any hardware fault with your SS1, but 
perhaps some
compatibility issue with the SS1/OBP and NetBSD. See if you can boot 
SunOS as a
sanity check.

Cheers,
Ethan