apex-1.4.0 and debian-nslu2-arm

[Marc Singer <elf@buici.com>]

I've released a new version of APEX.  This one properly loads the
kernel and ramdisk from NOR flash and passes control to the kernel.
In combination with the debian package, it will function as a second
stage boot loader.

The .deb puts the loader in boot/apex.flash.  The file needs to be
swizzled before being written to flash.  While I could add that, I'm
not sure that that would be the best way to handle it.  On the one
hand, the nslu2 loader will always need to be swizzled.  On the other
hand, the swizzling can be done easily as the flash image is being
prepared.

The APEX environment resides at nor:0x7fc000+15k, near the end of the
FIS partition table block.  There is a README that explains the format
used to write to the environment in NV storage.  If all you are doing
is writing new variables (not appending to an existing environment), I
think we can write a simple script to automate composing the data.
Heck, devio is probably all we need.

I've verified that it boots the debian installer image and I've
separately verified that RedBoot will execute APEX when it is written
to the start of the partition where the kernel is currently stored.  I
haven't written a new flash image with the kernel and ramdisk moved
and APEX in place.

The loader presently copies the partition labeled 'kernel' to the
place in SDRAM where the kernel goes, and the partition labeled
'ramdisk' to the place in SDRAM where the ramdisk goes.  These names
can be changed either in the source, or by writing a startup variable
to the environment.  It also assumes that these partitions have
SERCOMM headers on them.  I believe we don't need to include these
headers if we don't want to as there shouldn't be a backward
compatibility issue.

Cheers.