After suspecting that I had killed both my production and spare SPARCstation-10 motherboards, it is time to prove it one way or the other.
For SPARCstation-class machines, there is a handy trick that can be used to prove the main memory bus, the memory-controller, the CPUs, the basic “aliveness” of the on-board peripheral devices, and SBus plug-in cards: the serial console in firmware-debug mode. This spits a *lot* of self-test messages to the serial-port (at 9600 baud 8n1), even ultra-low-level tests of eg: “is the CPUs on-chip TLB storing, returning, and searching for entries correctly”, is the CPU-module cache-RAM working properly, are the hardware page-table-walkers working, etc. Extremely comprehensive, these identify any failing (or partially-failing) CPUs, DMA controllers, main memory MMUs, I/O-MMU, SBus devices, memory DIMMs, and so on.
Getting into Firmware-Debug Mode
The standard way to get the SS10 into firmware-debug mode: hold down the “Stop” and “D” keys on the Sun keyboard whilst powering up the system. Obviously, this won’t work if the keyboard is busted (or missing!) or if the keyboard UARTs or EBus on the motherboard are not working…
But there is another way to force firmware-debug mode – remove the NVRAM chip (the one with a barcode sticker on it, and mounted in a plastic DIP carrier) before powering-up.
Of course, to see the test/trace messages, you will need to connect a serial terminal (or terminal-emulator) to the SS10 serial-port via a “null-modem” cable. Although I used to have null-modem RS232 cables coming out of my ears, I have not needed one in anger for a few years and don’t seem to have any around any more; so I had to make one by rewiring a “straight-through” RS232 cable.
Trace Messages from Production Machine
Let’s see the results from the “production” SS10 (with HyperSPARC CPUs): (10-minute video). Hey, it is still alive, takes a while to come fully “up”, and can’t “see” the keyboard, but once it has booted fully, can access it over the network! Phew!
The problem of not “seeing” the keyboard is most likely due to the slightly iffy cable-socket on the keyboard itself: after being detached/reattached hundred of times over the last 20 years, the pins in the cable plug don’t always quite connect to the conductors in the socket. Takes a little bit of wiggling sometimes. Well, it’s either that or the secondary Zilog 8530 UART on the motherboard is busted, but given that everything else is working fine, I suspect that the problem is the keyboard socket.
Trace Messages from Spare Machine
To prove the death or otherwise of the spare machine (with SuperSPARC CPUs), I swapped-in the PSU from the production machine: (another 10-minute video). Hmmm, that one is alive as well, although it has a dead battery in the NVRAM chip (does not stop it from booting manually, just delays things whilst the firmware figures out that the NVRAM contents are corrupted). Phew again!
Of course, the next step is to see what we get when this spare SS10 is running off the new NV1-based adapted PSU… does *that* really work?