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
Fun with software, gizmos, virtual bricks, and other geeky toys.
Showing posts with label rockbox. Show all posts
Showing posts with label rockbox. Show all posts
Thursday, June 21, 2012
Tuesday, May 29, 2012
Memorial Day
I really like the English version of the latest jffs dronz put together! It's got just about everything I want on the zipit. But I did make a few changes over the Memorial Day holiday.
First I fixed a tinyirc bug so it no longer wraps the status bar when using the large 8x14 font. I tend to use a smaller font so I didn't notice the bug right away. Sorry.
Then I went to work, making it just a wee bit more user friendly, at least for me. I'm starting to appreciate gmenu2x as a program launcher, so I wanted that available right away on boot up, with no extra work. At first I tried to get it going from the Zcovery startup script, using the toybox nohup to work around a problem with the hangup signal. (Just like we did in olden days with the dialup modems). But nohup wants to redirect stdout, which is troublesome for text terminal programs launched from gmenu2x. So instead I simply fixed the bin/gmenu script to trap sighup just like on slug's jffs. No more hangups means I can launch from the Zcovery startup script. Yay!
With that problem solved, I modified Zcovery to first start a shell prompt in the background on tty1, then switch to tty2 to run gmenu2x. Works like a charm. But I'm pretty old school, so I want to get at that command prompt on tty1 at least half of the time. To make it easy to switch between gmenu2x and tty1 I modified the three keymap files so ctrl-alt-home always goes to the command line shell on tty1. I'm not actually sure I got this right in the calculator keymap, but I may try to eliminate the calculator keymap someday by remapping the keys inside the script like I did with zcalc. Then I'd only need to maintain two keymaps. Anyhow, ctrl-alt-home should work from gmenu2x or any SDL or text program launched by gmenu2x. Then alt-rightarrow will get you to the gmenu2x text screen on tty2 and another alt-rightarrow will get you to it's graphics screen on tty3. Sometimes the gmenu2x graphics remain on the screen after ctrl-alt-home, but you can clear that by typing cls or by pressing alt-rightarrow then alt-leftarrow to go to the gmenu text screen on tty2 and back to the command shell on tty1. In this setup, SDL programs tend to run the graphics on tty3, leaving the text screen on tty2 in limbo. With gmu and links you can type ctrl-z and bg on tty2 to free up the shell, however this is not advisable when running things from gmenu2x as it wants to manage both tty2 and tty3 for it's program launching scheme.
Once things were working satisfactorily, I decided to Americanize a few settings. I changed the timezone file and switched the time format in the clock and alarm scripts to 12 hour time with no seconds because that's what I use here. Since 99.9% of the time I only read things in English on the internet, I decided to compile an ASCII only version of links with SSL to save 200k on the jffs. I'm seriously considering using the much smaller SSL-free ASCII only version to save even more. I can always keep a full version of links on the SD card. I also removed the green gmenu2x background. I'd prefer to simply replace the wallpaper file if I ever get tired of the blue one. That saves a few more K.
I used all that saved space to add the rockbox executable and a single codec to the jffs. The rest of the codecs are softlinks to the jffs addon pack (or the normal IZ2S rockbox package) on the SD card. Yeah, I know... rockbox doesn't really make any sense on the jffs because you still need an SD card for the music files, but I'm smitten by the coolness factor of it all. Actually, now that I'm hooked on multiple ttys I may need to build a new rockbox executable because the current one doesn't realize it's supposed to give up drawing things when I switch to tty1.
There's still more Americanizing to do. The gmenu2x glinks app file sends the browser to the french portal by default. I'm OK with that for now, because it points to lots of handy zipit friendly internet sites. I also need to switch a few other things like the gmenu2x settings tab to english. But I think I'd like to get a build out there now because I like the new boot sequence so much.
In the future I still want to try swapping MatrixSSL into links instead of OpenSSL. And I'd like to switch to slug's gmenu2x sources, then hookup the wifi icon and paste in the IZ2S battery monitoring code that I used for rockbox. Both of these efforts should save considerable jffs space. I also want to add the new set timezone script to the initial boot sequence. Then maybe I'll get back to bunjallo for a browser choice somewhere between links and retawq in size and functionality. Or maybe I'll see if it's possible to dim the status LEDs (like the backlights) or just turn them completely off when the alarm clock is running. They're way too bright for night time.
I also need to figure out a better way to organize the goodie bag. Dronz has been busy adding everything, which is great, but now there's so much in there I can't remember what it all is. I'm not sure what would help. Short descriptions? Dates? Pointers back to the original blog posts? Gotta think about it...
Here's the Americanized jffs. iz2jffs-v4-en.tgz
The old install instructions should suffice.
Here's the new keymap files with src, plus the new gmenu, tinyirc, and Zcovery. That should make it easy to update the French version. gmenu-jffs-fixes.zip
I forgot to include the tinyirc source code with the fixes the so I'll pastebin tinyirc.c
First I fixed a tinyirc bug so it no longer wraps the status bar when using the large 8x14 font. I tend to use a smaller font so I didn't notice the bug right away. Sorry.
Then I went to work, making it just a wee bit more user friendly, at least for me. I'm starting to appreciate gmenu2x as a program launcher, so I wanted that available right away on boot up, with no extra work. At first I tried to get it going from the Zcovery startup script, using the toybox nohup to work around a problem with the hangup signal. (Just like we did in olden days with the dialup modems). But nohup wants to redirect stdout, which is troublesome for text terminal programs launched from gmenu2x. So instead I simply fixed the bin/gmenu script to trap sighup just like on slug's jffs. No more hangups means I can launch from the Zcovery startup script. Yay!
With that problem solved, I modified Zcovery to first start a shell prompt in the background on tty1, then switch to tty2 to run gmenu2x. Works like a charm. But I'm pretty old school, so I want to get at that command prompt on tty1 at least half of the time. To make it easy to switch between gmenu2x and tty1 I modified the three keymap files so ctrl-alt-home always goes to the command line shell on tty1. I'm not actually sure I got this right in the calculator keymap, but I may try to eliminate the calculator keymap someday by remapping the keys inside the script like I did with zcalc. Then I'd only need to maintain two keymaps. Anyhow, ctrl-alt-home should work from gmenu2x or any SDL or text program launched by gmenu2x. Then alt-rightarrow will get you to the gmenu2x text screen on tty2 and another alt-rightarrow will get you to it's graphics screen on tty3. Sometimes the gmenu2x graphics remain on the screen after ctrl-alt-home, but you can clear that by typing cls or by pressing alt-rightarrow then alt-leftarrow to go to the gmenu text screen on tty2 and back to the command shell on tty1. In this setup, SDL programs tend to run the graphics on tty3, leaving the text screen on tty2 in limbo. With gmu and links you can type ctrl-z and bg on tty2 to free up the shell, however this is not advisable when running things from gmenu2x as it wants to manage both tty2 and tty3 for it's program launching scheme.
Once things were working satisfactorily, I decided to Americanize a few settings. I changed the timezone file and switched the time format in the clock and alarm scripts to 12 hour time with no seconds because that's what I use here. Since 99.9% of the time I only read things in English on the internet, I decided to compile an ASCII only version of links with SSL to save 200k on the jffs. I'm seriously considering using the much smaller SSL-free ASCII only version to save even more. I can always keep a full version of links on the SD card. I also removed the green gmenu2x background. I'd prefer to simply replace the wallpaper file if I ever get tired of the blue one. That saves a few more K.
I used all that saved space to add the rockbox executable and a single codec to the jffs. The rest of the codecs are softlinks to the jffs addon pack (or the normal IZ2S rockbox package) on the SD card. Yeah, I know... rockbox doesn't really make any sense on the jffs because you still need an SD card for the music files, but I'm smitten by the coolness factor of it all. Actually, now that I'm hooked on multiple ttys I may need to build a new rockbox executable because the current one doesn't realize it's supposed to give up drawing things when I switch to tty1.
Stock zipit boots into gmenu2x and plays the zipit sound in rockbox with no SD card.
There's still more Americanizing to do. The gmenu2x glinks app file sends the browser to the french portal by default. I'm OK with that for now, because it points to lots of handy zipit friendly internet sites. I also need to switch a few other things like the gmenu2x settings tab to english. But I think I'd like to get a build out there now because I like the new boot sequence so much.
In the future I still want to try swapping MatrixSSL into links instead of OpenSSL. And I'd like to switch to slug's gmenu2x sources, then hookup the wifi icon and paste in the IZ2S battery monitoring code that I used for rockbox. Both of these efforts should save considerable jffs space. I also want to add the new set timezone script to the initial boot sequence. Then maybe I'll get back to bunjallo for a browser choice somewhere between links and retawq in size and functionality. Or maybe I'll see if it's possible to dim the status LEDs (like the backlights) or just turn them completely off when the alarm clock is running. They're way too bright for night time.
I also need to figure out a better way to organize the goodie bag. Dronz has been busy adding everything, which is great, but now there's so much in there I can't remember what it all is. I'm not sure what would help. Short descriptions? Dates? Pointers back to the original blog posts? Gotta think about it...
Here's the Americanized jffs. iz2jffs-v4-en.tgz
The old install instructions should suffice.
Here's the new keymap files with src, plus the new gmenu, tinyirc, and Zcovery. That should make it easy to update the French version. gmenu-jffs-fixes.zip
I forgot to include the tinyirc source code with the fixes the so I'll pastebin tinyirc.c
Saturday, February 4, 2012
Starting Over, Again.
In my previous blog entry I mentioned a bunch of goodies and ideas provided by dronz just as I was going to press with the blog post. It took a lot longer than I expected, but I think I've finally got most of it incorporated into a new jffs base. Originally I expected to break it into a bunch of additions, but as I rummaged through the goodies I realized much of it really belonged in the base jffs package. So it had to be small. The first thing I noticed was a proliferation of upxed executables from the original IZ2S and EZ2S systems that simply access a GPIO line to the zipit LEDs and buttons and such. I figured these presented a perfect opportunity to roll them all into a single multi-call binary (mbc) executable and really save some space. I was even hoping to toss in the IZ2S power button and screenblanker demons since they access the same GPIOs.
It actually turned out to make the most sense to create 2 mcb executables and leave the demons alone. The static linked demons were the most efficient with memory at runtime, and don't take up all that much disk space. Especially considering all the other savings I was getting from the two mcbs. You can see the two static linked daemons in this htop screenshot, using a mere 16K of resident (RES) memory each while running.
The shared versions use significantly more RES memory, although there is the possibility that some of that will be recovered by sharing (SHR) with more programs running. Here you can see the shared version of the screenblanker on the blue line with the two original static daemons on the two lines below.
I'm also starting to rethink upx. It imposes a 4k runtime memory penalty, which is not so bad, but it also starts it's disk compression 4k or so behind the builtin (gzip?) compression on the jffs. Now upx seemed to win somewhat in my minimal testing on the fairly large busybox and rockbox executables, but it's really hard to be sure when working on a live jffs because you never know when the jffs garbage collection will kick in and throw off all the numbers. I really prefer to just make the executables tiny and let the jffs compress them. Here's a shot of the original IZ2S daemons using 4k more memory after being upxed.
To make matters more difficult for me, the original IZ2S daemons were built in an earlier scratchbox environment that's a bit more frugal than the one I'm using. I've experimented with dietlibc and musl libc to see if I could duplicate some of that frugality with the mcb executables, but the gcc wrapper used by my scratchbox environment conflicts with the gcc wrappers used by dietlibc and musl, to that's gonna take some serious work to get any sort of results. Oh well.
Anyhow, the new additions from dronz also included some upxed helper utilities such as tee, clear, and date to pull in more functionality such as timezone, and hex passphrase management from the EZ2S network setup scripts. I set about recompiling tiny shared lib versions of those, as well as replacing the large static sed, grep, and ntpdate programs from IZ2S with dynamic builds of minised, ugrep, and ntpclient for a rather large savings of several hundred K on the jffs. I also threw in a new setup-tz.sh script to help get a /etc/TZ file generated after a fresh jffs install.
Now if you're off the wifi grid with your zipit, you can still set the time and date either interactively or on the command line with the new date utility. Simply type date MMDDhhmmYYYY with the appropriate Month, Day, hours, minutes, and Year on the command line, or run /mnt/ffs/bin/date -i to do it interactively.
Also amongst the new goodies were some additions for better sound out of rockbox, however since I'd already ditched the massive alsactl utility in favor of the smaller amixer program these required some changes to the rockbox script to make them work. I modified things to use amixer and it seems ok now, saving and restoring sound settings in the rockbox script. I also renamed the original /mnt/ffs/share/rockbox/eqs/Default.cfg file to Rockbox.cfg and switched to the dronz "hifi" Default.cfg file. This apparently gets you better sound than the original default eq settings. However I'm not positive how to activate the eq settings. If I had to guess, I'd say go into the Settings/Sound/Equalizer menu and select Enable, then Browse to pick the Default config file.
By the way, dronz points out that you can save gobs of space on the jffs by deleting codecs you don't use from the /mnt/ffs/lib/rockbox/codecs directory. He's got better ears than I, so he deletes the MP3 codec file mpa.codec. I'd probably go the other way and delete most of the others...
Since I was now committed to remaking the base system I decided to throw in some more font support for the Western European characters. The /mnt/ffs/share/fonts/erusfont.psf console font has slightly larger glyphs and is thus a bit more legible than the default font. It may also have more unicode glyphs than the default font. Feel free to edit the font loading line of the Zcovery script to suit your preference. You can also load the /mnt/ffs/etc/eurokeymap.kmap instead of the default keymap.kmap. This keymap provided by dronz allows you to use special key combos to type uincode text with the zipit keyboard. I had trouble with this in the bash shell on IZ2S (maybe I'm missing some language setting environment variables) but it works pretty well in the busybox sh shell on the jffs. I also couldn't get the eurokeymap to work in the e3 editor. However the nano editor handle the unicode typing so I'm providing a separate package for that with a slightly smaller build than the statically linked IZ2S nano executable.
If you wish, you can add more fonts. I recommend installing non .gz versions of the fonts on the jffs because the base system won't load .gz fonts and the jffs uses gzip compression anyhow, so the file size is effectively the same.
Finally, there's also a set of replacement kernel modules from dronz that you can use to enable auto-repeating keys, so you don't wear out your thumbs quite as fast.
Whew! That's a big post. Here's the goods, starting with the new base. Follow the instructions from the earlier post to install it.
iz2jffs-base-v2.tar.bz2
Oops. Apparently the new timezone script leaves you at a blank screen. Here's the fix: tz-iz2s.zip.
The mini Rockbox is now a separate install after the base.
And I still need to wrap up the final version of the source code for the IZ2S mcbs...
Here's the nearly final version of iz2s-pwr-src.tgz just in case i lose track of this...
It actually turned out to make the most sense to create 2 mcb executables and leave the demons alone. The static linked demons were the most efficient with memory at runtime, and don't take up all that much disk space. Especially considering all the other savings I was getting from the two mcbs. You can see the two static linked daemons in this htop screenshot, using a mere 16K of resident (RES) memory each while running.
Anyhow, the new additions from dronz also included some upxed helper utilities such as tee, clear, and date to pull in more functionality such as timezone, and hex passphrase management from the EZ2S network setup scripts. I set about recompiling tiny shared lib versions of those, as well as replacing the large static sed, grep, and ntpdate programs from IZ2S with dynamic builds of minised, ugrep, and ntpclient for a rather large savings of several hundred K on the jffs. I also threw in a new setup-tz.sh script to help get a /etc/TZ file generated after a fresh jffs install.
Now if you're off the wifi grid with your zipit, you can still set the time and date either interactively or on the command line with the new date utility. Simply type date MMDDhhmmYYYY with the appropriate Month, Day, hours, minutes, and Year on the command line, or run /mnt/ffs/bin/date -i to do it interactively.
Also amongst the new goodies were some additions for better sound out of rockbox, however since I'd already ditched the massive alsactl utility in favor of the smaller amixer program these required some changes to the rockbox script to make them work. I modified things to use amixer and it seems ok now, saving and restoring sound settings in the rockbox script. I also renamed the original /mnt/ffs/share/rockbox/eqs/Default.cfg file to Rockbox.cfg and switched to the dronz "hifi" Default.cfg file. This apparently gets you better sound than the original default eq settings. However I'm not positive how to activate the eq settings. If I had to guess, I'd say go into the Settings/Sound/Equalizer menu and select Enable, then Browse to pick the Default config file.
By the way, dronz points out that you can save gobs of space on the jffs by deleting codecs you don't use from the /mnt/ffs/lib/rockbox/codecs directory. He's got better ears than I, so he deletes the MP3 codec file mpa.codec. I'd probably go the other way and delete most of the others...
Since I was now committed to remaking the base system I decided to throw in some more font support for the Western European characters. The /mnt/ffs/share/fonts/erusfont.psf console font has slightly larger glyphs and is thus a bit more legible than the default font. It may also have more unicode glyphs than the default font. Feel free to edit the font loading line of the Zcovery script to suit your preference. You can also load the /mnt/ffs/etc/eurokeymap.kmap instead of the default keymap.kmap. This keymap provided by dronz allows you to use special key combos to type uincode text with the zipit keyboard. I had trouble with this in the bash shell on IZ2S (maybe I'm missing some language setting environment variables) but it works pretty well in the busybox sh shell on the jffs. I also couldn't get the eurokeymap to work in the e3 editor. However the nano editor handle the unicode typing so I'm providing a separate package for that with a slightly smaller build than the statically linked IZ2S nano executable.
If you wish, you can add more fonts. I recommend installing non .gz versions of the fonts on the jffs because the base system won't load .gz fonts and the jffs uses gzip compression anyhow, so the file size is effectively the same.
Finally, there's also a set of replacement kernel modules from dronz that you can use to enable auto-repeating keys, so you don't wear out your thumbs quite as fast.
Whew! That's a big post. Here's the goods, starting with the new base. Follow the instructions from the earlier post to install it.
iz2jffs-base-v2.tar.bz2
Oops. Apparently the new timezone script leaves you at a blank screen. Here's the fix: tz-iz2s.zip.
The mini Rockbox is now a separate install after the base.
rockbox-391-jffs.tar.bz2
Dronz says: You can save some space by replacing the default cabview theme with this 4k theme and the 14-Terminus-Bold.fnt font from the rockbox font pack (or this slimmer version of the font Lat15-TerminusBold14.zip).
Dronz says: You can save some space by replacing the default cabview theme with this 4k theme and the 14-Terminus-Bold.fnt font from the rockbox font pack (or this slimmer version of the font Lat15-TerminusBold14.zip).
Here's the typematic keyboard goodies from dronz.
And the smaller (shared lib) nano editor.
This loadkeys program can be used in IZ2S to convert keymaps to the binary .kmap format used on by the jffs base.
Oh yeah, here's the updated naim IM client that uses the still functioning OSCAR protocol. I still couldn't tell if it works though...
The handy IZ2S busybox update is still available in here.
And I still need to wrap up the final version of the source code for the IZ2S mcbs...
Here's the nearly final version of iz2s-pwr-src.tgz just in case i lose track of this...
Friday, December 30, 2011
Christmas Special
Sometime around Christmas rkdavis mentioned something about loading sdlBasic on the stock zipit jffs instead of rockbox. Since I eventually want gmu on a zipit to be used as a dedicated internet radio, I figured maybe it was a good time to start separating the base jffs goodies from the rockbox stuff.
I also wanted to tinker with the wifi setup scripts. I really like the easy dialog based EWoC wifi script included in later IZ2S releases, but I don't want to waste 200K of the jffs on the dialog executable. So I dug deep into the dark old corners of the internet to review what could be done with ANSI escape sequences instead. I found some really promising stuff and a related book that I'm gonna buy.
But it proved difficult getting things to work well with the builtin echo command from the stock busybox sh. And running ANSI escape codes with the external echo or printf commands from the IZ2S replacement busybox was just horribly slow. So this is all I've got so far: The previous SSID used shows up in green! Not pretty, and my horrible photo skills don't help much either, but at least it's a marginal improvement.
Follow the directions from the previous blog post to install the smaller base system. Then add whatever you want: sdlBasic, busybox, tinyirc, or anything else that fits... (Hmm, it looks like you'll need to add either the full sed from the original package, or add busybox for its sed, otherwise the wifi scripts won't work.)
iz2jffs-base.tar.bz2
Anyhow, I trimmed down the old sdlBasic to something that I think will fit in the jffs on top of the base system. I actually had to rebuild the executable because the previous build was pulling in libstdc++ due to my lame makefile. That would have been 3 megabytes of completely wasted space on the jffs. With libstdc++ out of the picture, I got all the libs needed for the sdlBasic runtime collected together. I removed the docs and included only the Beast and Sokoban demos to save space. Here's a nice blurry pic of me beating up on Sokoban level 1 to convince you that you absolutely must have it.
I personally don't want to mess up the jffs right now on my zipit by replacing rockbox with sdlBasic, so if anyone else tries it be sure to let me know how well (or not) it fits.
sdlbasic-iz2jffs.zip
Meanwhile, on the complete opposite end of the spectrum from this tiny stuff, I finally put up a download link for the Emacs I built for IZ2S way back when. It's so handy, I feel compelled to share it.
I also wanted to tinker with the wifi setup scripts. I really like the easy dialog based EWoC wifi script included in later IZ2S releases, but I don't want to waste 200K of the jffs on the dialog executable. So I dug deep into the dark old corners of the internet to review what could be done with ANSI escape sequences instead. I found some really promising stuff and a related book that I'm gonna buy.
iz2jffs-base.tar.bz2
Anyhow, I trimmed down the old sdlBasic to something that I think will fit in the jffs on top of the base system. I actually had to rebuild the executable because the previous build was pulling in libstdc++ due to my lame makefile. That would have been 3 megabytes of completely wasted space on the jffs. With libstdc++ out of the picture, I got all the libs needed for the sdlBasic runtime collected together. I removed the docs and included only the Beast and Sokoban demos to save space. Here's a nice blurry pic of me beating up on Sokoban level 1 to convince you that you absolutely must have it.
sdlbasic-iz2jffs.zip
Meanwhile, on the complete opposite end of the spectrum from this tiny stuff, I finally put up a download link for the Emacs I built for IZ2S way back when. It's so handy, I feel compelled to share it.
Tuesday, September 6, 2011
Thinking Small
Apparently the Zipit folks have obsoleted the original built-in app on the Zipit Z2. This means the jffs on the internal 8MB flash contains about 5.5MB of useless applications and data. Worse yet, it's supposedly possible to get the stock app stuck in some sort of infinite loop of update requests if it's never been connected to Zipit wireless for an initial firmware update. Now I've never experienced this myself, but I also haven't booted a new Zipit into the stock app for quite a while now. If you're really worried about it you should probably bypass IZ2S and run the latest FlashStock to replace the firmware with uboot and the spiffy rescue image. Then you can run one of the many uboot userlands like z2lite.
However uboot is significantly slower to boot than the stock bootloader, and all of the uboot userlands seem to require reformatting your SD card to ext2, which may significantly shorten the lifespan of the SD. So I got to thinking, maybe I should consider replacing the stock app on the internal jffs. Now, what could I fit into 5.5MB? A minimal Rockbox installation would be sweet. I could also go for a minimal gmu install to turn the Zipit into a dedicated internet radio device requiring no SD card. But both of these apps are just a wee bit bloated for the 5.5MB available on the internal flash. So how do I make them fit? We could use an IZ2S version of UPX to cut the executables and libs down to about one third the size. Then things just might fit.
The UPX source compiled without a hitch and seemed to work just fine on the IZ2S rockbox executable. Supposedly the source version of UPX has somewhat lower performance than the pre-built UPX executables, but sometimes you just have to take what you can get. It's probably good enough for my purposes. Now I just need to sacrifice the stock app on one of my Zipits and then see what fits. Meanwhile, here's the UPX executable for IZ2S.
upx-iz2s.zip
However uboot is significantly slower to boot than the stock bootloader, and all of the uboot userlands seem to require reformatting your SD card to ext2, which may significantly shorten the lifespan of the SD. So I got to thinking, maybe I should consider replacing the stock app on the internal jffs. Now, what could I fit into 5.5MB? A minimal Rockbox installation would be sweet. I could also go for a minimal gmu install to turn the Zipit into a dedicated internet radio device requiring no SD card. But both of these apps are just a wee bit bloated for the 5.5MB available on the internal flash. So how do I make them fit? We could use an IZ2S version of UPX to cut the executables and libs down to about one third the size. Then things just might fit.
The UPX source compiled without a hitch and seemed to work just fine on the IZ2S rockbox executable. Supposedly the source version of UPX has somewhat lower performance than the pre-built UPX executables, but sometimes you just have to take what you can get. It's probably good enough for my purposes. Now I just need to sacrifice the stock app on one of my Zipits and then see what fits. Meanwhile, here's the UPX executable for IZ2S.
upx-iz2s.zip
Wednesday, August 24, 2011
Loose Ends
I managed to build both an IZ2S and a z2lite rockbox 3.9 release over the weekend. You can find them in the Zipit Z2 goodie bag (link on the right). I also built a common plugin package that works on both. Well... Ok, I tested the rockblox plugin on both userlands and it seemed to work. I'm extrapolating that success onto the rest of the plugins. Actual mileage may vary.
Meanwhile the new ldraw forum is still active, and so the bug reports keep rolling in. Maybe it's just that the programs simply need more documentation. I've wondered for a while now how to best handle lsynth parts in ldglite, and how best to push them through lpub. Others have apparently been thinking the same thing. Fortunately I just got a new Windows 7 PC. Just in time to shake out some of these issues, and to try the new All In One Installer for ldraw. The result is I've gotta put out a new ldglite release with some updated search path support, in addition to the new color support I did a little while ago. Also, I think I finally see how to incorporate synthesized parts in lpub. The result should look something like this.
What worked for me was to break out the synthesized part(s) into separate files and make sure to tag them as part files with this meta-command in the header:
"0 !LDRAW_ORG Unofficial_Part".
This technique also works in one big mpd file if you don't want a bunch of separate files.
Sunday, April 10, 2011
A new day brings some new stuff for an old IZ2S.
Remember that bit about the double trouble? Well, forget it. Sometimes I have no idea what I'm talking about.
I still don't really know what prevents me from puting a working libasound together. It could simply be one of the zillions of ALSA config files is busted for all I know. However I was successful with the salsa embedded ALSA lib. I managed to build it and actually got some test programs from a beat up old Linux Journal to work. I played with these for a bit, did some reading about "safe ALSA", and compared the way SDL wanted to use ALSA to the working mpg123 and aplay executables. It turns out the simplistic buffering strategy used by SDL is probably ok for games, but not so good for gapless music playback on a stressed out low MHz linux box (like the zipit running IZ2S). So I mercilessly hacked the SDL_alsa_audio.c file to make it behave more like the other programs. Then I built a new libSDL with my changes, and with the tiny salsa library built right in.
If you like, you can replace the old libSDL in IZ2S with sdl-salsa-iz2s.zip. Then set SDL_AUDIODRIVER=alsa instead of dsp and go. I recycled some rather under-utilized SDL_ALSA environment variables, just in case you want to play around and adjust the buffering scheme. These are (lightly) documented in a text file included with the lib.
I also put together a real gmu-0.7.2-iz2s.zip package with the new libSDL since it no longer skips on IZ2S. I must say GMU is really handy for debugging the audio code. It's well written and easy to follow, unlike the gigantipus that is rockbox.
I happen to like rockbox though. So I rebuilt the IZ2S version with a more recent branch of code. It has better (but not quit perfectly smooth) battery monitoring. It can now change codecs on the fly and it no longer needs to move config files in and out of the /tmp directory. It also seems to quit after 10 minutes on pause. Perhaps that might help with the IZ2S power management? I also let it use the standard linux file structure which prefers to install in the /usr/local directories instead of the embedded setup using the /.rockbox directory. I'm not sure how much I like that, but for now it lets me keep the old and new versions installed at the same time for testing. Here it is. rockbox-iz2s-t11.zip
Finally, here's an ebindkeys executable for IZ2S with a setup to make the home key launch rockbox. That's a single easy to find button so I can start it up in the car at night without turning on all the lights. And here's another tip for the car. Add a line to the startup script to soft link your music directory to /audio so it's right at the top of the rockbox file browser for quick and easy access.
Update: It's a bit trickier to install rockbox themes on the new release. You'll need to CD to the share directory on your SD card and temporarily rename the rockbox directory in there to .rockbox. Then you can unzip an Ipod Video theme into the .rockbox directory. Rename it to back to rockbox and you're done.
Also, unlike rockbox GMU only allows one key binding per function. With the wide variation in default key mappings among IZ2S versions, this means that sometimes the volume is controlled via the +/- keys on the side of the zipit, and sometimes you'll have to use the prev/next keys. So if you're using IZ2S 2.04 with it's default keymap and you want the volume controls on the side then you should edit the gmuinput.z2.conf file and near the bottom replace this:
with this:
I suppose I could try to patch the code to work around this limitation. Or maybe distribute several different GMU config files with the package. I'll make a decision someday...
I still don't really know what prevents me from puting a working libasound together. It could simply be one of the zillions of ALSA config files is busted for all I know. However I was successful with the salsa embedded ALSA lib. I managed to build it and actually got some test programs from a beat up old Linux Journal to work. I played with these for a bit, did some reading about "safe ALSA", and compared the way SDL wanted to use ALSA to the working mpg123 and aplay executables. It turns out the simplistic buffering strategy used by SDL is probably ok for games, but not so good for gapless music playback on a stressed out low MHz linux box (like the zipit running IZ2S). So I mercilessly hacked the SDL_alsa_audio.c file to make it behave more like the other programs. Then I built a new libSDL with my changes, and with the tiny salsa library built right in.
If you like, you can replace the old libSDL in IZ2S with sdl-salsa-iz2s.zip. Then set SDL_AUDIODRIVER=alsa instead of dsp and go. I recycled some rather under-utilized SDL_ALSA environment variables, just in case you want to play around and adjust the buffering scheme. These are (lightly) documented in a text file included with the lib.
I also put together a real gmu-0.7.2-iz2s.zip package with the new libSDL since it no longer skips on IZ2S. I must say GMU is really handy for debugging the audio code. It's well written and easy to follow, unlike the gigantipus that is rockbox.
I happen to like rockbox though. So I rebuilt the IZ2S version with a more recent branch of code. It has better (but not quit perfectly smooth) battery monitoring. It can now change codecs on the fly and it no longer needs to move config files in and out of the /tmp directory. It also seems to quit after 10 minutes on pause. Perhaps that might help with the IZ2S power management? I also let it use the standard linux file structure which prefers to install in the /usr/local directories instead of the embedded setup using the /.rockbox directory. I'm not sure how much I like that, but for now it lets me keep the old and new versions installed at the same time for testing. Here it is. rockbox-iz2s-t11.zip
Finally, here's an ebindkeys executable for IZ2S with a setup to make the home key launch rockbox. That's a single easy to find button so I can start it up in the car at night without turning on all the lights. And here's another tip for the car. Add a line to the startup script to soft link your music directory to /audio so it's right at the top of the rockbox file browser for quick and easy access.
Update: It's a bit trickier to install rockbox themes on the new release. You'll need to CD to the share directory on your SD card and temporarily rename the rockbox directory in there to .rockbox. Then you can unzip an Ipod Video theme into the .rockbox directory. Rename it to back to rockbox and you're done.
Also, unlike rockbox GMU only allows one key binding per function. With the wide variation in default key mappings among IZ2S versions, this means that sometimes the volume is controlled via the +/- keys on the side of the zipit, and sometimes you'll have to use the prev/next keys. So if you're using IZ2S 2.04 with it's default keymap and you want the volume controls on the side then you should edit the gmuinput.z2.conf file and near the bottom replace this:
Button73=280,Volume+
Button-74=281,Volume-
with this:
Button73=270,Volume+ Button74=269,Volume-
I suppose I could try to patch the code to work around this limitation. Or maybe distribute several different GMU config files with the package. I'll make a decision someday...
Subscribe to:
Posts (Atom)