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 _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel