More of the Same

Yet another month of very light blogging.  And once again, I did actually accomplish a few things that I just simply haven't yet managed to write about.

I was lurking around on the zipit IRC channel lamenting the apparent demise of some zipit sites (and locating the backups on google and in the wayback archives) when beaglebreath mentioned he was looking to move some of his weather monitoring gpio code over to openwrt from z2sid.  Now z2sid comes with a native compiler, but openwrt is where most of the action is these days.  So I thought, hey! openwrt has a package with the PicoC small C interpreter.  Maybe that could handle it.  You only need to read and write some files in sysfs to work the gpios for the weather sensor. Based on my experience with PicoC on IZ2S I figured that'd be easy.  Of course reality gets in the way.  Openwrt had PicoC, but it was on an old version of PicoC, just before the file IO support was added.  Figures. I bumped it up to the latest version on the zipit openwrt github, and then added a tiny patch to convince openwrt to build it.  I had to switch some of beaglebreath's file IO routines to use stdio instead of fcntl.  But with that small change it seems to work for me.  However it's still unclear if it can actually handle the IO for the sensor.

At this point I decided to try a real native compiler instead of the C interpreter in PicoC.  I started with tcc because it's tiny.  It seems to work, sort of.  But I got stuck trying to link anything against uclibc.  Without a libc, file IO would probably be a challenge.  So I revisited the self contained aboriginal linux gcc that worked so well on IZ2S.  Because openwrt is eabi I was able to use the arm5l compiler which is quite reasonable for the arm5tel processor on the zipit.  I built a few hello.c progams, which worked, but the weather sensor program gave the same results as PicoC.  Hmm, maybe we're using the wrong source, or perhaps the sysfs works differently on the openwrt kernel than it does on z2sid.  Since I don't have my own weather sensor I'll have to dig up a logic analyzer someday and watch the IO lines to verify once and for all if PicoC can do it.  I still believe...

Meanwhile, I opted for a real challenging test of the native compiler.  Rockbox!  I got it to build way back in February with the buildroot cross compiler setup from openwrt, but it ran like crap so I gave up on it.

This time I compiled it on the zipit with the native compiler, but wouldn't link against the openwrt SDL shared lib.  Possibly because the libs are stripped?  I don't know.  I gotta swap in the unstripped libs someday and see what happens.  Anyhow, I still had nagging doubts that maybe the previous performance problems could've been fixed with my buffer patched SDL from IZ2S.  So I compiled the IZ2S SDL and salsa code on the openwrt zipit and static linked rockbox against it.  That was a bit of a chore, and the rockbox executable is now about 300K bigger, but it runs nice and smooth.  I had to fetch perl, some perl modules, and coreutils-install packages from the openwrt package repository to work through the rockbox build and install process.  I also created a 32MB swapfile needed to compile a few of the codecs.  Otherwise the build was fairly straightforward, if somewhat tedious.  I even compiled a pile of plugins.  Rockblox, anyone?

I still wonder if the performance problems with the cross-compiled rockbox could be fixed by installing a replacement SDL like I did on IZ2S.  Someday, maybe...

The apps on my openwrt zipit are now looking a whole lot more like my IZ2S zipit apps. 

Here's the goodies.  I updated these from the betas so now all the codecs are included, as well as a gmenu2x icon, and the key bindings on the rockblox and bubbles plugins have been fixed up.
rockbox-wrt-r3.9.1.tgz
rocks-wrt-r3.9.1.tgz

I finally managed to link against the shared libSDL using the unstripped libs from my openwrt staging-area.  So I upxed the smaller rockbox.bin down to just under 280K if you want to try and fit it on the jffs.  But it does sometimes skip when it first starts up.
rockbox-wrt-shared-upxed-r9.1.1.tgz

I also created a rockbox wrapper script with dronz' bass and treble setting settings.

RockboxWrtJffsInst.sh will set you up to use it when you boot from the jffs. This may not be required if you're using the overlay scripts.  I haven't tried them yet.


The updated PicoC is available from the openwrt package repository.

Here are some interesting PicoC links:
PicoC enhanced for a commercial PLC
PicoC robot code documentation

There might be something wrong with the openwrt gdb package so I compiled it on the zipit just in case.

gdb-wrt.tgz

Like Clockwork

Heh, not really like clockwork.  I've actually been somewhat remiss with the blogging lately.  What can I say?  It's summer.  Oh wait, I already said that, didn't I...  Anyhow, last time I made a teensy tiny bit of progress on my zipit clock radio dream project.  Well, it's now been another 4 weeks and once again I haven't really got much to show.  But a little something is still better than nothing, so here it is:  My first attempt at porting that maemo flipclock app I've been lusting after.

As you can see, after resizing it for the zipit I've got plenty of room on the bottom for other goodies like the date, alarm settings, or even the weather from the internet via the http://www.google.com/ig/api?weather=zipcode API, or somesuch.  I'll probably try to  steal some ideas from this nifty weather clock for z2sidX.  There's not actually whole lotta code in the flipclock, so I also just might attempt to paste this into GMU as an additional screen with maybe a truncated playlist in the empty space down below.  Although, I'm kinda sorta waiting to see what's in the mysterious GMU update release hinted at here before digging into that code again.

Oh well, I'm really not sure where I go from here, but I'm sure I'll get there eventually.

Here's a zip with the sources and an IZ2S executable.  flipclock0-3-iz2s.zip

Blinky Lights

Not so long ago I mentioned that the dronz alarm clock in the jffs was nice but... even with the lid closed the LEDs on the zipit are too darn bright and keep me awake.  At least they're only green and amber, and not those evil blue ones that seem to be popping up on just about everything these days.  I swear the blue ones can trigger migraines and burn holes in the backs of your eyes, but that's a story for another day.

Anyhow, the LEDs have gotta go if I'm gonna get any sleep.  I already had a utility for controlling the right LED, so I just dug up the GPIO numbers for the other two LEDs from the wiki, and patched it into the existing IZ2S powerbutton and lid checking MCB program.  The only tricky bit was the GPIO for the  middle LED defaults to an input for some strange reason, so I had to borrow some more code to set the direction register.  That seems to work, so now you can softlink the new "lid" executable on the jffs (or copy it on IZ2S) to a bunch of new utilities for the left and middle LEDs.  I also added commands to query the current state of each of the LEDs, so they can be saved when the clock starts up, and restored when the alarm goes off.

Here's a zip file with the new "lid" executable, the source code, a script to make all the softlinks, and another script that prints all of the current LED states.  Nothing really exciting, but hey, I need my sleep.

ledctrl-iz2s.zip

Summer Vacation.

Wow, July is half over and I haven't posted anything for weeks.  I've done a little bit behind the scenes, but every time I settle down to tackle something on my todo list the dog gets the urge to go outside and play.  And somebody has to go with him.  It's not so bad though...

It's actually kinda tranquil now that the bridge replacement is finally finished.

So what have I got to show for all this lack of effort?  Well, not much, really.  I did update a few previous posts with new qemacs executables for IZ2S, z2sid, and openwrt.  I really like qemacs now that I've added the missing features.  I still have to try and make a real openwrt project for it, but I'm slowly inching closer to that particular goal. 

Projectgus opened up the openwrt-zipit project on github, so I've been trying to learn more about github and the openwrt build system.  To do this I decided to update nupdf from a mipsel-only openwrt package to one that builds against the same (more current) mupdf shared libs as the fbpdf package.  The nupdf source archive appears to be inactive, so I cloned it onto github to do the update, and then added the zipit keyboard patches.  I then borrowed openwrt Makefile settings from the gmenu2x package to fetch the nupdf package via git from github instead of svn from google code.  Seems to work. 

Apparently the old static IZ2S nupdf package also works on openwrt if you simply unzip it into /usr/local, so maybe someday I'll try and run it on z2sid as well.  I'm pretty sure it's already available on z2lite.

Oh yeah, I also finally posted the gcc/gdb package for IZ2S in this old post.

A Little Less Failure This Time?

This week started out much like the last.  More adventures in failure.  The guys on Zipit IRC seemed to be struggling with an improperly rotated links -g running on DirectFB in openwrt.  I pointed out Ray Haque's secret sauce for that problem, but failed to get it done.  So I got the bright idea to try and build it myself, with SDL and all my favorite patches from the IZ2S world.  Sound familiar?  Yeah, and it started out exactly the same way.  One failure after another. 

To start with, I had an old failed rockbox for openwrt that I never quite got working right.  It runs, but horribly, and eventually I lost interest and moved on.  Shoulda took that as a warning.  Stay away.  But no, I fired up the old P3 with my openwrt setup on it and updated all the git archives following Anarsoul's instructions.  At least I thought that's what I was doing.  Apparently the browser still had a cached version of the instructions from last February when I was working on the rockbox build.  And the cached instructions contained a typo.  A dash character in one of the feed names prevented me from building the qi repositories with the links package that I wanted.  For several hours!  The guys on IRC were quite helpful, and we eventually worked out the problem only to discover the instructions on the internet were already fixed, and probably had been for months.

See.  There's the typo, right there.  Can you spot the difference?

Oh well, moving on.  So I started the P3 building the goodies and watched for a few minutes before... guess what?  Hard disk failure!  Aargh!  Stupid old 80GB external drive developed a bad superblock.  I sorta remembered this drive gave me trouble before so I decided to abandon it and get a newer one rather than try to fix it.  Someday maybe I'll try to recover the bad rockbox build with one of the backup superblocks.

The next day I nabbed a 500GB drive from one of the kids and started over.  I refetched all the openwrt archives, followed the correct instructions to setup the feeds and started the build again.  Then I went to sleep, exhausted but hopeful.  The build failed a few times on supertux, the kbd package, and libmpg123 so I had a few restarts to do the next day.  But eventually it built everything else I'd selected.  Gotta see what's up with kbd and libmpg123 since I may want them someday.  But for now I'm gonna build with IGNORE_ERRORS=m to keep it going after failures.

Anyhow, the links package compiled so I just needed to apply my patch from IZ2S and rebuild.  Or so I thought.  I tested the patch in the directory with the links sources and it applied cleanly.  Cool.  However when openwrt compiles, it wants to wipe out the directory with the package sources, start fresh, and apply it's own patches.  But it took a while to figure out how to remake my patch the way openwrt wants it.  You need to make it run with patch -p0 so the destination directory name in the patch must match exactly with the directory name in the package tarball used by openwrt.  At least I think that's the case.  It's hard to see exactly what the byzantine openwrt build system is doing, even with the V=99 command line option.

I got some more hints from the IRC guys on how to reproduce the openwrt build environment so I could manually step through the patching and configuring and try and fix the broken parts.  I don't think I ever completely reproduced the environment but got close enough to figure out some of the trouble spots.  Apparently for openwrt you need to make a makefile for each package that runs configure to create a makefile for the package.  Hmmm.  I examined the existing meta-makefile and attempted to convert the tricks used to configure directfb into tricks that would configure links for SDL.  It didn't exactly work.  The openwrt build process was successfully applying my patch, but failing during the configure stage because it couldn't find SDL.  I tried looking at some other packages like nupdf and sdlwidgets for SDL config hints, but to no avail.  As many things do, the answer crystalized in my sleep, and when I woke up I found the sdl-config program I needed in the openwrt-zipit/staging_dir/target-arm_v5te_uClibc-0.9.33_eabi/usr/bin directory.  I fixed up the meta-makefile with that path.  Now the configure stage managed to find SDL and moved on... only to fail writing the new makefile.  Syntax error in the patched configure script!  Did I already say arrgh!?

Now, the original SDL patch from the internet required me to rerun autoconf to create a shiny new configure script (and Makefile.in) with SDL options.  I did that for my IZ2S build, but I have no idea how to do that in the openwrt environment.  Also, different versions of autoconf tend to generate a completely different output files.  And configure is over 600MB!  So I'd attempted to make a small patch for the configure script that would paste in only the changes involving SDL and skip all the gratuitous changes caused by the different version of autoconf. That got me all the way to the syntax error.  I took another look at my patch, and the modified configure script, but that's not work meant for humans.  Hand editing 600MB of butt ugly machine generated script file is not my cup of tea.  Even the mighty emacs with it's color syntax highlighting and electric parenthesis matching wasn't helping me deal with the horrendous tab formatting.  So instead I gave up and changed the openwrt meta-makefile to replace the whole 600MB configure script with the one I'd regenerated earlier with a different autoconf on a different PC.  Oh well.  It's kludgy, but it works.   

Not Fail!  Yeah!

The new openwrt Makefile, patches, some zipit friendly config files, and key docs are on github.

I put up the links-sdl_2.3pre1_pxa.ipk package for openwrt zipits, with config files and a kbd cheatsheet.

Here's my wrt-env.sh script (modified from slugs).

Update:   Anarsoul added PKG_FIXUP:=autoreconf to the Makefile to auto-magically regenerate the correct configure script as part of the openwrt build process.  And projectgus pulled it all into the master github project, so you should be able to get the links package from the usual place.  Cool!

Meanwhile, here's a qemacs executable for openwrt.  I still need to learn how make it into a real openwrt-zipit package...

Adventures in Failure

A few days ago I mentioned my desire to try compiling right on the Zipit.  It ought to be possible.  It seems like just yesterday I had Linux with X Windows, emacs, gcc and all sorts of goodies running just fine on a junky Cyrix "486" CPU with only 16 MB of RAM.  What happened?

Anyhow, just as I was lamenting my failure to debug Bunjalloo in IZ2S the subject of rockbox on z2sid came up once again on the zipit IRC channel.  Ah Ha!  That's been on my todo list for quite a while now.  I knew z2sid came with a working gcc right from the get go.  I could start with that project and work my way back to the IZ2S compiler.  To make it easier for me I tarred up my pre-patched rockbox 3.9 sources instead of updating the zipit patch to the current release version.  Gotta do that someday...

I dumped the sources on a 2GB z2sid SD card I had lying around in my collection and booted it up in my one working uboot zipit.  I started up the rockbox configure script, picked the zipit target, and failed because it couldn't find the SDL dev package.  Ok.  That makes sense.  I should be able to get that with apt-get install libsdl-dev.  Unfortunately that took a lot longer than I wanted because I forgot you needed to be root to use ewok or wifi-config to get connected.  Also the wifi-config scripts all need to be edited to replace eth1with wlan0 in order to work in a uboot zipit.  I'm not sure why a zipit needs a user account in addition to root.  Everything I want to do on it seems to need root permission, and really!  Who cares if somebody hacks into my $10 toy via the free wifi at MacDonalds?

Eventually I got connected and ran apt-get update (twice for good luck) and then apt-get install libsdl-dev.  This was taking a while so I set it aside to finish while I went out for some old man hockey and beer time.  When I got back it was done, and successfully too!  But apparently apt pulled down dependencies for just about every SDL backend out there, including Xlib!  WTF!  The poor SD card was full up to the limit with only a few measly megabytes leftover for me.

So for giggles I ran make on the rockbox sources and let it go overnight.  As expected, it ran out of disk space and failed.  Oh well.  Maybe I'll try again, with a fresh install of z2sid, compiling my own lean mean SDL with only the framebuffer and salsa backends.  That might just leave enough space on the SD card for a rockbox build.  If only the zipit uboot was stable enough to work with larger SD cards.  I have a bunch, but no luck with anything over 2GB.

But really, I think I need to put zipit compiling on the backburner for a while.  If anyone has a bigger SD card and wants to try this, I put up the rockbox sources here.

  rockbox-zipit-src.tgz

You'll need to build SDL or get a libsdl-dev package.  Then do this.

cd rockboxtrunk/tools
rm bmp2rb
rm convbdf
rm codepages
cd ../build-zipit
cp autoconf.h autoconf.h.save
../tools/configure

Type 205 to select the zipit target.  This will configure an IZ2S build target.  You don't want that because the battery monitoring code is for the older kernel.  So open up the Makefile with nano or vi and remove the -DIZ2S from the EXTRA_DEFINES line.  Hopefully the battery monitoring code for the z2lite kernel is good for z2sid.  Also, I made the zipit config target use the SIGALTSTACK_THREADS option, but never got it to work so you have to restore the autoconf.h.save with the SDL_THREADS option instead.  Then maybe it'll build.

cp autoconf.h.save autoconf.h
make

Cross your fingers.  If it succeeds, strip the rockbox.bin file then:

make install.

Maybe strip the codecs in the /usr/local/lib/rockbox dirctory and borrow the /usr/local/bin/rockbox script from z2lite.

Update:  I discovered I was using the z2sid version with the enormous j (junk?) file on the root directory so I deleted that and tried again.  Still no luck.  Turns out it was the /tmp directory running out of space.  The /tmp directory has only 1MB, so maybe I'll make a /usr/tmp and export TMPDIR=/usr/tmp to see it that moves things along.

Update 2:  That actually got me most of the way through the build.  It appears as if only the initial tool building stage needs the extra TMPDIR space to reproduce the bmp2rb, convbdf, and codepages utilities deleted above.  Subsequent rockbox builds don't need it.  However I hit a snag on the assembler code.  I was forced to add -mcpu=xscale to the makefile get any arm assembly instructions above armv4 to build.  That got me all the way through the "make install" step.  Still didn't work though.  The main rockbox executable brings up the GUI and everything looks good until I pick some music to play.  Then...  "Codec Failure".  Oh well.  At least that's familiar territory.  The SDL codec loading section of the rockbox source code is overly convoluted, and I've had to tweak it a bit before for earlier IZ2S and z2lite builds. I'm not looking forward to repeating that work though...

Meanwhile, since the z2sid compiler seems to work well enough, I decided to build a qemacs for z2sid to make it easier for me to edit and debug the code on the zipit. 

  qe-z2sid.tgz

Maybe You *Can* Teach an Old Dog New Tricks

The other day while floundering around on the net I noticed qemacs 0.3.2 was out, with some compiler fixes.  Because of it's size and feature set (split windows and a shell) I tend to use qemacs on all sorts of embedded platforms, and on the zipit.  However its got a few quirks that constantly drive me nuts.  The one that really gets me is the missing repeat feature on the C-k key.  It kills me that I can't use consecutive C-k keystrokes to add multiple lines into the current kill buffer.  I use that all the time to cut and paste multiple lines of text between emacs windows.  To make matters worse, I never managed to get alternate the C-@ and C-w (mark and cut method) to work on the zipit because of the unusual keyboard layout.  So I finally decided to dig into the code and add the missing functionality.  It wasn't actually all that difficult to fix.  Shoulda done it years and years ago...

While I was in there I figured I might as well add the missing scroll keys too.  I've been using C-z and M-z to scroll my editor windows up and down since the days of the dinosaurs, way before there were scroll wheel mice, or for that matter mice, or scroll bars even.  I got hooked on those keys many years ago in school when I switched my preferred DOS editor from MINCE to Epsilon.  I no longer use Epsilon (I probably still have the floppies somewhere) but I always add those key bindings to my .emacs config file.  However I could never convince the ~/.qe/config file to do much of anything for me.  So now I've simply patched the source and compiled them in.  Yay!  If I get really deep into the code, perhaps I'll try to add bourne shell syntax highlighting, which I tend to run into more than html or C syntax on the zipit, and the embedded stuff.

Another thing I noticed on the net was a github archive with the qemacs 0.3.1 sources.  I decided this was my chance to finally learn how to git.  I'd already established a github account and forked a few projects, but never really got around to doing anything with it.  For starters, my scratchbox development VM is on debian lenny so I had to jump through a few hoops to install a current version of git.  The key to that was adding a line to the /etc/apt/sources.list file pointing to the recently archived lenny backports. I found the answers at "Git on Lenny, a love story", except for the new archived location of the lenny backports:

deb http://archive.debian.org/debian-backports lenny-backports main

Then this command got me a recent version of git.

sudo aptitude -t lenny-backports install git

So now that I'd got git, I had to get git skills.  For practice I forked the qemacs 0.3.1 repository on github, cloned it to the local disk on my zipit development VM, bumped the code to version 0.3.2, applied my patches, and pushed them back up to my github repo.  Piece of cake.

Next I need to learn to make a new repository from scratch on github so I can track my changes to the bunjalloo code. And then I've gotta practice git branching with my IZ2S fork of slugs gmenu2x code.  I'm pretty excited about that one since it appears to use a 7K png font file instead of an enormous ttf font.  If I change the jffs to use slug's gmenu2x I can get rid of the ttf libs, the ttf font, and (unfortunately) dgclock will have to go too unless I rewrite it.  But I'll still have two clock apps and will save at least 300K on the jffs for more interesting goodies.  Here's a screenshot.  The png font uses more pixels, so not as many apps fit on the screen.  But the scroll bar makes it pretty obvious that there are more down below, so that's ok, I guess.

The qemacs patches are on github, but I've also included them here with an IZ2S executable.
qemacs-0.3.2-iz2s.zip