[rescue] SPARCstation 1 boot woes

[David McMackins II]

Thanks for the info about the addresses. That makes sense.

As for booting SunOS, that was the first thing I ever attempted to boot
on this machine, and I got the same symptom. For that, I made a boot
floppy from Linux just using dd. However, I have no way of knowing if
it's a good image or if I needed to do anything special to make it play
nice with the SS1. This was SunOS 4.0.3c.

I do also have a CD image of SunOS 4.1.4 which I think I also tried.
The SS1 doesn't have a CD-ROM drive, but I stole one from my Sun Ultra
2 and connected it to one of the SCSI ports meant for hard disks. I
can't remember if it was SunOS or NetBSD or both that I tried from CD.

I'll give it another try from floppy some time soon and at least have a
look at the trace.

-- 
Regards,

David E. McMackins II
www.mcmackins.org

On Mon, 2025-11-03 at 03:19 +1100, Ethan Hawke wrote:
> > 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
> 
>