Just a note here:

I have documented how I installed Blob & Linux on my TuxScreen, some people may find this information more concise than what is available elsewhere within the wiki. The ARM CPU board from the Tux makes for an interesting stand alone system.

Information & schematics are on: http://www.openhardware.net/TuxScreen/

Something else to keep in mind.. I "bricked" a Tux while attempting to install a blob image that was > 32K (39532), this was while using inferno. Since 32768 is a "magic" number (0x8000), it is entirely possible that Inferno has a bug of some kind an will fail on these larger images. Luckily, I had a JTAG dongle. BTW: I have installed blob before on 6 other units without a hitch (all < 32K images).

TomW March 18, 2002

OK, so you've just got your nice shiney phones, and unpacked them from their boxes, you've plugged one in, switched it on, and discovered the Inferno software. Quite nice isn't it :)

What do you do next?

Well... you can start off by playing with the shell that's built into inferno... You just have to type pi in on the numeric keypad built into the phone. More specifically, you type...

##314159265359**

You have a little play with that, and get bored... You have a read of http://www.csh.rit.edu/~shaggy/shannon/index.html and learn that the TuxScreen is also known as a Shannon, or a Phillips IS2630. Then you decide to install linux.

The first thing to do is to get yourself acquainted with sboot. sboot is the bootloader that's on the TuxScreen by default. You can get into sboot by pressing the reset button on the back, and then pressing Escape on the IR keyboard whilst the Phillips logo is fading in at the start. Then you need to press CTRL-P.

TheKernel was messing with some of this stuff and got stuck in a loop where it would go into a screen that said "Downloading Software" instead of booting correctly. It would never dial right and hitting cancel would reboot and go into a red screen whose point was to tell me that all was not quiet on the western front. A reboot would just go back to the first screen in the loop. It wasn't going anywhere until I hit ESC (like above) followed by pressing '2' on the keyboard as explained on SoftwareDownload.

Here's the docs for sboot... probably worth a read... http://www.vitanuova.com/inferno/man/10/sboot.html

OK.. running sboot on the console is all very nice, but not much use if we want to transfer new files across into flash. sboot also talks some strange protocol to the inferno development environment. You need to follow the steps listed in InfernoRemote to establish a connection to the Tuxscreen. (N.B. You don't need the linuxemu.gz if you're on a windows box).

Right... now you've got a remote connection to your tuxscreen working.. and you're almost able to flash it now... except for one thing.. The flash memory is write protected, and in order to unprotect it, we've got to temporarily provide a 12V supply to the PCB. (This is a one time only thing). This is documented in FlashUnlock . A quick synopsis of the procedure is as follows:

• Add a 12V supply to the PCB by whichever means you see fit (I soldered on two wires onto the pads) (Don't actually apply the +12V yet, just connect the ground)
• Connect up to the TuxScreen with the inferno software on the PC
• Type P/m to list the partitions
• Connect the 12V supply
• Type P/u 0 to deprotect the partitions
• Disconnect the 12V supply
• Type P/m to list the partitions - all the numbers in the last column should be 0 now.
• If the numbers in the last column are not all 0, then the flash is not all unprotected, You need to repeate the above four steps again (i.e. reattach the 12V, and do the P/u 0 again, and then disconnect, and then check with P/m again etc...) (I had to repeat these steps three times before all my numbers became 0)

JCWren adds on 2002/10/20: In case the bit about the +12V is confusing, you will need an EXTERNAL 12V supply. When I first read this, the +12V on the one pad was a little unclear. For some reason, I was under the impression that this WAS the +12V supply, and would need to be jumpered somewhere. You can use a regulated bench supply (do NOT use a 13.8V supply, this is outside the specs for the FLASH part), a stack of 8 1.5V batteries (I believe RadioShack carries a AA battery carrier that holds 8 cells), or even the 12V off a PC power supply. Note that there is no 12V available anywhere on the phone itself. As everyone else has said, make sure the ground (GND) lead is connected first. You can leave it connected throughout the entire process, connecting and disconnecting only the 12V.

Now we're onto the scary part.. replacing the bootloader.

Get the latest blob image from the http://tuxscreen.net/download/ and check the md5sum. Move this file into wherever you installed inferno (in my case, C:/inferno/)

JeffTickle adds: I would like to stress the importance of getting an older blob image that is <32K, because as noted above, Inferno seems to dislike the larger blobs. I bricked my TuxScreen trying to install blob v0.6 which is 41K.

SquarT adds: The newest blob (20020709) in v0.6 seems to be 31.2K, so I assume I can safely use this. Update will follow when I have tried to do this. Indeed, it works like a charm. I couldn't connect with minicom (oh no, I bricked it!), but I could with HyperTerminal. I probably don't understand minicom or something :-). HyperTerminal is uploading the new ramdisk at this moment...

If you want to back up the current inferno image, you can use

c F!all D!inferno.backup

This will copy the contents of flash on the Tuxscreen into a file in the root inferno dir.

Now in the inferno console on the PC, type the following

c D!blob F!all

KenRestivo adds: if you are using a RedHat system, turn kudzu off! Kudzu probes your serial ports, doing PnP-like stuff. That just can't be good in this situation. The file will transfer across to the TuxScreen, (you can see the progress on the bar at the bottom of the TuxScreen Screen), and then inferno should come back with ...

flash: 0-7fff: erasing/writing... flash: erasing boot area! (0-7fff) <58?><terminal mode>

CarlWorth adds: When I did this I had slightly different output: "<7c?><terminal mode>" followed by a long line of garbage then "<rdp mode><sending reset>" and at this point the inferno process seemed to hang. But, not to fear, everything still worked just fine!

JCWren adds on 2002/10/20: When I did this, nothing appeared after the 'flash...(0-7fff)' message. I waited a minute or two for good measure, cancelled out of Inferno using control-C (at a normal Inferno prompt, you can type 'exit'. I dunno about all this killall stuff being necessary), started minicom, pressed reset on the unit, and it came right up.

Now.. power cycle the TuxScreen Kill off inferno Start up a serial terminal at 9600bps

Press Enter..

Hopefully, you'll see...

Consider yourself LARTed!

blob version 1.0.9-hack
Copyright (C) 1999 2000 2001 Jan-Derk Bakker and Erik Mo
Consider yourself LARTed!

Well done... You've got a new bootloader

The following procedure is not completely correct anymore with the newest blob. Here is what changed:

• Blob is now always running at 115200 baud n-8-1
• Blob now receives files using XModem (with the command 'xdownload' at the blob prompt, note that 'download' is now unavalaible). For example, to transfer a ramdisk, you simply have to type 'xdownload ramdisk', and then blob will wait for the XModem transfer to begin. You can use whatever terminal you like which have XModem support (minicom obviously does, and HyperTerminal does too).
• The kernel is now embedded in the ramdisk, which means you won't have to upload a kernel, most of the time; it's already included in the ramdisk. So you just have to 'xdownload ramdisk', then 'flash ramdisk' (preceded by 'erase ramdisk' if necessary), and you're ready to go.

TimRiker adds:

Now connect to the phone from minicom at 9600 baud n-8-1 no handshaking. This means no software (XON/XOFF) or hardware (CTS/RTS) flow control. If you leave hardware flow control on you will not be able to type anything into blob.

Boot the machine, and stop the autoboot or wait for it to fail. Note: newer versions of blob run at 115200 all the time so you may be able to skip the baud rate switching below. Type

download kernel

switch minicom to 115200 baud. In another window without exiting minicom type

uuencode zImage foo > /dev/ttyS0

as it progresses you will see dots in the minicom window. When it finishes switch minicom back to 9600 and type

flash kernel

again, there are dots as it progresses. When that finishes do the same for the jffs2 root filesystem by sending ramdisk.

download ramdisk

switch to 115200 and in another window without exiting minicom

uuencode rootfs-*.jffs2 foo > /dev/ttyS0

switch to 9600 then

flash ramdisk

then just type boot to get into linux!

KenRestivo notes:

NetBSD was a lot happier when i did cat rootfs-*.jffs2 | uuencode - > /dev/tty00

On M$ Windows you might need some WindowsTools.

FvGestel tried the M$-way using cygwin, with negative results; it seems cygwin doesn't allow two processes to open the /dev/com1 device simultaneously. Linux under vmware worked fine though...

DevinCarraway observes:

it's not really necessary to solder wires onto the flash lead pads to unlock the flash -- you only need 12VDC once, for a fraction of a second. It's much quicker to get the TuxScreen into debug mode with InfernoRemote happening and the SODIMM removed, flip it over, run "P/u 0" in sboot, then touch the wires you would have soldered to the pads. I used a couple of patch cables with alligator clips attaching the probes from a multitester to the P/S, which worked out conveniently when unlocking a few tuxscreens in quick succession.

StephenH adds (regarding Windows) 4/25/2002:

I used WindowsXP and CygWin to reflash my TuxScreen-- after doing InfernoRemote. I used HyperTerm to issue commands to blob and CygWin to encode and throw binaries at the blob:

• Use DeviceManager to set-up your COM port. I used "115200 8-n-1 none". I use COM1 where you might be using another COM port.
• Open HyperTerm and connect it to COM1. Ensure your talking to blob.
• Open a Cygwin session. Navigate to the directory where the kernel & ramdisk images are kept on your hard drive.
• In HyperTerm: "download kernel" and hit enter. Blob now gives you sixty seconds to start a trasnfer.
• In HyperTerm: Do a menu "View->Disconnet". HyperTerm releases the COM1 port.
• In CygWin: "uuencode tuxscreen-kernel foo > /dev/com1" to begin the transfer. Nothing will seem to be happenening, but if you watch your CPU utilization it may help you feel comfy that something is happening. Cygwin will eventually finish writing the uuencoded stream to the COM port and return from the uuencode comamand. At 115200 this took about 6 minutes or so. Also, be sure that you have the 'foo' in the command.
• In HyperTerm: do a menu "View->Connect". Your now talking to blob again. This will not work while uuencode is still doing it's business, which is a good thing.
• In HyperTerm: "flash kernel". This takes a couple minutes or so.
• In HyperTerm: "download ramdisk".
• In HyperTerm: do a menu "View->Disconnect"
• In CygWin: "uuencode tuxscreen-image.jffs2 foo > /dev/com1". It seemed to take about 10 minutes or so for CygWin to come back.
• In HyperTerm: do a menu "View->Connect".
• In HyperTerm: "flash ramdisk"
• In HyperTerm: "boot"