|TuxScreen on SourceForge||TuxScreen CVS||search the Wiki|
|Browsing -> Wiki -> Main -> [InstallingLinux]|
|edit, info, topics, orphans, hubs and nodes, or recent changes in the Wiki||create a new user or login|
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...
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:
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
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
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 ...
CarlWorth adds: When I did this I had slightly different output:
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
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:
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
switch minicom to 115200 baud. In another window without exiting minicom type
as it progresses you will see dots in the minicom window. When it finishes switch minicom back to 9600 and type
again, there are dots as it progresses. When that finishes do the same for the jffs2 root filesystem by sending ramdisk.
switch to 115200 and in another window without exiting minicom
switch to 9600 then
then just type
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...
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:
|Content of these pages are owned and copyrighted by the poster.|