SPI FLASH Recovery for XO-4 Using CForth
If you have an XO-4 that will run CForth but will not run OFW, possibly because you are a firmware developer and have installed a test version whose OFW component is horribly broken, you can load a new version of OFW into the SPI FLASH from CForth.
This is only possible if the CForth installed on the laptop properly initializes memory! If it doesn't you will have to use SPI FLASH Recovery for XO-4 Using JTAG, or play around with the memory configuration parameters manually to fix the problem before proceeding with the rest of these instructions...
Attach a serial port to your semi-dead XO.
Make sure your serial terminal emulator supports binary mode downloads, or use another method to ensure the data is sent untranslated:
- for screen, use pv or cat in another shell, see below,
- for Minicom, use a binary transfer plugin, see below,
- for TeraTERM, check the Binary option in the Send File dialog.
Get into CForth by holding down the rotate key and powering on. The ok prompt will appear.
Manually configure DRAM and the SPI FLASH, then prepare CForth for receiving the ROM image over serial:
ok late-init .spi-id ok 0820.0000 0800.0000 do key i c! loop
Now send the ROM image in binary mode. The ok prompt will return once the exact number of bytes has been received. The serial download takes just under 4 minutes (2 MiB at about 10,000 bytes/second). If the download is taking much longer than 4 minutes, check to see if your terminal program adds "pacing" delays after each character. Pacing can make a large download take *forever*.
Now write the OFW part of the ROM image to the SPI FLASH:
ok 0802.0000 1d.0000 2.0000 reflash
The reflash step takes about 20 seconds. The ok prompt will return.
After that finishes you can power off and back on, and hopefully your machine will work.
This does not erase or change the manufacturing tags.
This recipe reflashes only the portion of the FLASH that contains OFW, leaving the (already working) CForth portion alone.
Reflashing OFW and CForth
You can reflash the whole thing if you prefer, but I tend to be conservative in this state, not wanting to risk screwing up CForth. But for completeness, here is the recipe for reflashing the whole thing. Only the last command is different.
ok late-init .spi-id ok 0820.0000 0800.0000 do key i c! loop <Send a rom image file, e.g. q7b03.rom, over serial, in binary mode> ok 0800.0000 1f.0000 0 reflash
As above, this does not affect the manufacturing tags.
Testing Manufacturing Data Reset Conditions
To test the firmware response to erased manufacturing data in SPI FLASH:
ok late-init .spi-id ok 0800.0000 1.0000 ff fill ok 0800.0000 1.0000 1f.0000 reflash
Using Screen and pv
First, install screen and pv:
yum install screen pv
Now start screen and talk to CForth with it:
screen /dev/ttyUSB0 115200
Prepare CForth for receiving data as described above.
Then, in another terminal window, send the data using pv, which provides transfer progress:
pv --force -i 0.25 -B 128 q6c04.rom > /dev/ttyUSB0
or cat, which gives no progress indication:
cat q6c04.rom > /dev/ttyUSB0
Proceed with the reflash step described above.
Using Minicom on an XO
First, install minicom and pv:
yum install minicom pv
Now install the binary transfer program:
wget http://dev.laptop.org/~wad/bin-xfer chmod a+x bin-xfer
Thanks to Danny Sung at http://www.dannysung.com/wmain/linux/tips/sending-binary-files-via-minicom/ for the script.
Attach a USB/serial adapter, and set up minicom to use it:
olpc-nosleep sudo minicom -s USB0
You will need to change the serial port to be /dev/ttyUSB0.
You also need to change the “File transfer protocols”. You can add a section there called “binary”, point it at your file, and specify:
- Name: Binary
- Program: /home/olpc/bin-xfer -o %l
- Name: Y
- U/D: U
- FullScr: Y
- IO-Red: N
If you placed bin-xfer somewhere other than your home directory, don't forget to use the correct pathname! Save the configuration.
To send the binary file, type CTRL-A s and select Binary mode.
See also http://dev.laptop.org/~wmb/bin-xfr.c