end of a XO-1

[Jecel Assumpcao Jr.]

I hope this isn't completely off topic for this list. My idea is that
posting this report here might be useful to someone in the future
searching for related information.

Back in 2008 I bricked my XO-1 B2 (128MB) machine by upgrading to a
firmware that was incompatible with it. The original firmware didn't
have the commands needed to boot SqueakNOS and I wanted to play with
that system. I downloaded the needed software (spiflash.dic) and
firmware (q2c27.rom) to fix the problem and opened up the machine. The
serial connector CN24 was missing, but I made a five wire cable from an
old floppy cable and my brother-in-law, Fred, carefully soldered the
wires to the missing connector's solder pads on the board. The plan was
to use the IDC connector at the other end of the cable to connect to a
Xilinx ML401 FPGA development board configured as a serial adaptor.

I was using the FPGA board for another project and only got around to
trying to fix the XO-1 last week. The XO-1 was also missing the Recovery
Mode Jumper Block (CN31) so my father taped a small piece of metal
shorting all four solder blobs. I checked that the FPGA was generating
65MHz for the EC chip and using a serial terminal application on the PC
I could see that characters typed on the PC keyboard were reaching CN24
on the laptop.

Plugging in the laptop's power brick (with no batteries) made the
message "213423:SCI:40" appear in the terminal application (the first
number wasn't exactly that and changed a little each time - it was some
kind of time stamp). Unplugging caused a similar message. Eventually I
noticed that pin 1 of CN24 is supposed to be 3.3V from the laptop to the
serial board and not from the serial board like I had thought. I
reconfigured the FPGA to stop sending 3.3V on that pin and now the
message would only appear when plugging in the laptop and random noise
when unplugging.

Pressing the power button generated about five more messages and then a
<cr><lf>"M" heartbeat message every two seconds or so. Running "./forth
spiflash.dic" didn't yield the desired results because the program
thought that 0x0d was the SPI FLASH ID, which was invalid. Trying more
times would get 0x0a, 0x4d and back to 0x0d as IDs, all invalid.

I suspected that the KB3700 was operating in normal mode instead of ISP
(programming) mode. So I removed the metal short from the solder blobs
at CN31 and verified that two of the diagonal pins were ground (I got
about 1 ohm) and the two opposite diagonals were KB3700 pins (about 100
ohms to ground). I expect these would be TP_ISP_MODE (pin 54) and
TP_CLK_TEST (pin 48). Without the short the behavior was exactly the
same as before. We tried to use two screwdrivers instead as short
circuits but couldn't get anything that looked like an ISP mode.

At one point the laptop failed to turn on and the EC chip no longer sent
any messages to the PC. The 12V from the power brick was still good and
the 65MHz from the FPGA board was the same as before. It is very likely
that the EC died, though it could also be some part of the internal
power supply. We unsoldered the cable and closed up the machine. It can
still be a nice static display in some museum.

I can think of two possibilities for the failure to program the ISP
flash. The first is that the EC chip was not in ISP mode. Given how hard
we had to poke the solder blobs with the multimeter probe to see which
ones were supposed to be ground it is likely that there was a layer of
something on top of the blobs (even though they still look shiny) that
was causing bad contacts. The alternative is that the EC wasn't
receiving commands from the PC because of the 65MHz ripple on the RX
line. It looked pretty bad on the oscilloscope (nearly 1V peak to peak)
but serial ports are sometimes surprisingly robust.

-- Jecel