The YOPY Report, 1 June 2001

It's been two weeks since I got the YOPY.

In the process of playing with the YOPY, I quickly determined that it
was somewhat bulky, but that the hardware was otherwise quite nice.
The software that it ships with is essentially unusuable as a real
PDA.  (That's why they're selling it as a "development kit".)  For
instance, the calendar application does not ever actually sound the
alarm; that part of the code is unfinished.  I was impressed with
certain aspects of the default applications, such as the
year-at-a-glance screen of the calendar, which would be impossible on
other PDAs with lower resolution screens.

So, this is clearly an experimental, development device.  I decided to
evaluate it as such.  This work is done in my spare time, so it's not
progressing particularly swiftly.

My first task was to get a cross-developement platform ready.  There
was a complete cross-developement toolchain for Linux on the YDK CD,
but I didn't like the way that it installed, and I have a fetish for
only using software that I compiled myself when at all possible.
Building the software myself means that I have the ability to upgrade
to the latest version of the software without waiting for the vendor
to provide a packaged release.  

Unfortunately, building a cross-compiling toolchain is not always a
simple task.  I already had version GCC 2.95.2 on my workstation, but
the patches for 2.95.2 to support the YOPY's processor did not run
cleanly.  On the assumption that these fixes would have been
incorporated into the main-line development for the compiler, I tried
a pre-release version of GCC 3.0.  This was a mistake; the reason they
call it a pre-release is that it's still flaky.  Version 2.95.3 of the
toolchain built clean as a cross-compiler.  I applied only one patch
that improved the optimization for ARM processors, and used a fairly
well-documented hack to get it to build without the C standard
libraries.

Building GCC and glibc (the gnu version of the C standard library) is
a bit of a chicken-and-egg problem, because GCC is needed to build
glibc for the target platform, and GCC also wants to know where the
target glibc is when it's building itself.  So a minor hack (called
the -Dinhibit_libc) is required.  Once I was working with 2.95.3, this
worked fine.

After arm-linux-gcc (and the rest of the toolchain) was installed, I
built glibc 2.1.3.  There is a 2.2.x version of glibc, but since I
haven't tried it on my workstation yet, and the YOPY also shipped with
2.1.3, I decided to stick with 2.1.3.  I'm not aware of any crippling
deficiencies in 2.1.3 that would merit pushing this envelope.

The shell environment was quite usable through the serial port, but I
was almost immediately irritated by a bug in 'ln' that prevented me
from being able to make symbolic links.  On this platform, 'ln' is
actually 'busybox', a program that emulates a wide variety of standard
unix commands in a single program, carefully tailored to minimize size
for embedded systems.  The first program I built (aside from
"hello_world.c") was to compile busybox release 0.51.  This version is
noteworthy in that it includes an implementation of 'vi' that uses
only an additional 22k on the disk (or flash, in this case).

I was also disappointed at the lack of a command prompt usable on the
device itself.  I compiled w-term, a terminal window program for
W-windows, the graphics system that ships with the device.  W-term
worked okay; it's kinda cool to have a usable unix workstation in my
pocket.  Minor nits hadn't been worked out, such as the backspace key
not working properly, and I couldn't locate the source code for the
tiny screen-keyboard to fix it.

According to the manufacturer website, W-windows is now deprecated in
favor of a stripped-down version of X-windows, and a test version of
that software was available for download.  I installed it; it works
well.  It also came with versions of the GTK and Gnome libraries, so
lots of software should run on the device.  It didn't include a
handwriting recognizer, but the backspace key of the screen-keyboard
worked properly.  I built 'rxvt' (the smallest X-based terminal window
program I could find), and I was happy again.

One problem with the YOPY is that it uses 'ext2' (the standard linux
filesystem) on the flash storage, with a device driver that emulates a
disk interface.  Any given block on flash storage has a limited number
of write-erase cycles before it burns itself out.  Because of this,
the storage algorithms appropriate for disk drives aren't appropriate
for flash-based storage.  A filesystem for flash-devices should do
"wear-leveling", it should write evenly to the entire flash device, to
prolong the total useful life, and should be maximally tolerant when
the device starts to fail.  Such a filesystem exists for Linux, called
the "Journaling Flash Filesystem 2" or JFFS2.  I decided to switch to
JFFS2 on the YOPY.

This turned out to be moderately difficult.  JFFS2 is quite new, and
not well supported.  It is in active development, sponsored by Red
Hat.  I needed to upgrade the kernel on the device from 2.2.14-yopy1,
to something in the 2.4.x series.  I first tried to use the 2.4.5
kernel, on the theory that it was the newest, and would have the most
changes/fixes/improvments integrated.  Some of the work to support the
ARM processor has made it into the actual core linux version, but a
lot of work is done for that architecture as a series of patches by
Russell M. King (to support the ARM) and Nicholas Pitre to support the
SA1100 (the specific version of the ARM in the YOPY).  On top of this,
the G-MATE developers have their own patches for the YOPY itself.
After fighting for a while with 2.4.5-rmk3-np2 and the various patches
available, I eventually gave up and used 2.4.2-yopy1, which was
available from yopydeveloper.org, and already included a consistent
set of patches.  Of course, this doesn't include the
latest-and-greatest changes, but I was spending too much time trying
to figure out where the bleeding edge was, and trying to unify the
fronts, so I punted.

I did build 2.4.2-rmk2-np2, so that I could run a diff between that
and 2.4.2-yopy1 and isolate the changes made for YOPY support.  (I was
irritated that G-MATE didn't provide this themselves.)  But before I
could re-apply those changes to a newer kernel, I got distracted and
started working on actually getting JFFS2 to run.

After minor wrangling, I got a home-built 2.4 kernel running on the
device, and after a bit more hair-pulling and gnashing of teeth, I
managed to get it to boot with JFFS2 as the root filesystem.
Unfortunately, I couldn't figure out how to change the partitions on
the flash device, so I had to make the filesystem artificially small.
I've just recieved an email that indicates that the flash device
partitions for the YOPY are hard-coded into the -yopy1 kernel patch.
I'm not sure whether I should be pleased to know this or disgusted by
what seems like a crappy design decision.  I guess it's a
developmental device, after all.  I hope to have this solved tonight.

Once I have JFFS2 working, I intend to figure out how to make the
device wake-from-sleep, which I believe is critical to production use
as a PDA.  Other projects on my TODO horizon include IR support, a
survey of suitable application suites, and USB synchronization
support.  Irritatingly, they didn't include the proper cable for USB
with the development kit, but it's possible to splice a USB cable into
the serial cable.

The work continues.