TuxScreen on SourceForge TuxScreen CVS search the Wiki
Browsing -> Wiki -> Users -> [BlobTerminalServer]
Google
Topic:
edit, info, topics, orphans, hubs and nodes, or recent changes in the Wiki create a new user or login

I have two TuxScreens, with 2 serial ports each, plus a couple embedded Atmel AVR-based boards, each with serial ports. I keep them all locked away in a server closet during development, because if I leave any interesting-looking projects out in the open, my daughter will toddle over and rip them apart, pulling out wires, carrying them off, etc. I was using a PC for serial communications and constantly switching its two serial ports around, but this quickly became unbearable and so I trotted down to WeirdStuff and bought an ancient TerminalServer for $50.

The first thing I had to do was change /etc/inittab to launch the serial getty at 38400, since the old UARTs on the terminal server quickly revealed their inability to handle 115200 (framing errors, garbage chars). No prob.

I had a while ago gotten a hint from the TuxScreen mailing list that I could flash kernels over NFS, simply by mounting my development tree from the tux, and doing a "cat tuxscreen-kernel > /dev/mtdblock1". Much rejoicing and kernel hacking ensued, as I no longer had to deal with blob, slow serial comms, and uuencoded files. Flashing new kernels is now totally painless.

So I edited buildroot-tux/sources/linux.config to use 38400 instead of 115200 for serial comms, rebuilt the kernel, and flashed it. All good, now my console and kernel boot messages were showing up fine via telnet at 38400.

Finally, I had to hack the blob BootLoader to use 38400 baud too. This was easy: I grabbed the http://www.tuxscreen.net/download/v0.4/buildroot-tux.tar.gz and built it. I hacked the blob (2.0.4) to change the default terminal and download speeds to 38k4 instead of 115k2, rebuilt, and held my breath while re-blob'ing (cat tuxscreen-blob > /dev/mtdblock0). The tux booted just fine with the 38400 blob.

I have my kernels configured to use the SysReq key, so I then changed the terminal server port to pass the "break" signal through. All was now well, I could remotely un-wedge or reboot the tuxes, get boot messages, and have a root console. All done, except....

Using the terminal server left me with no way to re-flash jffs images (what blob calls a "ramdisk"). I can't just write to the mtdblock2 device while it is mounted (I don't know exactly what would happen, but, I'm pretty sure that, as Harold Ramis said in Ghostbusters, "it would be bad"). PivotRoot would probably work (just unmount the flash after the thing pivot-roots), but I haven't tried that yet. Besides, I needed something that would work with my other embedded gadgets that have bootloaders on 'em, too.

So I decided to find some way to upload an ascii-encoded file from within an interactive telnet session.

How I solved this is described here, along with its source code: http://www.246gt.com:8030/projects/tuxscreen/hacktelnet

To summarize in case that site is too slow or down: There are probably much better ways do to this (i.e. kermit, etc.). But what I did was to hack busybox telnet to accept 2 filenames on the command line, and, via an escape command, dump them to the open network socket descriptor. That's all.

Yes, it's slow at 38400, but it works.

SourceForge Content of these pages are owned and copyrighted by the poster. SourceForge