Wednesday, November 25, 2020

Sound the Alarm!

 Well, wouldn't you know...  It's time for yet another holiday season to be "celebrated" under strict covid lockdown!  So I was gonna call this story "The Holiday Formerly Known as Thanksgiving", but I've already done that title, or at least something quite similar.  And I prefer to produce only the freshest nuggets of high quality content.  So instead of grumbling about the holiday that might've been, I'm gonna sound the alarm with this tiny tale of what can only be described as the most zipit alarm clock, ever.

This is the old clock, not the zipit clock

Now I realize I've dipped into this well before, but this time is truly special because I'm totally invested in the outcome.  You see my former alarm clock -- an all-in-one alarmClockRadioPhone purchased long ago when Radio Shack was a thing -- has finally passed on to another existence that clearly does not involve monitoring the passage of time.  It's dead, Jim.  And so it must be replaced ASAP lest I find myself late for some early morning Zoom meeting of ultra vital importance.  You all know how that is I'm sure.  Meanwhile, I'm an old crank so don't even bother to suggest how my smart phone can totally do all those things and so much more.  Yes, yes, I know!  But the darn thing has a touch screen interface, and that makes it simply unsuitable for covert operation in a darkened room.  Not to mention the screen blanker.  Great for battery life, but it renders impossible any sort of casual consultation upon return to bed from the usual 3 AM restroom visit.  And don't get me started on the bothersome late night texts, alerts, and spam calls.  That thing is banned from the bedroom.  So yes, I'm truly motivated to make the zipit clock right this time.

The zipit flipclock app of my former essays is pretty darn spiffy, but it's far too bright for nighttime use if you're actually planning to sleep.  And this can't be remedied without ruining the aesthetics.  So I reached a bit further back in the bag of tricks and took a second look at the ttyclock sources.  At first I simply tried it with red numbers and the largest font in my possession that could render it complete on the zipit screen.  The red numbers won't roast your eyeballs in the dark, but the digits are still sorta small for a quick glance from far away across the room.

You've probably seen this one before

Sadly, the largest font can only fit the hours, but the character height is close to ideal.

Not quite

Eventually it dawned on me that ttyclock emulates a BOLD font with double-wide digits.  So I whipped up a new build with a skinny digit option.  This version fills the tiny zipit screen with minimal waste when rendered with the 32 pixel tall character blocks of the large terminus console font.  As a bonus, that font is already used by my cheesy setclock app and the matching, if somewhat inadequate, alarm app.  At this point I felt I had an adequate replacement for the 7 segment LED display of the deceased all-in-one alarm clock.  

That's the stuff

But then I chanced upon the graceful lines of the gluqlo flipclock on github, and imagined how that might look in red.  The code makes use of sdl and a ttf font for the display, which makes it a really nice fit for the zipit.  So I hacked the code to add an option for red, and took it for a test drive.  It looks pretty darn sweet when viewed from a certain angle.  I also added an option to display an alarm time down below on the right in the margins.

I like it!

Even so the zipit is less than ideal for this purpose, with several considerable shortcomings, especially for nighttime operation.  The zipit's three status LEDs are simply blinding at night, and must be dealt with.  The adjustable screen and keyboard backlight gradients are far too granular.  Try it yourself.  Turn off the lights and press the ctrl-volume or shift-volume buttons to adjust the backlights.  There's simply too much light at the lowest setting above zero.  And the display backlight leaks out the side of the screen like nobody's business.  Meanwhile the optimal viewing angle on the zipit is quite narrow.  As you rotate outside the viewzone the digits disappear into the leaky backlight which washes over you with the cold white intensity of an auto headlight.  I swear you could read a book in that glare.  

I've addressed these issues as best I could, and have used the zipit this way for about two months now. So it's good enough, if only just barely.  My alarm and clock apps both use a wrapper script to temporarily disable the status LEDs.  It took a while to sort out the best method because we've got kernel notification events tangled up with the ebindkeys daemon.  The details for dealing with this are found in the small /etc/init.d/S11z2-leds script and the /etc/ebindkeysrc config file.  For temporary LED light relief it's better to set the triggers to "none" than set the brightness to 0.  And be aware that "S11z2-leds restart" does nothing.  You must use "start" to restart.  Also, ebindkeys does not restore the charging LED trigger properly after a notification.  For the backlights I decided I needed 3 levels of auto dimmer adjustments to tune it between daylight and sleep at certain hours, with a manual override via the spacebar.  To automate it I needed to put that fix in the gluqlo C code.  Meanwhile the alarm itself is still implemented in a wrapper script that runs in the background behind the gluqlo clock display.  

Nothing new here...

Perhaps someday I'll find the time to integrate the whole mess into the C code, and also incorporate a GUI for various music options.  In other news, while testing I grew tired of entering the time of day via the setclock app after every reboot.  The alt key for numbers gets wearysome.  So I added a webtime app to do it via the magic of the internet.  I also had to update the /etc/TZ file with explicit spring ahead and fall back settings.  eg.  EST5EDT,M3.2.0,M11.1.0

It looks right at home there

 The sources and bleeding edge openwrt zipit binaries are available on github.

gluqlo_wrt_be_1_1.tgz

ttyclock_wrt_be_2_0_1.tgz 



Monday, June 8, 2020

Weather Report

There's something about the weather.  People always seem want to know about it, including me.  So I've been searching, every now and then since like forever, for a simple weather app for the zipit.  The darn thing's got an alarm clock radio and plenty of music apps to help me start my day, and keep it going.  But what if I just want to go outside?  The zipit really oughta help out with that too.

So when I recently discovered The Right Way to Check the Weather with a short and simple command line (like curl wttr.in) I thought I was finally there.  The documentation said there were many options -- including some that seemed ideal for the tiny zipit screen.   But no, sadly, I was not quite there yet.  The zipit is simply not made of modern stuff, and so was not quite up to the task.  Actually that's not completely true.  An ASCII only -- black and white -- weather report is supported.  But who the heck wants that?  The weather is life itself, and black and white just doesn't cut it.

So I set it aside and went about other business, until someone else on the zipit IRC channel made note of wttr.in and got me thinking.  Apparently some ideas had germinated with the passing of time, because I now realized I could make a filter to re-tune the output for the zipit.  Yeah, that might just do it.

The two most obvious problems I'd noticed with the standard colorful weather output were the use of fancy xterm 256 color escape codes, and some utf-8 unicode glyphs that I just didn't have.  The old fbcon terminal only supports the escape codes for an ancient, under-powered 16 color palette.  And the tiny psf console font simply has no room to waste on a dozen subtle variations of the standard single quotation mark.  How many different ways can you tilt that thing?  And honestly, how often am I gonna use that lightning bolt glyph?  So I ran about a zillion weather reports from various airports (and some extra tall mountains) and built up an enormous sed filter to coral the nonsense into a smaller pallette and a reasonable character set.  As you can see, the 16 color spectrum is quite limited, but gets the job done adequately for the temperature and wind speed ranges.
 
Yeah, that "dark yellow" is really more brown than orange, but whatcha gonna do? 

Here's the filter script:

zipweather

After a while I realized the 5x8 zipit font provided just enough text to fit something slightly more advanced -- an actual forecast.

At that font size I can't actually read it, but I can still make out the pictures.

The zipforecast script should be available here shortly...

Update June 12, 2020

And...suddenly I'm reminded on the zipit IRC that the st-sdl terminal can handle xterm color escape sequences, so I had to try it.  I did a quick hack to set the display to the 320x240 zipit screen size and built it on the laptop to see if it was viable.  The larger color table looks pretty good.  I noticed that it also handles the UTF-8 characters, including the lightning bolt, which is a nice bonus.

Note the many subtle shades of orange and greenish yellow.

It was easy enough to build on the zipit.  But once again pthreads gave me segfaults when I tried to run it on a zipit with IZ2S.  Eventually I remembered to search the blog for hints on that.  This time I ended up linking with -pthreads before and after the SDL libs, and I also had to remove an extraneous -lc early in the link args to make it work.

 Once again, the weather here is mostly greenish yellow.

The truetype dejavu font struggles a bit at this size.  And it's taller than the 5x8 psf font, so some of the forecast scrolls off the top.  Also, I still need to add support for the weird zipit keyboard.  Gotta borrow that mess from links, or maybe pspmaps.

Update June 20, 2020

And...it turns out the clunky truetype font looks much, much better with antialiasing enabled, although It's still too tall.  And there are some questionable spacing choices on the 80 and the 86.  Is it a failed attempt at kerning?  Maybe I should add a command line option to select another font.

The trend is now slipping into the orange end of the spectrum.

Meanwhile the zipit keyboard works pretty well with a simple change to ignore the Alt key modifier whenever there's a nonzero unicode value available for a key press event.  All one line fixes so far.  I also borrowed a slightly larger chunk of code from the current X11 version of st to support for the DSR Device Status Report escape sequence required to make qe work properly.  It probably wouldn't be much trouble to import the truecolor escape sequence support from there as well.  But first I'd need to find an interesting shell app to test that with.

At this point I've got my st-sdl patches up on github and need to start thinking about making a release.

But first a quick distraction from the comments...  I took the mydingux SDL myterm program mentioned by user Unknown in the comments below for a spin.  And while it clearly does not support enough escape sequences to do a proper job rendering the weather, it does provide support for a nice shiny background image that I'm gonna probably borrow for st-sdl.

I do like the shiny stuff.

Ok, I realized that a colored background image is only easy if you don't support the escape codes for background colors on the text (myterm does not).  So I decided to release an iz2s st-sdl binary before I dive into that mess.

https://github.com/deeice/st-sdl/releases/tag/v0.3

Sunday, April 12, 2020

Pandemic Coronavirus Lockdown Coding Weekend (formerly known as Easter)

Shortly after yesterblog, I discovered www.radio-browser.info was gearing up to switch over to a new API, cutting off the old incompatible API (and the ziptuner along with it) on August 1, 2020.  Uh Oh!  Better get right on that

So now in my third or fourth week (I've lost track) of coronavirus pandemic lockdown, with the impending deadline starting to loom, I decided to get busy with the API update.  The docs claim to "prefer" https, but after some initial success with http, I started geting 301 errors.  So I suspect the https has evolved from a mere preference into a full blown requirement. Ok, so be it. Cryptonecronom here we go again...

On the zipit, the openwrt build of ziptuner adapted just fine to the the new "secure" https API, but the IZ2S build had issues with the certs.  I have no idea where the ancient IZ2S build of libcurl expects to find them.  I was able to pass a cert location to the command line curl program, but was unsuccessful overriding it in the ziptuner code with curl_easy_setopt().  So I'm currently running the new API build of ziptuner for IZ2S with cert verification disabled.  I don't see how that's any less secure than the original http API, so I'm not gonna sweat it for now.  But I'll keep trying...

In the meantime, I managed to squeeze a bit more utility out of the dialog program, making use of backsplash option to show the selection number of whatever station might be currently playing.  Just in case you scroll further down and forget...


I'd like to play some Groovetube, but wait, maybe I should save station 56 first.

Unfortunately this puts the squeeze on size of the station listing box, slicing off a few more precious lines.  So I limited it to screens of 24 lines or more.  On the zipit that's the iz2slat font, or something even smaller.

I also did a bunch more code cleanup and bug fixing.  The code is still not pretty, but it's inching ever closer.  Good enough for a ziptuner 0.6 release on github to support the new API.  And I've included an updated IZ2S binary with the certs.


Bunny tax.  My daughter suggested this, to brighten things up.


Sunday, March 1, 2020

Saved at Last

This blog really needs some new life, maybe gotta take it in a new direction because the previous post is dated well over a year ago.  Yikes!  I suppose the problem here is that I really haven't done anything for a long while that felt interesting enough to discuss.  And then time passes and leaves me behind.  Youtube moved on, dropping support for the smaller, lower bitrate video streams of the past, as google is known to do.  So nothing suitable for the zipit.  I think that killed some of the spark that motivated my tinkering.  Keeping up with youtube on the zipit had become something of a quest.

At the same time, a 64GB micro-sd suddenly went read-only in the zipit I use exclusively for music in the car -- with only 34GB of the storage actually used up.  I can still play the music on it, but can't add any new stuff.  So much disappointment in such a small package!  I wasn't using that particular zipit for anything else, so I gotta assume maybe rockbox does too many small writes, possibly saving the current song location?  But I really don't know.  So I started over with a new 32GB sd and some new music.  I also went back booting into rockbox from the internal jffs instead of the sd card.  I'm pretty sure the internal nor flash supports many more writes, and the jffs most likely does much better wear leveling than the junk in the sd card.  Perhaps in time I'll regain the confidence to try a bigger sd again... 

Meanwhile I finally retired the old iphone 5 and got a new android phone. And the car supports android auto, so I figured I'd see how well that works.  After using it for a while, I'd say it has potential, but Rockbox is still a better interface for my stash of mp3s than any android app I've tried so far.  Musicolet is ok, but the android auto interface stinks compared to the one on the phone itself.  So much failure is built into car touch screens.  Don't get me started on the software built into entertainment system of the car itself.  A touch screen is a really stupid interface for a car because it forces you to look away from the road, unless maybe you've got a robot behind the wheel.  I don't have one yet, so Musicolet demands I stop touching and speak to it whenever I hit the android auto screen more than once a minute.  Makes sense, but I'm just not quite ready to go there yet.  And anyways, how's all that talking supposed to work when the music is blasting?

Also in the last year, at some point, Notepad++ was driving me nuts on the junky Windows machines I'm forced to use from time to time.  So I took up the defunct Windows port of qemacs and "finished" it.  There, that's much better...


Yes, I confess.  I do still use Windows XP sometimes...


Apparently there's loads of fairly new unreleased goodies in the official qemacs repository.  I need to play with all that and see what I like.  So I made a separate qemacs fork in my github, and updated the Windows fixes to fit.  I'll probably put it on the zipit as well someday and see if all the new code bloat is worth it there.

OK, so by now if you're paying attention you're probably wondering about the title of this post.  Yeah, I know.  If you got this far, you've already forgotten.  It's "Saved at Last".  What's all that about, you say?  Well, one area where the zipit still excels in my mind is for internet radio.  For that the zipit still works best for me.  But there was one key feature missing from the ziptuner.  It gave you the ability to find, sample, and save stations, but you still had to use another app to make use of the saves.  I finally got around to fixing that.  Hence the title.

Originally the ziptuner was supposed to be a quickie hack to fill a gap on the zipit.  At the time, there were several apps to play internet radio, but no easy way to find new stations and save the urls.  Hence the need for the ziptuner.  But the ziptuner grew up as I used it and learned what I really wanted it to do.  Unfortunately the code grew in the same haphazard fashion, new bits grafted on here and there, with no real plan or design.  It's a real pain to debug ncurses apps because they take over the screen you want to use for the debugger.  So bugs crept in and went unfixed.  Eventually I could no longer stand to even look at the code, much less work with it.  So I never added that final critical missing feature. 

Well, eventually it dawned on me that I could use Xdialog on my laptop as a cheap substitute for the ncurses dialog program.



It's missing some of the advanced button options.  But I could work around that, and it frees up the text console for the debugger.  So I was finally able to test and fix things in a comfortable debugging environment.  The ziptuner was saved at last from the code rot!

While smashing bugs I identified some code symmetries, allowing me to break it up into more manageable chunks instead of the deeply nested nonsense that it once was.  And when I could see what I had, I knew what I could do next, and voila!  Option 9 -- List Saved Stations -- was born.

 

Here's a sample Saved Stations list from my zipit.  Gonna play me some Groovetube.  And I'm all hooked up for Saint Patty's day in two weeks.  I'm pretty excited about it.


There's still more to be done.  I eventually added a -a command line option to resume playing a saved station on startup.  But the .pls format support is unfinished.  At least now there's some hope for that...

Monday, December 31, 2018

Reindeer Games

Hey, it's the holidays again, and right now the RS97 crowd is buzzing like a jolly bunch of busy bees on dingoonity, with daily updates on their progress creating fresh new goodies for their cute little game consoles.  Some of the stuff is in the sweet spot for the zipit, so I've raided their github archives and compiled a few new games for IZ2S.  Here's what I've tried so far.

Prince of Persia
Abbaye des Morts
Cave Story

Of the three, I've found Cave Story the most compelling.  Maybe it's the music?  Or maybe because Cave Story seems to work properly whereas Prince segfaults occasionally and Abbaye is too slow.


The third poison plant gets me every time.  But I swear I'll get past it before years end.

The sluggishness in Abbaye is due to the expectation of a 60Hz refresh rate, which ain't never gonna happen on the zipit.  But there's a nice spot in the SDL2 shim code where it adds adds a delay after the buffer flip, whenever the refresh rate exceeds 60Hz.  I can tweak that for the zipit to skip frames instead when it needs to catch up.  Then I've gotta tinker a bit more, perhaps try and remove any gratuitous floating point math and fix up any bad keybindings.  After which I'll zip up some packages.

nxengine-iz2s.zip
abbaye-iz2s.zip
 
I tweaked the keybindings for a better zipit experience on both of these.  There's no Fn keys on the zipit, so just use the Q, W, and E keys for F1, F2, and F3 if you find yourself in the Cave Story options menu.  I also changed jump and fire from Z and X to ctrl and Z to line up better with the other keys on the left edge of the screen.  Here's the basics.

    Movement - ← ↑ ↓ → (down opens doors)
    Jump - Ctrl
    Fire - Z
    Previous weapon - A
    The next weapon is S
    Inventory - Q
    Map - W
    Exit - ESC (the options menu is also accessible via ESC)

For Abbaye you can use ctrl,Z for jump,crawl and comma,period for left,right instead of the dpad if you find the center nub on the dpad gets in your way.
This Abbaye screenshot actually came from github, because I'm feeling lazy...

Update 12/31/2018

Oddly, as the holidays progressed I was overcome with a desire to complete a project long ago given up as somewhat of a failure.  You see, a relative (who wishes to remain anonymous) has a tablet and was spending an inordinate amount of time attempting to develop professional level FreeCell skills before returning to work in the new year.  Witnessing this was a constant grating reminder of my long ago failure to finish while attemping to bring some high quality console card games to the zipit.  I got pretty close, but never really went the distance.  This was mostly due to the limited utf-8 support in IZ2S.  You can do some unicode manually, but library support is simply not there due to the small size options selected when uclibc was built. So libncursesw on IZ2S is just a bloated version of the regular libncurses, with no functioning unicode features.

However I realized that I actually had some new ideas to try.  The iz2slat font provides latin-15 support in addition to a full set of line drawing characters for ncurses.  So life is not so bad.  But the font wastes space with a few duplicate characters, and also has some unicode glyphs that can't be used by ncurses, making them very limited in value.

I's been a while since I fiddled with the font, so to get started I grabbed the psftools (not this psftools although it may also work) required for editing glyphs in ASCII mode.   And to help visualize how the glyphs in progress would look on the zipit, I created a small showpsf program from libpsf.  Here it is displaying the iz2slat.psf font on my laptop.

If you squint you might just see some duplicate glyphs in positions 2,3, and 128.

There's already a diamond in position 4.  I originally had a plan to replace the 3 duplicate glyphs in positions 2,3, and 128 with the glyphs required to show all 4 suit symbols in some console card games instead of the feeble ASCII substitutes.  So I created a variation of the iz2slat font with the changes and assigned the suit glyphs unicode numbers U2660, U2663, U2665, and U2666 in the psf unicode table.  Unfortunately the only way to display them on the zipit console is to avoid ncurses and instead use ANSI escape sequences.  I can do that, but it makes porting existing code difficult.

The new suit glyphs show up just fine on the zipit in the showpsf program.

So I came up some cheesy work around ideas.  At first I thought maybe making a whole new font designed around codepage 437 might work.  But further reading discouraged me from that idea.  As far as I can tell, all the codepage 437 linux solutions are based on utf-8 support.  I need to get significantly cheesier for something that works in IZ2S.  It occurred to me that the difference between the latin-1 and latin-15 charsets involved only a small number of fairly obscure glyphs.  Other than the Euro symbol, the other new characters probably won't be missed all that much.  (I've never used them...)  So I made another variation on the iz2slat font where I substuted the card glyphs in latin-15 zone.   I almost used the accent characters, but instead went with some actual letters that might just work as recognizable suit identifiers if I accidentally forgot to switch from the normal iz2slat font.

Here you can see the new location of the suit glyphs.

To tie things all together I dug up csol (a new console solitaire suite on github), created a new pint-sized zipit theme for it, and tweaked the code ever so slightly to eliminate the dependence on utf-8 for the zipit theme.

And here they are making csol look pretty.

The following picture represents a victory lap from my one and only game of freecell on the zipit.  I feel pretty good about it, but I don't think I have what it takes to go pro...

 I got a really bad case of video game thumb rescuing that 4 of diamonds from the bottom of the stack.


Here's the goodies (once I zip things up):

iz2splay.psf
csol-iz2s-with-font.zip
showpsf-iz2s.zip



Wednesday, December 19, 2018

Cryptonecronom

Anyone remember way back when the internet was simple?  You could telnet to directly to certain TCP/IP ports and type your email or web requests in pure and natural ASCII text, and it would work.  Well those days are gone, replaced by an endless rotation of crypto protocols that seem to rapidly degenerate into obsolescence or expiration.  Or maybe time moves faster as you age?  I don't know.  Anyhow, I expect this post be be all about the dead crypto eating away at my aging computers (and zipits) and my attempts to get things working once again.  The well known technical term for this rot is crypto necro nom-nom-nomicus in meme-latin.

We'll have to see where this eventually takes us. For now I'll start it off by re-posting a recent update to an old blog entry about the QEMU compiler setup for IZ2S, because dead crypto is what instigated my renewed efforts there.

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

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

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

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

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

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

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


Meanwhile, almost as soon as I made the new dropbear, I realized that i needed more.  At the time I was using putty on Windows PC and for some reason putty requires an sftp-server on the linux side to transfer files, even if you use pscp.  Dropbear lets you know that's not gonna work by mentioning it can't find /usr/libexec/sftp-server and then disconnecting.  Fortunately bleeding edge openwrt has an sftp-server package that works just fine for this.  So I dug up the bleeding edge recipe that builds a minimal sftp-server executable from openssh and compiled it for IZ2S.  To activate it you should install the sftp-server executable in the libexec directory on the root of the IZ2S sd card, and then edit z2start.sh to make a softlink from /mnt/sd0/libexec to /usr/libexec, similar to the one for /usr/lib.

Unfortunately when I tried to install the sftp-server package on my bleeding edge openwrt zipit, I ran into trouble with opkg.  It no longer worked.  Some investigation revealed that opkg was using wget to fetch the packages from mozzwald.com via http.  Running the wget command by hand showed the http command got redirected to an https link which failed with an error about libustream-openssl gone missing.  Turns out wget on openwrt is actually a softlink to uclient-fetch, and I needed to install the libustream-openssl package if I wanted it to do https.  So I fetched the package manually from mozzwald.com on my laptop, then transferred it to the zipit and installed it from there.  At that point I could run opkg update and see that it now functioned properly.  So I used opkg install to fetch and install the sftp-server and ca-certificates packages.  Crypto death rot was put off for just a little while longer.

The rot isn't specific to the zipits.  My eeepc 900A netbook has also got it bad.  It's currently running an old puppy linux flavor (puppeee) specially tailored for the hardware.  But it's about a decade old now and the crypto stuff is so outdated that nothing on the internet will even try to talk to the web browser.  Git can't fetch code from github.   Ssh is crippled.  Everything that made this machine fun is now busted and I'd really like to bring it back from the dead.  So the search is on for a more recent netbook sized linux that could meet my needs.

Goodby puppeee, you served me well back in the day.

Update Jan 5, 2019

I wound up taking the path of least resistance and installed a newer version of puppy linux -- specifically the Ubuntu based 32-bit XenialPup 7.5.  It went onto a usb stick with relative ease via this command.

  sudo dd bs=4M if=xenialpup-7.5-uefi.iso of=/dev/sdb conv=fdatasync

Booting it was a bit more challenging.  The eeepc boot screen mentions F2 for setup and Tab to see messages, but it's the Esc key that actually gets you to the runtime boot media selector.  I only just stumbled onto the Esc key functionality with a happy accident when I tried Tab and got bored watching the memory test count up.


The XenialPup looks pretty darn similar to puppeee, and I like that.

I booted xenial from the usb stick a few times to try it out and quickly decided it was familiar enough with ssh, picocom, and git all pre-installed, just like on puppeee.  The only obvious issue was the wifi drivers.  Running lspci -v showed the kernel detected the atheros wifi, but no modules were loaded.  Someone left out the atheros drivers from the xenial iso image.  Oops.  But this was already known and an atheros_kernel_modules-4.4.95noPAE-xenial32.pet package was already created to patch the hole.  So I borrowed the ethernet cable from the TV and fetched the package.  I also tried the Pale Moon browser and found it sluggish, but it gets me onto github so I'm satisfied there.

Unfortunately double clicking on the atheros .pet package stubbornly refused to install anything, darn it!  However I untarred it manually and had no problems copying the additional driver directories into the lib directory tree.  Then I ran depmod -a and insmod ath5k and voila the "Connect" gui could now see the wifi.

This was good enough for me so I manually copied the files from the xenial USB stick to the eeepc flash drive for a homemade frugal install.  I also added the devx_xenialpup_7.5.sfs developer tools squashfs for gcc.  Then I edited my existing grub menu.lst file to remove some obsolete browserlinux and pup431 options and added xenial instead, keeping puppeee as the default in the menu for now.  At this point I ditched the USB stick, and booted into xenial from grub.  It takes longer than puppeee, but what can you do, it's got some ubuntu stuff in there.  The next step was to get me some emacs.  So I ran the pet installer, did an ubuntu package update, and installed the ubuntu emacs package.  I'm not sure I'm gonna keep that since it hogs a whopping 80MB whereas an emacs sfs is only about 40MB.  I'm not sure if I can use the emacs-24.5-i486.sfs from the puppy forums because it's not specifically for xenial.  So perhaps it's time to howto roll my own sfs.

So far the noticeable differences boil down to a larger font in the urxvt terminal -- I probably need that at my age -- and I don't know if I can set the titles in the urxvt tabs.  They don't respond to the old xterm ANSI control sequences, but hopefully I can figure something out.  Anyhow, life is good once again with the eeepc netbook.


Update Jan 12, 2019

After using it for a while I noticed another issue.  Closing the lid on the eeepc is not detected, so the screen stays lit and the netbook continues to run hot and heavy.   I suspect xenial runs a bit hotter than puppeee since I sorta remember tinkering with some special eeepc settings available in puppeee, so this is a bit of an annoyance.  I've currently "solved" the problem by creating a small script to echo "freeze" into /sys/power/state and then placing a convenient icon for it on the desktop.  That works ok, but it got me thinking maybe I should keep looking for alternatives.  So I'm gonna try AtomicPupXIX when I get a chance.  It's supposed to be a slackware based puppy linux tailored to atom processors in the early eeepc lineup, so it could be a good fit.

Update Jan 21, 2019

I also did some work on the tiny zipit bleeding edge openwrt starter filesystem that gets installed by the latest flashstock.  I updated the certs and installed libustream-openssl to fix up links and wget, and a tossed in few other goodies while I was at it.  And very quickly ran out of space. 

No room for emacs.

Now the filesystem for this is comprised of a read-only squashfs and a 1MB overlay jffs.  All the new stuff goes onto the jffs and that's where we ran outta room.  But I sorta remembered checking the squashfs a while ago and discovered that it didn't quite fill up the entire mtdblock3 partition.   So I dumped it to a file with dd and copied it over to my laptop where I used unsquashfs to examine the contents.  Sure enough there was about 400K unaccounted for.  So I figured I could squeeze (squash?) mpg123 and the libustream-openssl package in there.  The certificates are likely to change in the future so they'll have to stay with the jffs.  I had to simplify to a plain blue background, lose the zz-zipit sound file, and change a few duplicate files into softlinks, but eventually it all fit.

Plenty of room for emacs.

Hopefully I can fit the certs and both ziptuner and emacs onto the now roomier jffs partition.

Here's the fully packed ultra-bleeding-squashfs.sfs file.  I managed to fit everything else I wanted onto the jffs with over 700k to spare.   If you boot your zipit from an SD card and your kernel is configured with the right mtd partition sizes you can use dd to upgrade the squashfs installed by flashstock.

root@zipitz2:/tmp#  cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00040000 00010000 "uboot"
mtd1: 00010000 00010000 "ubootenv"
mtd2: 00190000 00010000 "kernel"
mtd3: 004d0000 00010000 "squashfs"
mtd4: 00150000 00010000 "jffs2"


root@zipitz2:/tmp# dd if=ultra-bleeding-squashfs.sfs of=/dev/mtdblock3
9856+0 records in
9856+0 records out


And don't forget to upgrade /dev/mtdblock2 with the latest openwrt kernel while you're at it.

One more tip.  If you're like me and get really annoyed by bright or blinking LEDs, especially at night, you might want to edit /etc/init.d/z2leds.  Set all three LED triggers to "none" to wrest control away from the kernel and give it to you.  Also comment out or delete the bit where it checks the battery and turns on the "charged" LED. 


root@zipitz2:~# cat /etc/init.d/z2leds
#!/bin/sh /etc/rc.common
#
# Setup Zipit Z2 LED's
#

START=11

start() {
    echo "Setting up Zipit LED's (gimme full control)"
    echo "none" > /sys/class/leds/z2\:green\:wifi/trigger
    echo "none" > /sys/class/leds/z2\:green\:charged/trigger
    echo "none" > /sys/class/leds/z2\:amber\:charging/trigger
#    STAT=`cat /sys/class/power_supply/Z2/status)`
#    if [ "$STAT" == "Full" ]; then
#        echo "255" > /sys/class/leds/z2\:green\:charged/brightness
#    fi
}


That didn't completely cure the epic seizures the kernel was having over the "charged" LED on my zipit, so mozzwald made this new seizure free kernel.

Update Feb 3, 2019

In order to stay out of trouble, the seizure free kernel avoids reading the flaky charge controller status, and so it can't provide a charge full status to gmenu2x.  This is a minor annoyance so I thought maybe some small updates to ebindkeys and or gmenu2x could work around it.  But the squashfs partition is completely full, right down to the last 4K block.   So I've had second thoughts about including the 150K dialog package in there, just to support the sleep timer applet.  Especially so, since I had to substitute a slightly smaller non-wide character version of dialog -- It makes a mess of ziptuner on the international internet radio channels.

With this in mind I finally did something useful with my piles of ANSI escape sequence junk code, and made a 6K standalone menu script as a fallback if the sleeptimer applet finds no dialog package installed.  Here's what it looks like.



The current code avoids using stty since it's not available in the squashfs, and at 50K I'm not planning to put it there.  Eventually I'll redo the squashfs again without dialog, but with more updates and other goodies instead.  Perhaps picocom and tinyirc.

...And I ended up replacing the dialog package with qemacs and tinyirc, in addition to the sleepmenu since that was an exact fit sizewise in the squashfs partition.

ultra-bleeding-squashfs-2.0.sfs



Tuesday, October 16, 2018

Where do we go from here?

This blog seems to be running out of steam, or maybe it's just me.  Anyhow, I guess it's time for an update of some sort.  So I'll have to cobble something together to fluff up the word count...

Some ideas to write about include:

Compiling code for the zipit on my chromebook.  That was fun.
Tinkering with voidz linux on the zipit.  Also sorta fun.

My original plan for the chromebook was to use the compiler from chromebrew to make a smallish static dietlibc build of the current movgrab source code to work around a problem with the musl builds.  The chromebook has an arm processor, so many static zipit executables actually run on it, allowing me to test things without having to transfer to the zipit.  More on that here:

https://mozzwald.com/irclog/zipit/2018/05/28

My hopes for dietlibc were many.  It builds smaller static executables than other libc implementations.  It might not have the socket reuse issue I was getting with musl.  And it had a recipe for building a static openssl, something that had eluded me last go around when I made the static uclibc build of movgrab.

I got dietlibc working, and made a static qemacs with it, but the movgrab build never came to fruition.  I suspect it really only works with glibc, and glibc now actively resists static builds.  So I gave up.  But then the voidz linux distro got created for the zaurus and and seemed like it could be a really nice fit on the zipit, with musl and no systemd.  I didn't have a compiler for it, but wanted to give it a test drive.  So I went back to the chromebook and built a set of static executables to let me run the ziptuner.  This tarball has ziptuner, dialog, mpg123, with some config files and scripts.

ziptuner_static_with_dialog_and_mpg123.tgz 

The executables are all static builds that I compiled and tested a bit on the chromebook.  The ncurses setup on the chromebook has issues with terminfo and I remember mpg123 was a bit of a challenge, but I eventually managed to coax some sound out of it. Unzip it into /usr/local on voidz and run ziptune to give it a try.  It might also work on other zipit distros due to the static executables.  For all the trouble it gave me in the build, the mpg123 executable actually runs pretty well on the chromebook.

Here's a shot of the ziptuner compiled and running on voidz.

I'm hoping to try and learn how to turn ziptuner into an actual xpbs package for voidz.  We'll see how it goes.