I'm trying, with the help from Ian Molton, to install Linux on my Toshiba e800 PDA.

This is where CE 2k3 stops, the calibration step:

Useless to say that my device is unusable in the state. I had to do something about it. There was one and only one option in my opinion: run Linux, of course!

Lots of information was gathered from: Linux on the Toshiba e-series PDAs and sub-pages, most notably the "debricking" page.

• First, unplug the battery.
• Next, remove all screws you can come to sight.
• Then, open up the case:
  • The silver-looking sides are clipsed to both the front and back of the case.
  • Gently lift the back of the case from the bottom. Don't go brute force!
• You can gain access to the JTAG pads by removing the black, thick plastic band on the left side of the PDA (when you looking from the rear), next to the WiFi (or BT) module.

I've had a 9-pin ribon cable soldered on the PCB (by a colleague of mine, I tend to be clumsy with small things):

Left of the picture is the top of the PDA. The JTAG connector is on the PCB, right in front of you, covered by a solid thick plastic band.

Here's the pinout for the JTAG pads, when looking at the PDA as in the picture above:

• Now, you can close the case. This is what I get:

• Build your parallel port adapter as per Ian's instructions (it is a simplified and fully working version of a Xilinx DLC5 JTAG Parallel Cable III). Here's the one I build:

Again, Ian has done most of the needed job to drive this adpater from software. See there for how to get the software.

Here is a typical bsrflash session that dumps the first Mebibyte from the flash:

# bsrflash r dump.bin 1048576
Probing available busses... Intel PXA255 A0
c8026496
Probing for devices... Found Intel K3 strataflash in 2x16 bit mode.
Reading data:  000eb154 / 000ffffc

On my computer (x86_64 at 2.2GHz), reading 1MiB takes 30min. Yes, you read correctly: thirty minutes! This is roughly 583 byte per second. So, 32Mib take 16 hours!

If you get something like the following:

# ./bsrflash r dump.bin 1048576
Probing available busses... Intel PXA255 A0
c8026496
Probing for devices... No devices found.

then you are not fast enough. After the PDA has been powered on (using the hard reset slidder, at the bottom), you have a window of about 1 second to run bsrflash, or the WinCE loader will kind of rellocate the flash so that it is no longer available at 0x0 (we still have to figure how it does that, and how to work around this feature).

When dumping the flash, Ian suggests that you dump it a second time and cmp(1) the two files to check for transfers glitches (JTAG has no CRC or whatsoever). If they differ, then:

1. check cabling:
   • a parallel cable (from adapter to PC) longer than 1m could be problematic (mine is 80cm),
   • a long JTAG lead (from PDA to adapter) could also cause grief (mine is 30cm),
   • all in all, try keeping the total length below 1.5m;
2. dump a third time:
   • if two of the three files match, then those two are most probably OK (the odds that two consecutive reads give the same error at the same address is low enough),
   • if the three files differ, then you really have a cabling problem;
3. Ian and I came up with a set of patches to make bsrflash more robust; apply them all in order:
   1. 100-debrick-bsrflash_null_pointer_dereference.patch.txt
   2. 200-debrick-bsrflash_prepare_multiple_reads.patch.txt
   3. 300-debrick-bsrflash_multiple_reads.patch.txt
   4. 400-debrick-bsrflash_truncate_existing_dump_file.patch.txt

If you applied the patch set above, then usage of bsrflash changes when reading the flash:

bsrflash r <filename> <size> [samples]

where samples is the number of identical and consecutive samples of a single address that are required to validate that the data at this address was read successfully. 2 is most probably enough, 3 is my choice, while 4 and above may be overkill (but acceptable if you dump a small size). Setting this to 2 will double the download time; setting to 3 will triple it; and so on… Defaults to 1.

Here is an example of the new usage:

# bsrflash r dump.bin 1048576 3
Probing available busses... Intel PXA255 A0
c8026496
Probing for devices... Found Intel K3 strataflash in 2x16 bit mode.
Reading data:  00000fb8 / 000ffffc : read error, retrying
Reading data:  0001d870 / 000ffffc : read error, retrying
Reading data:  000eb154 / 000ffffc

UPDATE 20080131 Ian has commited the 4 changes above into his GIT tree.

<box round red 640px|WARNING> Do NOT try to use the bootloader without prior confirmed JTAG access!
If you use it on your device and it breaks, don't come moaning and whining, neither Ian nor I will be held responsible for the breakage.
Once you decide to replace the original bootloader by APEX, you're on your own.

You've been warned. </box>

We are using APEX as bootloader as an initial attempt at having a fully open source bootloader. We may end up porting a more common bootloader (namely, U-Boot) once we master the boot sequence and hardware initialisation.

For now the APEX port to the e800 is very alpha. Here is a table of the status of some important items, somewhat in order of importance:

For the adventurous, the port is on-going in the ymorin_e800 branch in Ian's GIT cloned tree. I'm pushing there whenever I have some interesting stuff done.

We'll eventually push back to the original APEX GIT tree once we are stable enough.