Dividends

At some point during all the various updates to the previous post I noticed that dronz posted an update to his calculator package in the goodie bag.  I haven't really had time to test it yet, but I spotted the note about my crappy build of bc.  Way back when I compiled bc I got stuck, unable to fix a segfault with the builtin mathlib, so it was limited to only the most basic functions.  Good enough for the rudimentary math required for zpub, but not much else.

Well, now I have a native compiler and a debugger so I took another look.  Turns out the segfault was due to gcc 4.1 optimizing out some important initialization functions required for the builtin mathlib.  I turned off the optimizations, and now it all seems to work.   Ok, my "extensive" testing showed the sine of zero is zero, and four times the arc tangent of 1 is pi according to the bc mathlib.  That's miles better than a segfault.

I have the compiler running on an SD card loaded with IZ2S 2.04, and the keyboard drivers on 2.04 are a bit flakey, so I decided to build another bc executable with the readline command line editing enabled.  That adds quite a bit of bloat, so it's not really suitable for the jffs, but it did help me with my testing on the jumpy keyboard.  So I guess I'd recommend the readline version if you're gonna put it on an SD card.   Otherwise I'd upx the smaller bc and go with that.

bc-with-mathlib-iz2s.zip

Here's a site with tons of goodies for bc.

Another site with code for making animated graphs from bc.  Perhaps it could be combined with zgv or imgv to make a graphing calculator?

Update:

I spent a few minutes with dronz' latest iz2jffs calc script and tweaked it up a tiny bit.  The resulting calc script runs bc with -l to load the mathlib, lets me change the scale, and can apply subsequent operations to a previous result.  That covers about 99% of my calculator usage, except maybe when I want to do hexadecimal math.

Try, Try, Again

Previously I mentioned the premature demise of my openwrt and IZ2S development laptops.   I have backups for both, but they're on far from optimal machines.  So I've been itching to get something going with native compilers on the zipit.  Lately I've been having some luck with the aboriginal linux native compiler on my openwrt zipit, so I thought I'd give the other aboriginal native compiler some attention on the IZ2S zipit.

Running gcc -v tells me the native compiler I've been trying to use in IZ2S was built with --disable-multilib and --with-float=soft, which is incompatible with the hard float settings in all the IZ2S shared libs built with the scratchbox VM.  That's too bad because the xscale processor in the zipit has no FP hardware, so the soft-float setting makes more sense than forcing the kernel to trap whenever a function call attempts to pass an arg via nonexistant FP registers.  But even more disappointing, it means the aboriginal gcc is pretty much limited to producing static executables for IZ2S.  Someday I should try to use it to build a static version of nightsky and see if soft-float really is 10 times faster than trapping all the FP calls.

The scratchbox instructions on the wiki mention arm-gcc4.1-uclibc20061004 so I fetched gcc 4.1.1 and attempted to build it with the scratchbox cross-compiler.  I think the last time I built a compiler was way back before C++ even existed, so I was more than a bit intimidated by the complexity of a more modern compiler.  My first attempt to build gcc in VM didn't go so well, so i thought maybe I could build it right on the zipit with the aboriginal compiler.  I very quickly thought better of that plan.  Unzipping gcc on the zipit used way too much disk space.  In fact, I panicked watching it unzip all that stuff and hit the hard reset button, which naturally hosed the FAT filesystem on the SD card.  Poking around in the wreakage reminded me that the FAT filesystem doesn't support softlinks, probably a deathblow to building gcc.  Not to mention the zipit is too slow, has no memory, and the SD card would take a serious beating.

I came to my senses and decided to try again in scratchbox.  This time I did some homework.  Running gcc -v reveals the config settings used to build the scratchbox compiler.  Running ld -V tells what config settings were used to build the scratchbox binutils.  I took some notes and read (ok skimmed) the gcc build instructions.  So this time I built binutils first, configured to install in the /usr/local/share/gcc directory so I could keep it segregated on the zipit SD card.  That went fairly well, so I duplicated most of the config settings from the cross-compiler and attempted to build a native gcc.  It went somewhat better this time.  Near the end of the build it tried to use xgcc (a limited build of gcc) to build something - maybe libgcc and/or the final gcc executable.  But xgcc was an arm executable built in an earlier stage, so it segfaulted when run in the scratchbox environment.  I patched the gcc/Makefile to replace ./xgcc with gcc so it would use the scratchbox cross-compiler to finish the job.  This actually seemed to work and make install put what looked like a native compiler in /usr/local/share/gcc.

I gave it a whirl on the zipit and discovered a few problems compiling a basic hello.c program.  First of all, it couldn't find stdio.h.  I'm not sure how to get make install to put everything in the /usr/local/share/gcc directory.  So meanwhile I had to fetch the /usr/include and /usr/lib directories from scratchbox.  I used zip to pack these up for transfer to the zipit so it would make file copies instead of softlinks for the FAT filesystem used by IZ2S.  I also had to track down libc.so.0 because apparently libc.so is just a script that points to the real libc.so.0 somewhere in bowels of scratchbox.  I edited the libc.so script to remove the scratchbox paths so libc.so.0 could reside in the same directory as libc.so on the zipit.  I also made a compiler.sh script add the /usr/local/share/gcc/bin to the PATH and softlink the various lib and include directories into the proper places in the /usr and /usr/local sections of the filesystem.

This let me build the executable, but it wouldn't run.  It was looking for the /lib/ld-linux.so.2 dynamic linker instead of the /lib/ld-uClibc.so.0 I had on the zipit.  I fixed this temporarily with a softlink, which got the hello program running, but was quite unsatisfying.  After a bit of internet research I went back to the gcc build and edited gcc-4.4.1/gcc/config/arm/linux-elf.h to make LINUX_TARGET_INTERPRETER use the uClibc dynamic linker.  Reconfigure, rebuild, again.

Now hello.c compiles and runs.  Yeah!  So I moved on and I tried to build an IZ2S version of imgv.  It compiles and links against the IZ2S SDL libs.  Yes!  Couldn't do that with the aboriginal compiler.  But it segfaults when I run it.  Drat!  Actually, some of it runs because when I forgot to set the SDL env vars it rotated the screen before segfaulting.  I think that means it was actually doing some of the SDL stuff.  I ran imgv through strace, and it appears to blame gettimeofday?  Weird, but getting closer.  I ccould almost feel it.  I've had mysterious segfaults due to bugs in the ancient IZ2S uclibc so I also compiled imgv with the scratchbox compiler to compare.  It also segfaults on getimeofday so the compiler is off the hook on that one.

I went to my backup SDL test program - fgui.  This also segfaulted, but with a little debugging I tracked it down to the SDL_init call.  It was set to initialize SDL_EVERYTHING including the SDL_CDROM code.  I probably built SDL without cdrom support, so I reduced the init to SDL_VIDEO only and voila, it runs on the zipit.Looking back at imgv I see it inits SDL_VIDEO and the SDL_TIMER.  I bet the timer code is triggering the segfault when it trys to use the buggy uclibc gettimeofday function.  I might just have to rebuild SDL with some new fixes, or see if I can link in the gettimeofday function from libiberty.a instead.  And I should probably review the SDL_Init calls in some of the SDL programs I'd previously abandoned due to mysterious segfaults (like bunjallo and zgv).

So the good news is the native IZ2S compiler appears to work.  Yes!  Here's a screenshot of the freshly compiled fgui SDL test app in action on the zipit.

Now I just need to figure out how best to trim it down and package it up.  Can I get rid of the enormous pre-compiled c++ headers?  Apparently --enable-libstdcxx-pch is on by default.  This is actually a bit of a tough call.  The precompiled headers use 36MB of the precious SD space, but I suspect if I ever do any C++ they'll save gobs of time on the super slow zipit, by appending --include bits/stdc++.h to CXXFLAGS?  Maybe I should run some time tests.

Here's the native compiler (23MB).  iz2s-gcc.zip
The C++ precompiled headers (7MB).  iz2s-gcc-pch.zip
And a snapshot of my usr/local/lib and include dirs (40MB).  iz2s-gcc-usrlocal.zip

The native compiler contains a script (/bin/compiler) that you should source in order to setup some softlinks and environment variables.  You may want to edit he bin/compiler script if you want to enable a swapfile for compiling bigger things.

Update:

I moved the SDL sources to the zipit and did some debugging on the segfault.  Turns out it was pthreads that was causing the segfault in the sdl_timer code, not gettimeofday.  So I did some searching on the internet and discovered some references to problems running pthreads from shared libs (like say SDL).  The fix is in the linking.  I linked with -pthread before -lSDL and -pthread again (for good luck) after the -lSDL and the other SDL libs and now imgv runs just fine.  So does zgv.  Maybe uclibc has some fake pthread functions that get in the way if you don't explicitly link in the real thing?  I don't know, and I also have no idea right now what's the difference between -pthread and -lpthread, so I have some more reading to do...

Here's an imgv package for IZ2S: imgv-iz2s.zip
And here's a zgv executable for IZ2S: zgv-iz2s.zip

And finally, this is what bunjalloo looks like on the zipit.

Sorry for the poor lighting.  It's sorta ironic considering the headline article in the magazine I used for background.

Finch

Shortly after my last post, walrus43 mentioned on the zipit IRC channel that he'd like to get the Finch instant messenger client working on his openwrt zipit.  And he was hoping to accomplish that with the native compiler.  Wow, that's quite a challenge.  I remember that Finch beastie from the trials and tribulations of my IRC client porting days with IZ2S.  At the time I dismissed Finch as far too bloated to even attempt.  It's only C code, but it uses glib, which has a huge list of tricky prerequisites for a uclibc environment.  After several days of fiddling I actually managed to build a finch executable with the native compiler, but I haven't quite got it working with the protocol plugins.  So it's not all that useful in it's current state.  I'll try to finish that up shortly and publish the results, including my fake pkg-config script.

But in the meantime, I switched over to the cross-compiler and a built full working finch package to go along with the libpurple protocol plugin package already available in the zipit openwrt repository.  It's all in git already, but I'm not sure if I have to do any extra steps to force the nightly build system  to recognize the new finch package.  On my local PC I had to do this:

  make package/symlinks
  make menuconfig

Then select the finch package so my next make would build it.

Finch actually runs pretty well, but some of the dialogs are designed for screens taller than a standard  24 or 25 by 80 character terminal.  The default font on slug's openwrt only gives you 20 lines so this can be a bit of a problem.  However it looks like the smaller fonts I created for IZ2S make this workable.  Here's the 30 line preferences dialog with the 5x8iz2s.psf font file.

It might be a good idea to create a wrapper script for finch setup that does this before running finch.

  loadfont < 5x8iz2s.psf

Here's the goodies.  This is my first try.  It works but you may prefer the real ipk file below.

finch-wrt-with-libs.tgz

Unfortunately that finch executable had a bug which caused it to segfault on exit.  I found a defect report on this (#13739) which made it fairly easy to patch, so I rebuilt the finch executable and threw in the smaller IZ2S fonts here.  You still need the libs from the other tarball above.

finch-with-fonts.tgz

The package has arrived, but it doesn't have the smaller fonts or the gmenu2x icon yet.

finch_2.7.11-1_pxa.ipk

Workaround

In the waning summer days since my last blog update I suffered two crushing laptop failures.  Although neither laptop is completely dead, both are pretty much useless to me in their current state.  First, my ancient PIII thinkpad decided it would only run for 3 minutes before an abrupt shutdown.  Very frustrating.  I can just barely open all the windows needed for openwrt coding and then, bam, it's done.  A mere 2 days later the NVIDIA graphics chip fritzed out on my old Dell 620 (the one with the IZ2S development VM).  The poor thing still boots and runs, but I can't see what it's doing.  I'm gonna try to  dismantle it someday and reflow the solder to the graphics chip.  But that won't likely happen for a long time, if ever...

So now I'm down to an early EeePC netbook and a bunch of zipits.  That's just barely enough to workaround my laptop problem, but it'll have to do.  Since I was fresh off a successful rockbox build on the openwrt zipit, I figured that I might as well soldier on with that compiler and see what else it could do.  Unfortunately I tend to work much faster with a real keyboard.  The EeePC keyboard is extremely cramped but I can still sorta touch type without too much pain.  So the first thing I did was to build all the SDL libs on the netbook.   Now I can tinker on the EeePC first, before committing to work on the zipit.

Around the time of the laptop meltdown I managed to convince slug to rebuild the SDL library on his jffs and drop DirectFB to save a whole bunch of space.  I'm thinking a small build of the links browser would be a much better use of the precious jffs space.  But anyhow, he got it working only to discover he needed a way to do the splash screen without DirectFB.  So I poked around and found imgv, already in the openwrt packages.  It uses SDL for the graphics and has some nice features, but was lacking a command line interface that would allow it to run a timed splash screen.  I couldn't imagine an easier project to practice with the native compiler on the zipit.  In almost no time we had a working SDL splash screen and slideshow program, and slug made us a new rc12 jffs with plenty of room to grow.

Then walrus45 followed up on my imgv work and pointed out there was also a zgv openwrt package that could use some lovin.  Once upon a time I took a stab at building zgv for IZ2S because of the spiffy thumbnail image selector, but never got it to do much of anything.  For some reason, this time it was easy.  I just configged it to use SDL instead of svgalib, tweaked the fileselector to fit better in 320x240, and miraculously it all seems to work.  I still gotta get my changes worked up into an openwrt patch for github and the official packages.  Then maybe I'll try and build it with the native compiler on an IZ2S zipit.

You can fit up to 8 thumbnails on screen with the current set of hacks.  Originally it was limited to 2 thumbnails at 320x240, which (as you could imagine) was not terribly useful.  Here it is, zoomed to fullscreen on an old cell phone picture of the dog.  I haven't yet played with the slideshow feature to see how it compares to imgv.

Speaking of beagles...   Also around this time beaglebreath resurfaced and got me going again on the gpio code.  We eventually worked out that the kernel needed a small patch to enable the CIF camera gpios for use in sysfs.  Mozzwald supplied the patch, Slug whipped up a new kernel and voila, the gpios were working.  I managed to build some gpio testing hardware (no solder required ;) and beaglebreath got his weather sensor working on his openwrt zipit.  I'd still like to see if picoc can handle the timing requirements, because I think it'd be cool to have a full gpio prototyping setup on a zipit with no SD card.

 Here's my solder-free gpio test rig.  It's a bit unwieldy but I needed a way to include the pull up resistor to make the open collector gpio pins work.  The three clips on teeny tiny pins of the zipit connector had a habit of falling off whenever I tried to type a gpio sysfs command on the zipit.

Next up, maybe I'll get back to work on the flipclock.  I noticed that dronz recently added a fancy new timezone script to the the goodie bag.  Perhaps I'll try and fold the clock into gmu, with an internet radio scanner based on a shoutcast website that walrus45 pointed out.  Apparently this page works in the links browser, without javascript, although I don't have it working yet.  I tried to set it up via the links menu.  I went to setup>associations, selected "Add" to create a new association for the audio, and then created a new association with these settings:

  "Label":  shoutcast-pls
  "Content-Types(s)":  audio/x-scpls
  "program":  mpg123 -C@ %

I also unchecked something about X-Windows.  It didn't work at first, so I went back to the setup menu and picked "Save Options".  That seemed to do the trick.  Now I need to figure out how to control it better.  For example, Alsa Mixer lets me change the volume, but its a challenge to get there.


Here's the goodies (not much, really):

A zgv executable for openwrt (I still need to update the patches on github)
An imgv ipk for openwrt.

Bedtime Stories

Thanks to some nice folks at CMU, the zipit can now read aloud to me at night.  Apparently things have come a long ways since the eighties when I toiled away in a lab down the hall from the speech guys.  I sorta remember the speech recognition software at that time had some difficulty with my central New England speech patterns.  Or maybe that was a scene from a movie... I can hardly remember it was so long ago.

Anyhow, the flite text to speech system and the accompanying Bard Storyteller epub reader appear to be a perfect fit for the zipit.  If you don't like the "kal16" voice you can set Bard to scroll lazily through the document (still hands free) instead of reading aloud.  That's a step up from my cheesy links2 based ereader.  The only issue I've run into so far is the poor rendering quality of the pictures at the 320x240 resolution of the zipit.  I might take a stab at fixing that someday.

Here it is reading a relaxing bedtime story acquired from the archives at Project Gutenberg.  I feel sleepy already...

For some reason the name and the sound quality of the kal16 voice made me think of "Karel the Robot", the intro to programming book used at CMU way back in the early eighties.  Or maybe it was just that story.  I don't know.

I put the zipit patches for this on github, so pretty soon now the nightly build should generate some official ipk files.  I really wish git would make that easier, instead of giving me trouble every single time I try use it...  Meanwhile, here are some openwrt ipk packages that work for me.

bard_0.7-1_pxa.ipk
flite_1.5.5-1_pxa.ipk 
libzip_0.10.1-1_pxa.ipk

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