[rescue] SPARCstation 1 boot woes

[Mouse]

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

> It looks like the program is transferring correctly with an offset of
> 32 bytes.

32 is probably the size of the a.out header, though the first 32 bytes
of your hexdump don't make sense from that perspective.  Assuming
(based on the filename) that it's the 1.4T boot.net I sent you, it's a
canned sequence coming from somewhere I haven't bothered tracking down
in 1.4T's build infrastructure:

  0 05:41:50.04 dependall ===> sys/arch/sparc/stand/boot
...
  0 05:44:47.60 (printf '\01\03\01\07\060\200\0\07\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0'; cat boot ) > boot.net

presumably chosen to more keep the network boot code happy than for any
other purpose.

> I don't know sparc assembly, but I'm familiar with the basics of
> assembly languages, so I can follow a little bit.

It's a fairly boring RISC architecture, except for two possible trouble
spots: delayed branches and register windows.

Delayed branches.

After a control transfer, often, the instruction following the control
transfer instruction (in the "delay slot") gets executed before the
control transfer happens.  I say "often" rather than "always" for two
reasons: (1) some control transfers don't do this at all (trap
instructions, for example); (2) control transfers that _can_ execute
the delay slot instruction can be set to do so only under certain
conditions (typically marked with ,a in assembly or disassembly, a for
"annul").

Register windows.

The SPARC (32-bit - I'm discussing only 32-bit SPARC here) machine
language has five bits of register number, allowing naming 32
registers.  One of them (%g0) is, loosely, /dev/zero: it's fixed at
zero and writes to it are ignored.  Seven more (%g1 through %g7) act
like registers in a more conventional architecture, always accessing
the same register.  But the remaining 24 are bank-switched based on
stack usage.  The usual picture looks something like this:

----+---------+
... |%o0...%o7|
----+---------+---------+---------+
    |%i0...%i7|%l0...%l7|%o0...%o7|
    +---------+---------+---------+---------+---------+
                        |%i0...%i7|%l0...%l7|%o0...%o7|
                        +---------+---------+---------+----
                                            |%i0...%i7| ...
                                            +---------+----

Each row corresponds to a stack frame.  When the register windows are
shifted for a call (discussion below), the diagram is shifted down by
one frame, so %o0...%o7 ("outs") of the calling frame become %i0...%i7
(the "ins") of the called frame, with the previous %i and %l reigsters
becoming inaccessible until the inverse shift is done on the return.
(%l0...%l7 are called "locals", hence the "l".)

This window shift does not always happen on a call and can happen
without a call; there are separate instructions ("save" and "restore")
that drive it, which are often (but not always) part of function
prologue and epilogue code.  (Functions which do not do this are called
"leaf" functions and are usually restricted to use of just the %o and
%g registers.)

The chain is actually a loop, in hardware, with a mask register
indicating which windows are valid; attempting to save or restore into
an invalid window takes a window spill/fill trap, with the trap handler
responsible for moving between the windows and the stack.  Wikipedia
says that there may be "from three to 32" of these register windows in
any particular implementation.

I can go into more detail if desired.  I know the SPARC ISA well enough
to have written an emulator for it (userland only, but that covers most
of it), so I can likely answer any specific questions you may have.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse at rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B