Re: APEX and Debian
The existing utilities that access the FIS directory from userspace for upgrade and configuration save and restore purposes currently rely (for the nslu2) on the existence of "kernel", "SysConf" and "Flashdisk" flash partitions, but the utilities have been written to enable those names to be easily changed (in fact, there are actually other names that are used for the other devices). As long as there is an FIS directory and /proc/mtd access to a set of named partitions then we will deal with any necessary name changes and the change from jffs2 rootfs to initramfs (which could still be used with a jffs2 rootfs anyway).
I fully agree that network access in APEX using the newly written drivers is a top priority. USB mass storage support for loading the kernel and initramfs directly from disk is still a very desirable feature down the track ...
-- Rod
-----Original Message-----
From: "Marc Singer" <elf@carmine.cac.washington.edu>
> It's only the NSLU2 SerComm-hacked RedBoot which loads the kernel and ramdisk from specific hard-coded locations in flash into specific hard-coded locations in RAM - most RedBoot implementations (including other devices like the IOMega NAS100D that the nslu2-linux project
supports) use the FIS directory to find the various flash partitions
by name.
Good to know. How will these be affected if we start munging the FIS directory? What i there is no ramdisk partition?
Reply to: