The Lost GPS Episode

This is an old tale, nearly lost to the shifting sands of time due to a peculiar practice in modern households known as "spring cleaning".  You might remember in an earlier episode when I confessed to a penchant for keeping notes on random scraps of paper, reserving the immense power of the computer for the final preparation, configuration, and publishing of said notes.  But my methods have a weakness.  Random scraps of paper notes strewn about bear a striking resemblance to garbage -- to the untrained eye.  And spring cleaning caught me by surprise this year, delayed as it was by a few months, thanks in no small part to the ferocious and lasting winter we'd so recently suffered through.  And so it came to pass that most of this tale now resides in a landfill somewhere, lost and forgotten.  I will however attempt to recreate the juicy bits from the #zipit IRC logs at mozzwald.com.

But first, a little background.  The humble beginnings of this sadly delinquent story first came about more than a year ago when I took a zipit on the road for a trip to Boston, intending to investigate it's utility as a travel laptop, alarm clock, and gps.  It worked quite well as an alarm clock, and well enough as a laptop, but my zipitized build of pspmaps made it truly a poor man's gps.  Emphasis on poor.  I'd already fixed up pspmaps to work with the latest google API -- now with JSON -- so I upgraded it further with some sorely missing features which you can read about here.  Then, as chance would have it, the clever folks on the zipit IRC channel got to chatting about some tiny serial gps modules.  So I did some searches and discovered the new breed of gps modules were much smaller than what I'd worked with in the past, which makes sense if you think about it.  And now you can get them packaged with the antenna built right onboard.  Nice!  Eventually I got motivated and purchased one for myself -- a tiny usb serial gps module (with built in antenna) to use in conjunction with pspmaps on the zipit.

 Here it is.  GlobalSat USB dongle Model No ND-105C.  Zipit included for size comparison.

The GlobalSat gps arrived in early May, last spring.  It's even smaller in real life than I imagined from the pictures.  And it's designed to spit out NMEA sentences once a second or so at 4800bps over usb serial, most likely to an android phone or a tablet.  But it's also exactly what I required to convince pspmaps to track the location of the zipit. So the first order of business was to get it connected it to my laptop and make sure it really worked.  The GlobalSat has a blinking red LED on one side to indicate that it has power and is getting fixes.  Red LED, check. Hold it right side up near the window and the LED blinks, check 2.  Next step, set the serial baud rate and see what's cooking.

stty -a /dev/ttyUSB0
stty -F /dev/ttyUSB0 4800
cat </dev/ttyUSB0

Yay!  NMEA sentences.  It works.  Hit Ctrl-C to make them stop.

So now we want to try it on the zipit.  You'll need an adapter to get usb out of the rear connector on the zipit.  If you can solder the tiny pins then you can make your own cable from the Hirose connector like the one shown in the picture above, or you can get a cool zipit breakout board from mozzwald while they're still available.  Once it's connected you have to load the kernel module and toggle the zipit usb  into hostmode.  If you have the latest openwrt jffs with mozzwald's zippity beep extras then you should be ok.  I borrowed the kernel and some nice scripts like /usr/local/bin/usbtog from the jffs image and loaded them on my openwrt SD card so I'd have room to build things.  Navigate to the gmenu2x terminals screen and open up a bash command prompt. 

Load the prolific usb serial module for this gps.

insmod pl2303

Toggle usb to device mode and then back to host mode.

usbtog d
usbtog h

Make sure the usb serial device was created.

ls /dev/ttyUSB*

Look around to see what's up.

lsusb

    Bus 001 Device 001: ID 1d6b:0001
    Bus 001 Device 003: ID 067b:2303

dmesg

    pxa27x-udc pxa27x-udc: USB reset
    USB Serial support registered for pl2303
    usbcore: registered new interface driver pl2303
    pl2303: Prolific PL2303 USB to serial adaptor driver
    pxa27x-udc pxa27x-udc: USB reset
    usb 1-2: new full-speed USB device number 2 using pxa27x-ohci
    usb 1-2: New USB device found, idVendor=067b, idProduct=2303
    usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
    usb 1-2: Product: USB-Serial Controller D
    usb 1-2: Manufacturer: Prolific Technology Inc.
    pl2303 1-2:1.0: pl2303 converter detected
    usb 1-2: pl2303 converter now attached to ttyUSB0

Now fetch a copy of picocom and run it to watch the NMEA messages scroll by.  If you're near a window you should be able to recognize the position fix messages.

picocom -b 4800 /dev/ttyUSB0

Press ctrl-a crtl-x to return to the console.  Once you've verified the gps actually works on the zipit you can get started installing some software to make better use of it.  Apparently gpsd is the defacto standard gps driver on linux.  It sounds really nice.  Supposedly it sets itself up between you and the raw NMEA messages and smooths over the wrinkles while making the data available to multiple multiplexed clients, even remote ones.  Cool.  You'll want to grab the specially patched version of gpsd for the zipit and install it with opkg.  Here's some additional reading on gpsd clients if you're curious.

When I'm testing things I usually open a second tty on the zipit with alt-right, load a smaller font like iz2slat and launch gpsd from there so I can see what it's doing and so I can talk to it from the original tty, accessible via alt-left.  I discovered early on that gpsd only seems to run from a real zipit tty.  Normally I ssh into the zipit to test things but that didn't work for this.  I also discovered that you must bring up the loopback adapter so you can talk to gpsd.

ifconfig lo up
gpsd -N -n -D 3 -G /dev/ttyUSB0

Now you can telnet into port 2947 on the zipit (from the zipit or your laptop) and send the command to make gpsd talk.

telnet localhost 2947
?WATCH={"enable":true,"json":true}

It should start jabbering away.  Use the IP address of your zipit instead of localhost if you want to try this from your laptop.

You can also run a special version of gpsd sample client program cgps, that I christened zgps, with all the extra whitespace squeezed out so that it fits on the tiny zipit screen.  This will print live fix information in a more human readable format than the raw JSON data you looked at earlier.  The modified zgps.c source code is available if you'd like to see what I did.

The zgps client shows you what the gps sees.

I also used another gpsd example client program gpspipe to make a nifty little speedometer script for the zipit that you can play with.  If you want to duct tape the zipit to your bicycle and still be able to actually read it while riding, then you'll need to find the nice large ter-132b.psf terminus console font somewhere, possibly in a full PC linux OS, and install it on your zipit.

The zipit is not currently moving at top speed.

And finally, the goal of this adventure, a special version of pspmaps patched to work with gpsd is available.  If you don't already have it, install pspmaps 2.4.2.  Then rename the pspmaps executable (just in case) and replace it with the gpsd patched version.  When you run it, there should now be a selection in the menu to enable the gps tracking.  The updated pspmaps source code is in my pspmaps github project.  Normally, I'd cap this part of the story off with a short shaky video of pspmaps tracking my progress along a local road somewhere.  It really did work, I swear, but unfortunately I haven't made that video yet.  Sorry.

So how did we get here?  The full story is faithfully recorded in the irclogs from early May to the middle of June.  Search for the word gps from user deeice if you want all the details.  I'll try to cover the highlights. 

When the gsp arrived, my first priority was to make sure it actually worked with the zipit.  That took some trial and error with the kernel modules and the usb host/data mode toggling business, but eventually I arrived at the recipe listed above and could see the gps talking and reporting NMEA location fixes in picocom.  The next step was gpsd.  The default openwrt-zipit package is the old and crusty version 3.6 gpsd, so I checked to see what version was in the current upstream openwrt packages.  I think that's how we settled on version 3.10.   Or maybe that was the version available on the zipit Arch linux.  I was mixing it up at the time, working on both openwrt and Arch, so who knows.  Anyhow, I got the newer gpsd compiled and running on the zipit and then got busy hacking the cgps code into a multithreaded demo that I might eventually shoehorn into pspmaps.  That took much longer than it should have because none of the gpsd client programs running on the zipit would talk to gpsd until I finally realized the loopback interface wasn't up.  Darn it!  Once I solved that issue, the rudimentary pspmaps to gpsd interface was coded up and working in no time.  And then we discovered the performance issues.

It turns out gpsd is littered with floating point math!  Ewww!  Also it does't appear to use blocking IO to read the NMEA sentences from the serial port.  Both of these issues were confirmed by scanning through the gpsd mailing list log file archives.  Apparently they've made various attempts to fix things over several releases but were not entirely successful, most likely because the zipit and other seriously underpowered devices are not in their target market.  So I set about trying to fix it because the enormous cpu drain of gpsd was clobbering the pspmaps performance. 

CPU is pegged at 80%.  Yikes!

For some reason gpsd wants to calculate its own "more accurate" location fixes from the satellite position data, using loads of floating point math, each and every time a character is received from the gps.  Or at least it might as well be.  The mailing list logs pointed to a NOFLOATS_ENABLE configure option that might alleviate some of the pain, but the option seems to have disappeared in the most recent 3.14 versions of gpsd, so libgpsd 3.10 version was selected and built with the NOFLOATS_ENABLE setting.  That made things marginally better.  Next I fixed the IO select call to block, but it still used too much cpu.  So I was forced to go with a simple hack to usleep for a fraction of a second  whenever we receive snippet of data from the gps.  That chunks the data up into larger clusters and gives the cpu some well deserved rest periods in between.  Pspmaps only looks at the fix data once a second anyhow.  That put the performance in the not great, but acceptable range.  I was looking for less than 5% cpu usage and we were getting something more like 20.

So I checked out some alternatives to gpsd.  There's an ancient version of gpsd hacked to use fixed point math for the maemo called minigpsd that looked at least slightly promising.  But further investigation showed the api was incompatible and insufficient, and even worse it made use of the enormous bloated gconf library for it's tiny config file.  WTF?  Even the gnome crowd seems to have abandoned gconf as a mistake.  I also looked at some interesting arduino code like tinygps.  But then I found what I wanted in the simple raw NMEA parser minmea.  It doesn't multiplex the gps data (as far as I know), but it does support fixed point math and my simple test program showed it only uses about 6% of the cpu (probably half of that is printing out what it's doing) so it's a winner.  According to the github pspmaps archive, I've already hooked this into the pspmaps code base along with the gpsd code, but I couldn't actually remember running any tests on pspmaps with minmea.  So I ran some tests and it really does work pretty much as I promised.  Yay.  I'm not sure how robust my code is if for example the gps is disconnected and reconnected later.  So I still need to do some follow up work here...

Also, I don't seem to have the faster gpsd installed on my zipit.  At least it doesn't act any faster than that screenshot above.  Phooey!  Gotta poke around on the zipit and see what happened to that.

I also need to tinker with using /etc/init.d to launch gpsd for better hot plugging.
And I need to locate (or make) the Arch executables for zgps and/or pspmaps.

The todo list goes on and on.  Time to find some random scraps of paper and get this down in writing...


Update January 25 2016:

Ok, I found the faster gpsd executable (with a tenth of a second usleep before the select call, and perhaps a few other unknown tweaks that I thought might work).

Significantly less cpu used by the patched gpsd.

Now I just need to figure out exactly how I created it so we can get it into a real ipk package.  Until then you can copy this one to /usr/sbin/gpsd and replace the one installed by the gpsd ipk.

gpsd-wrt-with-usleep.tgz


Update 2:

Actually, that might just be all there is to this story.  The gps was acting flaky recently, and now it won't talk at all.  I think the flimsy micro usb connector got busted somehow.  Oh well.

Update 3:

Nope.  I'm not ready to end this yet, so I ordered a cheap serial gps from sparkfun to keep the hope alive.  It's as simple as it gets for a serial gps in order to work around my limitations.  In theory, I should be able to connect the three wires (gnd, 3.3V, and tx) to the power, ground, and ttyS1 rx line on the zipit expansion port.  I already have 3 of the appropriate connectors with which to learn how to solder properly (or get someone skilled to do it).  The best part of this plan is that it should work with both iz2s and the current openwrt and arch zipit distributions.  At least, that's the plan.

Hmm, perhaps while I'm waiting for the package I'll try and use my serial to ttl converter to test that rx pin.  I know I've managed to get a clip onto one or 2 of those tiny pins in the past.

 See that?  I got 3 clips on the zipit connector for some gpio tests, way back when.

Update 4 - January 30 2016:

While waiting for the sparkfun gps to arrive, I figured I might as well check and make sure the whole expansion connector serial port idea works.  Supposedly pin 7 on the connector is labeled btrxd, and was originally intended as the receive line for a bluetooth serial port, which the kernel sees as ttyS1.  The bluetooth transmit and flow control lines are only available on pads inside the zipit and not exposed on the expansion adapter, but that's ok for my purposes.  Somebody at Zipit Wireless must've been thinking of me when they did that.  Anyhow, I compiled picocom on my iz2s zipit and created the ttyS1 serial device.

mknod /dev/ttyS1 c 4 65

Then I connected some clips to pins 7 btrxd and 22 gnd on the zipit connector and clipped the other ends to tx and gnd on a nokia ca-42 data cable that was hanging off a usb slot on my laptop.

Here's the wiring harness.  Ignore that green screw terminal dB9 adapter on the top right.

I then cranked up picocom at both ends and sent a friendly message to the zipit.

It's gonna work.


Update 5 - February 21 2016:

The axim cable arrived a while back but I was busy dog sitting and didn't do much with it for quite a while.

Little Edison probably thinks it's a chew toy, just for him.

Once there was no longer danger of interference from small doggies demanding attention, I got busy with the cable.

 Here's the axim cable with the lid removed.

It's well constructed for my plans.  The connecter is easy to disassemble with two screws and some small clips on the sides near the business end.  There's only 4 wires through the cable, but they're connected to about 13 pins.  In the picture you can can see some extra wires used to tie different blocks of pins together.  Probably all go to ground on the axim.

I've pulled a fistful of pins, all tied to the red wire.

I used my needle nose pliers to yank the blocks of pins, and then chopped off all but one pin from each wire with a toe nail clipper.  Hope it still works for my toes...  Then I re-inserted 3 of the pins back into the proper slots required to connect the gps to the zipit bluetooth serial pins.  My notes say I connected the green wire to pin 22 ground, black to pin 17 +3.3V, and white to pin 7 btrxd, reserving the red wire for "in case of emergency..."

The reassembled cable has just 3 pins, right where I want them.

The operation was something of a challenge because I only have 2 hands and can no longer see all that well up close.  Fortunately I discovered an old kids toy festooned with magnifiers and doubled up the 2 biggest lenses so I could see the pins and their slots.

Eventually the sparkfun gps arrived as well, you can see it in that last picture of the cable.  I will get it connected, but meanwhile, interest in my lego CAD programs has been rekindled briefly, so I'm going with that for now.


Update 6 - September 24 2016:

I did eventually return to this topic and finish the job.  You can read the final chapter in the zipit gps saga here.

Space Quest

The quest for space continues.  No, not the game -- although that might be a good excuse to compile ScummVM, since I never completed the mission in Space Quest 3.  But no, we're talking about my personal quest for free disk space here.  The goodie bag hasn't been updated in over a year, and my temporary datafilehost.com links were all fading away from lack of exercise.  A remedy for the situation was clearly long overdue.

I tried dropbox, and it works.  I fixed up the expired datafilehost links by moving them to dropbox, but the dropbox interface doesn't suit my style. Meanwhile mozzwald generously donated a directory on his server.  So I recreated the goodie bag there and started making updates for the more recent blog posts.

While this was happening, I also went off on a quest of sorts for free disk space in the openwrt jffs.  When you install the openwrt jffs from flashstock, the first thing you probably notice is the jffs performing poorly due to the lack of free erase blocks.  It's packed to the gills with good stuff, but there's no room to breathe.  Most of us end up deleting some big files (like streamripper) and moving them to an SD card instead, just to make it behave.  However there's actually plenty of wasted space on the flash, and I so finally decided to try and take some of it for the jffs.

Mozzwald's version of the openwrt rc23 jffs (with streamripper already gone)

My first target was the UBOOT Splash Image partition.  I don't know anyone who'd rather stare at a static image than the informative boot messages.  I want to see what's going on (or more often than I'd like, what's going wrong) when the thing is starting up.  Given a choice, I'm never gonna hide the boot messages behind a pretty picture of a penguin or somesuch nonsense.  So, for me the stupid empty splash partition was a total waste of 128K bytes of precious flash that by all rights should've belonged to the jffs.  That right there is just enough erase blocks to uncramp the jffs and allow a decent amount of customization.

Because the image partition is empty and contiguous with the end of the jffs, this turned out to be some low hanging fruit.  The kernel will automatically format the extra space as jffs when it boots.  Here are the steps to merge the uboot image partition with jffs.  Power up the zipit and quickly press a key to pause inside uboot at the uboot command prompt.  Then update the uboot environment to include a modified mtdparts setting in the bootargs environment variable.

printenv

setenv bootargs "console=ttyS2,115200 fbcon=rotate:3 root=/dev/mtdblock3 rw rootfstype=jffs2 mtdparts=physmap-flash:256k(uboot),128k(ubootenv),1152k(kernel),-(filesystem)"

saveenv
boot

Once openwrt is up and running, open up bash and confirm the new partition scheme, and the extra space in the jffs.

cat /proc/mtd
df -h

Enjoy the additional headroom.

Mozzwald's version of the openwrt rc23 jffs (with 128K recovered from bootsplash)

Now, at this point I got greedy.  Riding the high of easy victory I decided to go for the gold.  For the last three years I've been waffling over an existing uboot hack https://github.com/stratumnine/u-boot-pxa-zipit-env8k that carves out another 192K of flash from the uboot and uboot environment partitions. So I booted up the zipit with openwrt from the SD card and started making preparations.  First I fetched some tools for uboot.

opkg update
opkg install uboot-envutils

This only installs the fw_printenv binary so you have do do some legwork.

cd /etc
echo "/dev/mtd1 0x0000 0x20000 0x10000 2" >fw_env.config
cd /usr/sbin
ln -s fw_printenv fw_setenv

I decided to test the tools by stashing the MAC address of the zipit in the uboot environment.

fw_printenv
fw_setenv ethaddr xx:xx:xx:xx:xx:xx
strings /dev/mtdblock1 |grep ethaddr

I'm planning to use that bit with strings to (someday) make the MAC address match the zipit when I boot from an SD card.  It should work with both openwrt and arch SD cards.

Next I got the tools to tinker with the /boot/uboot.script uboot environment files we use when booting from the SD card.

wget http://mozzwald.com/zipit/uboot/z2uflasher_03222011.tar.bz2

Unzip it and copy mkscript.sh and mkimage.arm.static to openwrt sd card.  I used these to add mtdparts to the bootargs in /boot/uboot.script on the SD card and then rebooted the zipit from the SD card.  The kernel gave me an error because of spaces in the partition names, so I tried again without the spaces and it worked.  Now the mtd partitions when booting from SD matched the ones I got when booting from flash.  This meant I could relocate partitions when booting from SD.  So I thought I was ready.

I fetched the env8k-uboot.bin from stratumnine and examined it.  I verified the first instruction ea000ffe really does branch to 0x4000 in ARM asm.  The small 8k uboot environment is completely empty, which should be ok.  The rest of the file looks like code so I decided to go for broke.  Unfortunately I got impatient and rushed it.  I wrote to the character mtd device instead of the block mtd device and bricked the zipit.  Darn it!   Probably should've used the mtd program instead of dd, or maybe some of the other standalone mtd-utils (which are apparently packaged individually by openwrt), or simply modified the flashstock script which is already known to work.

 

Perhaps it's time for daddy to learn how to solder...

Update Jan 9, 2016:

Turns out the env8k-uboot.bin has a bug that renders it useless anyhow.  It's able to save changes to the uboot environment in the 8k sector, but it does't read the saved environment on boot.  So we can't add an mtdparts setting to the bootargs.  Also, the code on github doesn't have all of the changes required to make the 8kenv-uboot.bin file.  Additionally the uboot partition in this setup starts with six 8k blocks and ends with two 64k blocks, which appears to render the /dev/mtdblock2 device unwritable because there's no one size fits all erase block.  That's a nuisance, but not a deal breaker.  However, unless we find the code and fix it, the 8kenv-uboot is a dead end.

Not one to give up so easily, I retrieved from my archives a slightly older tiny uboot setup from stratumnine with a more conventional layout that's only 64k bigger than the 8kenv-uboot.  I modified my flashstock SD card by creating a new flashdump directory combining the tiny uboot with the kernel and filesystem from mozzwalds zipity-beeps flashdump directory.  Here's what's in the modified flash.def file.

u-boot-z2-tiny.bin 0 bae3dc47a78032e8c98990767743aaba
mtdblock2.bak 262144 374666a92397653c2dd5119b3270b2e2
mtdblock3.bak 1441792 26f82b88f912d44f6db1388141ad4fb4

I then booted the zipit from the updated flashstock SD card, selected my new option from the list, crossed my fingers and let it flash.  This time uboot started up just fine.  Yay!  So I quickly hit the enter key to interrupt it and fix up the environment.

printenv

setenv bootargs "console=tty0 console=ttyS2,115200 fbcon=rotate:3 root=/dev/mtdblock3 rw rootfstype=jffs2 mtdparts=physmap-flash:192k(uboot),64k(ubootenv),1152k(kernel),-(filesystem)"

saveenv
boot

Check it out!  500K free in the jffs.  Let's examine the partitions.

cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00030000 00010000 "uboot"
mtd1: 00010000 00010000 "ubootenv"
mtd2: 00120000 00010000 "kernel"
mtd3: 006a0000 00010000 "filesystem"

Next I saved the uboot environment and added it to the tinyuboot flashdump to make this all simple and automated.  But first I removed console=/dev/tty0 from bootargs.  That gets a bit annoying when it prints kernel messages all over your bash session.  Here's the final result.

tinyuboot-flashdump.zip

Unzip it onto your flashstock SD card if you want to try it.  It'll give you an additional menu choice of tinyuboot to write to flash.

In the flashstock menu.  More options to choose from.

I'm still undecided which way to go on the kernel messages so I included two backups of the uboot environment partition in the tinyuboot directory -- one with kernel logging to tty0, and one that only logs to ttyS2.  It's currently setup to use the the one that's quiet on tty0 because the openwrt busybox on the jffs backup lacks the setlogcons applet to change that at runtime.  But I don't really like the lack of screen updates during boot.  Makes me nervous.  So I might try just turning the log messages off in the openwrt init system file /etc/config/system.

config 'system'
    option 'hostname'    'engine12'
    option 'conloglevel'    1

So hard to decide...

Marking Time

I was about to call this post "Adventures in Failure", but then I remembered that I already used that title.  Oh well, at least I finally have something to write about again, even if it is mostly fail.

The summer of code started out on the right track.  I decided to take pspmaps to the next level, and bought a tiny inexpensive usb gps to attach to the zipit.  I made some great progress and someday I'll write all about it here, but not right now because I didn't quite finish anything to my satisfaction.  Before I got there, I inherited a beat up crate of old school vinyl records from the turn of the 70s that otherwise would've landed in a dumpster somewhere.  I couldn't let that happen, so I spent most of my free time over the summer converting the vinyl to mp3s for the zipit in the car, instead of polishing up the gps code.  By the time I finished I'd lost my thread, misplaced my notes, and forgotten my passwords to both github and the scratchbox virtual machine I used for zipit development.   Getting old and forgetful can be a real bummer sometimes.

Eventually the passwords came back, but I could not get any traction with the gps coding. My lack of progress was duly noted on the zipit IRC channel, and it was suggested that I should try to do something really dead simple to get back in the groove.  Perhaps due to the sad state of my notes -- a jumbled mess of post-its and random scraps of paper -- the ctodo program was put forward as an award winning solution to this particular problem.  One that could possibly fill a small gap in the productivity apps available on the zipit.  So I gave it a quick compile on my laptop, but it segfaulted on my first key press.  Award winning gold smiley program indeed...

I fixed that particular segfault, submitted a pull request from my fork of the project on github, and to my total astonishment the change was accepted and merged into the main upstream branch no more than a minute later.  I really gotta learn me some organization  skills like that ctodo author.  Could running ctodo on the zipit could do that for me?  Nope.  It works on the laptop, but locks up the zipit.  Maybe it's the screen size.  I don't know.  I give up.  I can already do the same thing on the zipit with emacs if i were so inclined.  I just happen to prefer scraps of paper and dusty piles of sticky notes.

Someone else on IRC suggested that noisy apps are fun on the zipit, and could I maybe finish porting the little piggy tracker that I'd abandoned unfinished many months ago.  Sure, why not?  I eventually figured out where I'd left my work on that project.  What is it that makes some people (mostly object oriented C++ zealots and Apple computer users) name things like directories and source code files with a leading capital letter?  It took nearly 3 weeks before I thought to search for a directory starting with a capital L.  Oh, look, there it is!

Anyhow, when I previously abandoned lgpt I'd gotten it running, but the screen was completely black.  This time I tried it first with an official build on the laptop and worked out the key sequence to quit -- right, right, A -- and then typed the same sequence on the zipit.  Voila, it exited the program gracefully.  Once I had that down, I located the logging function and instrumented just about everything that could possibly alter a pixel on the screen with debug messages.  I found and fixed a few small coding oversights and eventually got the display working.  I suspect the particular lgpt display code option I selected for my zipit build (generic SDL on the framebuffer) was written long ago, but never tested.  Perhaps only the  windowed (non-framebuffer) SDL code, and display code tailored for particular gaming devices, was ok.  There were no guidelines other than the source code itself to help me out, so this was much harder than it really should've been.  And to bump up the frustration level, once I got it displaying things and making sounds, I quickly discovered that it eventually crashes at random times when I try to use it on the zipit.  I give up.  Again.

After all this I was getting pretty desperate for something -- anything -- that I could call a success, so I set my sights a bit lower.  Ok, a lot lower...  I still like noise makers so I dug up a 12 year old drum program, the drumpiler which reads ASCII formated rhythms and pushes the expected sounds out through the speaker.  Now that's something maybe I can understand.  Write yourself a rhythm in emacs and then run it through a compiler.

 

I tried it first on the laptop and attempted to use the example rhythm from the documentation along with the 4 wav file sounds from the drumtoy program.  Didn't work.  Apparently it's very picky about what sort of wav files you can feed it.  The code is quite dense and very lightly commented in what I suspect is Italian, but after some intense gdb sessions and internet searches for wav file header layout info, I created a one line hack to make it accept mono sound files in addition to the stereo files it originally wanted.  It actually sounds pretty good on the zipit with the drumtoy samples.  Wooot!  Success at last!  I'm back in business.

The goodies will be posted right here, just as soon as I've created a satisfying rhythm I can call my own.  Or maybe sooner, when I come to the realization that I actually have no musical talent to speak of.


Update:  Yep, it's confirmed.  I have no musical talent.  I tried to whip up a simple GoGo beat, but it was so totally wrong that I had to rename the file to nogo.txt  It's included in the iz2s package for your enjoyment.

drumpiler-0.9.1-iz2s.zip

Listen and laugh.


Update 2: I decided to keep going with the command line noisemaker thing for a little while longer, so I made an openwrt build of the drumpiler.

drumpiler-0.9.1-wrt.tgz

I also decided to investigate the similar jdkdrum program that should be available for openwrt from the openwrt-zipit package, but for some unknown reason the package failed to build.  This one lays out the drum tracks horizontally instead of vertically, if that's more your style.   I built it first for iz2s and it was somewhat sluggish starting up, but then it ran just fine once it started making noise.  There's a bunch of floating point math involved in mixing the tracks before it plays, so I converted it to fixed point and now it's quite snappy on iz2s.    I used the compiler on the zipit itself to build it for openwrt.  That took less than a minute and went without a hitch, so I don't know what's wrong with the official package.   Also, the original source worked ok with very little start up delay, most likely due to the superior eabi floating point implementation in the openwrt distribution.   Here's the goodies.

jdkdrum-iz2s.zip

jdkdrum-wrt.tgz

And here's the jdkdrum fixed point patch.

I'm currently thinking about shifting away from the command line (but sticking with the console) to investigate the pineapple tracker, or one of several other forks of hardware chiptune tracker project code that you can find kicking around on github.  I think it might be fun to get another ncurses style tracker running on the zipit, if I can squeeze it onto the tiny screen.


Update 3:  I built both trackers (compiled and debugged them on the zipit itself) and they both appear to work ok.  Pineapple tracker is quite a cpu hog, however I haven't yet tracked down the reason why.  That's because the hyperbola tracker is small enough to fit easily on the internal zipit jffs.  And with a few small code tweaks, it fits on the zipit screen with the 5x8 font.  It's also very light on the cpu.

Debugging an ncurses application on the zipit with gdbtui was fun, but challenging.   Even with an ssh session I kept hosing up the screen.  If only I'd noticed this tip about the gdb tty command before I got things working.  That lets me run gdb in a nice large ssh window on the laptop while ncurses operates on the zipit console.  Perfect.  I should probably debug a few more ncurses apps before I forget this handy trick.


Pictures and new goodies will be posted real soon now.

lgpt-iz2s.zip
hyperbola-iz2s.tgz
pineapple-iz2s.tgz


Update 4 (January 2016):

I Compiled some trackers for openwrt.  Still gotta work on the pictures...

hyperbola-wrt.tgz
pineapple-wrt.tgz

These require an OSS compatible libSDL (otherwise they sound like garbage).

libSDL-1.2.so.0.11.3-wrt-alsa-oss.tgz
or
libSDL-1.2.so.0.11.3-wrt-alsa-oss-sticky.tgz

Unfortunately these libSDLs cause the gmu supplied on the jffs to segfault, so use with caution.  The older gmu (version 8) that I have on my SD card works ok though.  Investigation is ongoing...  I think maybe it's something to do with the sdl timer code used in gmu9.  I don't have a working autotools on my openwrt zipit, so I had to use the iz2s config.h file.

Meanwhile slug_ over at engine12.com, who still has a real working openwrt zipit dev setup (mine died in a disk crash), applied the sticky key patch, enabled oss, and made a real openwrt package.  So this one actually works, and as an added bonus the official openwrt gcc is newer and better, so the resulting lib is smaller -- only 4k or so larger than the old one that comes with with the openwrt jffs.

libsdl_1.2.14-2_pxa.ipk

Hit Me With a Clue-by-four

There's been an uptick in activity on the zipit IRC channel lately.  I like that because it gives me something interesting to read when I get home from work, and it's usually more entertaining than the TV.  Also, it gets me thinking.  The other day (actually quite a while ago now -- I've fallen behind with the blogging) someone on the IRC said something that really whacked me upside the head with a cluestick.  Truth be told, it was a couple of good whacks. 

The first hit came while were discussing ssh and sshfs (and a bunch of other nonsense) but it got me thinking about the sshd on my Arch zipit.  I remembered doing some memory checks in top while working on gmenu2x and gmu for Arch, and sshd was always there, devouring a rather large pile of the precious few 32 megabytes of RAM on the zipit - 3.8MB for the daemon, 5.1MB for a connection, and maybe another 5MB to run it from systemd.  Holy cow, that leaves almost nothing for compiling.  No wonder it was soooo painfully slow on the zipit.  It must've been swapping like mad just to get anything done.

Arch zipit with an open sshd session

Both IZ2S and openwrt run the dropbear daemon instead of the full blown sshd, and it appears to use significantly less memory, likely by trading slower speed for smaller size.  There's no Arch dropbear package for arm processors, so to save time I attempted to use the static dropbear executable from the aboriginal linux extras folder.  I believe we went that route for IZ2S.  So I grabbed the Arch X86 dropbear package, manually extracted the files into the right place, and replaced the X86 executables with softlinks to the aboriginal dropbear executable.  This gave me the systemd script needed to start and stop dropbear with systemctl, and it also included the man pages, which can be handy.  I'm new to systemd, so I played with systemctl for a while -- stopping sshd, starting dropbear, and so on.  I eventually learned that I could make things easier if I used dropbearconvert to get the two daemons using the same keys.  Nice.  However, I never managed to convince the aboriginal dropbear executable to accept my password.  I was gonna have to endure another glacially slow compile session and build an Arch dropbear executable myself.  Darn it!

I fetched the sources and did a practice compile on my laptop to see what to expect.  Looked like it might be a real bear :) to compile on the zipit.  But, as fate would have it, about this time I got another whack from the cluestick and remembered the Arch zipit was only running at 208MHz.  No wonder things were taking forever!  How could I be so stupid?  So I fetched the cpu speed script from openwrt and bumped the zipit up to 520MHz for the compile.  Also, this time I closed my ssh session and ran systemctl on the zipit to stop the sshd and free up all that RAM normally tied up by sshd and systemd.  Then I started the build.  It was greased lightning compared to my previous compiling sessions on the Arch zipit.  In about an hour (yeah ok, it's not all that fast) I had a working set of dropbear executables.  According to top, dropbear was using about 0.7MB of RAM for the daemon and 1.6MB for an ssh session.  That's a significant savings over sshd.  And if I want the convenience of compiling via ssh from my laptop (for the bigger screen) I can save another 5MB by stopping dropbear in systemd and temporarily running it from the command line instead.

Arch zipit with an open dropbear session

Things are really starting to shape up for a leaner, meaner Arch zipit.  We just need to tackle the other big fat bloated RAM hog in Arch -- systemd itself.  On the IRC channel justplainmike did some work on replacing systemd with the busybox init app, some standalone flavor of udev, and a minimal init script.  I'm not sure if that ever worked out, but he's also got the Arch compiler running in a qemu chroot.  So I've gotta try that, just as soon as I get a bigger hard disk for my laptop.

Meanwhile I need to assemble some sort of package for the Arch arm dropbear.  For now, here's a tarball of the contents of the X86 package with the executables replaced.

dropbear-arch-zipit.tgz

Also, the default all red color scheme and Gigabyte memory units in top makes my head hurt.  Do yourself a favor and fix it.  Just press E several times to get to MiB, then Z7S4 to change the list and status colors, and W to save it in your .toprc file.


Update -- December 2015: 

Dropbear is a real package now for arm in Arch, so the tarball above is pretty much obsolete.  Also, mozzwald has rolled out a new zipit Arch image with the dropbear package pre-installed, so you might want to start with that.  I've updated this older blog post with the details.

QEMU take 2: A New Compiler for IZ2S

I'm not entirely clear how I got derailed from my efforts with the Arch zipit and my script cleanup projects, but whatever, I'll roll with it.  At some point in mid April I found myself reexamining the qemu setup that I'd abandoned over a year ago.  My goal back then was to be able to compile and test IZ2S zipit goodies without the clunky scratchbox VM I've been using for several years now.  

I didn't exactly get there, but I did reach a point where I could run SDL programs like gmenu2x in a 320x240 pixel zipit framebuffer, simulated in a QEMU window.  That could be nice for testing purposes, but not so much for compiling due to the limited memory in the zipit simulation.  It's almost like compiling on the zipit itself.  However, an IZ2S chroot running in qemu user-mode *could* be made to run a compiler with all the memory of the host machine.  Most of the work on that was already done by Tycho at brainfisheatfrishbrain.com based on the qemu setup outlined here.  Unfortunately Tycho vanished from the zipit IRC channel, apparently without quite finishing.  And I ran out of Holiday time, also without finishing.  Naturally some other zipit project eventually distracted me...

Anyhow here I was, back on track with the qemu setup, and things seemed to be falling into place this time.  There were small gaps in Tycho's documentation that stumped me before.  Where it says, "Create a chroot", what it really means is to make a chroot for the host system.  These were subtle bits that I missed the first time around.  Of course it could also be that my host laptop is more up to date this time due to a recent disk crash and reinstall with the current version of LMDE.  I took some notes and I think this fake shell script captures what I've done so far, using the tarball from 29 november 2013 (SD iz2s FAT) as a starting point.

I'm pretty sure the old gcc-4.1.1 compiler in that tarball still works, just like it does on the SD card.  So if you just want a compiler, and don't care that it's showing it's age, you can use that one after some minimal setup in the chroot.  The setup is mostly softlinks to the busybox apps and other things that aren't immediately available in the chroot, like they are when you boot from the SD card.  Pretty simple stuff.

I took it a little further and eventually got to the point where I could compile things in the IZ2S chroot with the gcc-4.2.4 that Tycho built.  But then I realized it was linking things against the glibc dynamic linker instead of uclibc.  Ouch.  I ran into that problem long ago when I built my older ARM native IZ2S gcc-4.1.1.  Not only was this a nuisance on the SD card, but it prevented me from using x86 tools from the host OS like make, bash, and autoconf to improve compile times in the IZ2S chroot.  Because of this I can't really recommend using the 4.2.4 compiler.  However I could still use it to build a newer compiler, which I did.  I'm pretty sure the old arm oabi has been obsoleted in the most current gcc releases, so I selected 4.4.7 from March 2012 as a reasonable candidate.  It's the most recent of the 4.4.x series, started in 2009, and it's in the sweet spot of the compilers currently used for openwrt on the zipit.   I've seen hints that maybe a 4.7.x compiler can be made to produce oabi executables, so I may eventually try that someday.

Once I got the compiler running, I recompiled Tycho's binutils to link against ld-uClibc.so.0 and then used the new compliler to rebuild itself, completely purging ld-linux.so.2 from the system. 

Now I had to test it, so I tried it on the OpenMSX that came in the brainfish IZ2S tarball.  Turns out, OpenMSX has a really crazy build system.  Not only does it require python, but it also insists on rebuilding everything from scratch, every time.  I originally passed it over for IZ2S due to the build system, but Tycho put python, and tcl, and all the required pieces in place so I went for it.  It took forever due to the full rebuilds, and because the chroot gcc seems slower than the old scratchbox VM gcc.  I guess that makes sense because even though scratchbox is running in a virtual machine, it uses a cross compiler whereas the IZ2S chroot wraps an arm native gcc in the the qemu-user emulation.  A VM for the same architecture beats emulation.

When I finally got an openMSX executable, it still took me a few days to figure out how to run it on the zipit.  MSX never really went anywhere in the US so I didn't know all that much about it.  Eventually I figured out where to put all the BIOS rom images and such, and got it into the CBIOS screen.

Not very exciting.  Now I had to figure out where to get something interesting to run in it.  Since I don't own any MSX hardware or software I tracked down a few homebrew roms.  Bombjack is sorta cute, but it seems like maybe the sound and gameplay is a bit off.  I suspect at 312MHz the zipit is just ever so slightly underpowered.  For comparison I also ran the openmsx executable that Tycho made with the older gcc-4.1.1 and the arm assembly code disabled.  I couldn't tell the difference.  Oddly, the sound worked about the same on both builds, despite the comment about sound not working.  I checked and noticed the brainfish IZ2S tarball was still using the old libSDL with broken sound support.  Tycho probably never knew his openmsx executable was actually fully functional.

I may need to recompile it one more time if I can't figure out how to modify the keyboard config file to give me access to the Dingux on screen display.  (Without that I have to run it from an ssh session if I want to quit.)  Then hopefully I can put together some IZ2S packages for gcc-4.4.7, openMSX, python, tcl, and whatever other useful libs Tycho built before I get distracted by another project.

I also need to sort out and publish some readable follow up instructions for installing gcc-4.4.7 into the IZ2S chroot, and using it to build things.

I've already got a tracking number for mozzwald's z2 breakout board, which means it's been shipped, so the distraction free window is rapidly closing...


Update:

I sure called that one.  Six months and counting and I still haven't followed up on this.  So I hastily zipped up the gcc-4.4.7 executables.  I hope I got them all.  There actually seems to be multiple copies of the binutils executables.  I suspect only the ones in the gcc/bin directory are actually required.

gcc-4.4.7-iz2s.zip

Unzip it to your SD card and source the compiler script to set up all the paths and such.

  ".   /mnt/sd0/bin/compiler"
 

Here's the instructions I posted in the comments section on how to put together the qemu chroot.  You should be able to unzip the compiler into that instead of compiling it yourself.

Qemu setup instructions

Or, use this tarball of the entire qemu iz2s setup.  You'll still have to follow some of the instructions to start it up in quemu user mode.  It's got the compiler, python, openmsx, etc already built and ready to go.  Thanks mozzwald for hosting it.

iz2s_qemu.tar.bz2

For historical purposes, here's a link to the scratchbox VM with the older gcc-4.1.1 compiler.

Zipit Z2 Development V2.zip

Update 2 (11/2018):

After a few years of neglect I decided to put the qemu compiler to work once again, and make a new IZ2S build of dropbear.  The old cyphers are deprecated and the workaround command line args to ssh into the zipit are painful.  I could handle something like -1, but -oKexAlgorithms=+diffie-hellman-group1-sha1 is about 40 letters too many to commit to memory.  So I resurrected the qemu chroot and went to work compiling the latest dropbear.  It took a few tries to remember some of the tricky techniques required to produce "optimal" executables for both the internal flash jffs and for the SD card.  For the jffs, small size is critical, so I built the dropbearmulti target with minimal features and compressed it with the lzma version of upx.  An IZ2S SD card uses the FAT filesystem, so individual apps work better than dropbearmulti, because softlinks are not available on FAT.

I've uploaded a zip file to the usual place, with dropbearmulti for the jffs and the individual apps for the SD.

Meanwhile, I discovered some gaps in the tool set on the IZ2S qemu image.  The upx and sstrip programs were absent, and libcrypt.a was unavailable.  I believe libcrypt is actually in the qemu image with the older v4.1 compiler, and simply needs to be copied from the older gcc libs in /usr/local/share/gcc/lib to the usr/lib directory.  But it's not in the v4.4.7 compiler zip or the zips for for the IZ2S libs and includes.  So I think I need to put together a small "toolchain_extras" zip file with the missing bits.

Also, since I can't seem to remember, I'll point out here that CFLAGS="-march=armv5te -mtune=xscale" is nice for the zipit processor.  And do NOT use soft-float on IZ2S.  The stock kernel is OABI and the libs are compiled with default float settings.  Back in olden times that meant hard float instructions with kernel emulation of the FPA via exceptions, which is why floating point code is so dreadfully slow on IZ2S.  If you run readelf -h libgcc.a you'll see lots of zeros in the flags and ABI bits, indicating the defaults were used.  So if you get hard/soft float mismatches from the linker (like I did when I accidentally grabbed the soft-float libcrypt.a from openwrt) then you should compare readelf header output of the mismatched files to see what's up.

Here's a readelf -h header sample from the IZ2S libgcc.a for reference:

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 61 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            ARM
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          700 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           40 (bytes)
  Number of section headers:         9
  Section header string table index: 6




Another tip to remember... If you're making an SDL program for IZ2S, don't forget to link with -pthread before -lSDL and -pthread again after.  This prevents a nasty segfault in the startup code -- before it even gets into main().

Scripts and Scraps

While working on qemacs, gmu, and other assorted goodies for the zipit Arch image, I built up a small collection of scripts to make life easier for myself.  Alsa is not set out of the box with reasonable defaults for the zipit, so a small script takes care of that.  In order to compile I need to run make, which only works properly if the zipit is keeping track of time.  So I made a script to connect the wifi, and dug up another script to set the clock via http.  Arch runs heavy compared to openwrt or iz2s (systemd and bash vs busybox) so I needed a script to enable swap in order for gcc to have enough memory to actually do anything.  You get the idea.  I really must start a github repository for Arch zipit tools before I lose track of this stuff.

Anyhow, after success with gmu I attempted to build gmenu2x for the zipit Arch image.  I was compiling on the zipit itself, so it took forever.  To speed it up I tinkered with zram at high priority with failover to the lower priority swapfile, but that tended to fail rather than failover.  Locking up the zipit did not improve compile time.  Oh well, so for coding and pacman updates I disable zram and switch to a 64 megabyte swap file.  Otherwise I just stay with the zram.  I built my arch gmenu2x with the IZ2S gmenu2x  code fork because I'm more familiar with it than the openwrt branch. Unfortunately I had to modify the code to use the Alsa API for volume control because mozzwald's kernel wasn't configured with OSS support.  I suppose that means I'll have to start another github fork of gmenu2x for Arch.  I'm not too excited with that idea as the Arch alsalib (like all things Arch) is full featured and heavy and tends to push gmenu2x into swap.  So I convinced mozzwald to add OSS to his kernel build.  However I still need to go back and rebuild gmenu2x to test it. 

AFAIK nobody's built any zipit specific power management utilities for Arch yet, so I added keyboard and LCD backlight controls to gmenu2x, but it needs more work.  For example, there's no screen blanker for graphics mode yet, so you close the lid on gmenu2x and the backlights stay on, unless you dial them down manually first.  Hmmm, that got me thinking the IZ2S utilities and some unimplemented features I'd put on the backburner for all that stuff.  So I gathered up the old scripts, and various scraps of code from pastebin, and assembled an IZ2S utilities repository on github.  Then I got to work on some of those backburner utility projects.  First I folded the power management and LED control multi-call-binaries into one super utility mcb.  This allowed me to add the missing keyboard backlight restore function to lid switch monitor, without calling a separate executable.  I built it with tiny executable settings, so someday I'll make yet another jffs image and this'll save a bunch of space on the flash, and possibly some runtime RAM as well.

I also cleaned up the fake mouse demon and added code to intercept key press events on the zipit's side mounted volume rocker button.  If the control or alt modifier keys are active when the rocker is pressed then the demon steals the key events and adjusts the backlights instead.  It's almost just like I promised way back when I published my preferred "universal" keyboard layout.  While I was in the code I also (finally) added functions to get some use out of the play and stop buttons, when they're being interpreted as the left and right fake mouse buttons (probably most of the time given the general lack of mouse aware programs on the zipit).  Previously I'd added play and stop icons on the gmenu2x settings screen, which is nice, but the actual physical play and stop buttons are available all the time.  Much better.  I've currently got them sending fake key events to tty4 if anything like mpg123 is running there, but you can edit the OnPlay or OnStop scripts if you want them to do something else. 

The play and stop button work got me thinking about the youtube and movgrab.  I long ago lost track of the SD card where I originally set all that up for IZ2S, and couldn't find a pastebin with my IZ2S youtube scripts, so I started over and came up with something that mostly works.  Live streaming only works well with the postage stamp size video.  Perhaps the stdin and stdout buffers are limited (like named pipes) to 64K in the aging stock zipit kernel?   So to work around, I let movgrab spool things to a file on the SD card and pointed mplayer at that instead of a pipe.  It works well for short full screen videos, but eventually breaks up on the longer ones.  That's ok, I suppose.  The movgrab process eventually gets it all and you can play it back later with slightly better settings.

Slightly better is still sorta iffy.  I swear it looks better in real life.

I suspect maybe youtube is throttling the stream, so I tried to get mplayer to display the progress bar and let me monitor how far along it was getting.  But apparently the old IZ2S mplayer was compiled without progress bar support.  It's a pretty old version.  Maybe it's time for an upgrade?

 The tiny 3gp video streams ok, but there's not much to see.

I started on a new mplayer build for IZ2S, disabling this and that -- things that will never work on the zipit -- and patching the ffmpeg code for uclibc.  But what I've come up with so far is still too fat and bloated.  If I can't build a reasonably lean and mean mplayer with progress bar support, then perhaps I can convince the existing mplayer to leave a few rows of pixels on the bottom of the screen untouched.  Maybe I can put up my own progress bar with a small framebuffer program running in the background, monitoring the movgrab download progress while simultaneously tracking the estimated play time?  I did some experiments with libFB and libpsf, but nothing conclusive yet. Also, while I can have the background process send pause and play commands to mplayer if the download buffer gets too low, what happens if the user (me) manually tells mplayer to pause, or even quit.  How's the background process gonna know about it?  Gotta do some more thinking on this...

I'll try and package up the goodies and drop them here when I get a chance.

Ok, here's the Arch gmenu2x, gmu, and qemacs in /usr/local/*.
zipit-arch-local.tgz

Here's the assorted helpful scripts that I've got in the Arch home directory. 
archome.tgz

Update - December 2015:

Mozzwald made an updated arch image with the oss enabled kernel, and I recently acquired some cheap 32GB micro sd cards, so I decided to try it out.  Dropbear is a real package now in the arm arch distribution, so that's pre-installed on the new image.  Nice.  This also has the backlight blanking demon so the screen will blank even when closing the lid on an SDL program.  Good stuff!

Since this was a new install, it gave me the chance to document the steps required to get the gmu and gmenu2x in the zipit-arch-local tarball above running.

Right after installing mozzwald's image on the sd card, I installed the two tarballs above.  Then I put it in a zipit and booted.  When it was up and running, the first thing I had to do was look under the battery for the mac address so this zipit wouldn't conflict with my other arch zipit on the wifi.  Install the correct mac and connect to the wifi.

   ifconfig wlan0 hw ether xx:xx:xx:xx:xx:xx
   wifi-menu

Next you want to install some packages.  You'll need to turn off zram and use just the swapfile, otherwise pacman will run out of RAM.  Maybe zram and a swapfile work ok together for small things, but I never got them working well together for pacman.

   swapoff /dev/zram0
   swapon /swapfile2

Then update the packages, and install some good stuff.

   pacman -Syu

For SDL you have to use --nodeps twice or pacman will pull in all sorts of bloated X11 junk.  The dependencies for the other sdl libraries are ok though.  Same for alsa-utils.

   pacman -S sdl --nodeps --nodeps
   pacman -S sdl_ttf
   pacman -S sdl_image
   pacman -S sdl_gfx
   pacman -S alsa-utils

 I use mpg132 for the internet radio app in gmenu2x.  Openssh is handy for scp.  And fbgrab is handy for screenshots to prove you did it.

   pacman -S mpg123
   pacman -S openssh
   pacman -S fbgrab

Once you have all this stuff you need to setup your environment for SDL so it knows to use the framebuffer and alsa drivers.  You'll use some of the scripts from the archome tarball above.

   .    /root/sdlenv
   .    /root/alsaon

I probably want to set the init system to do this and the mac address on every boot up, but I'm not there yet.  This should be enough to run gmu, but I still need to create a wrapper script for gmenu2x in /usr/local/bin, and maybe plug it into the init system.

Don't forget to fix the top display settings.  Scroll to the bottom for instructions.