Re: APEX and Debian
Marc, I really like your latest proposal for how APEX will use FIS partition names in its boot command environment. If the APEX environment can co-exist in the last block with the FIS directory (which has a fixed maximum size) and the SerComm Trailer (which is also a fixed size) then this is a perfect second-stage bootloader solution from the nslu2-linux project's point of view.
Some other random notes, rather than quoted replies ...
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.
I would prefer that we put the APEX environment in the last block instead of in sysconf, for the reason that existing upgrade utilities (including the Linksys web upgrade functionality on a virgin device) do not modify sysconf but do overwrite the last block. We have been using sysconf as the sole area (apart from RedBoot itself) that users can assume is not modified by a reflash of new firmware.
Just to be very clear about whether the last block of flash space can be recovered or not - the nslu2-linux project stance is that 99.99% of users are not in a position to safely replace the RedBoot first-stage bootloader without us entering the realm of potentially causing more warranty returns to Linksys (which is a place where we simply will not go, please do not try and convince us otherwise). So we must and will always support the case where the existing (albeit very broken) RedBoot remains unchanged as the first-stage boot loader. This means that the last block will remain required for at least the SerComm Trailer (or else RedBoot will not boot). Also, all our existing custom firmware (over 35K downloads) relies on there being a correct FIS directory in the last block to enable named access (for upgrade and configuration save and restore purposes) to kernel, sysconf, and jffs2 rootfs partitions from Linux through the /dev/mtd driver. So we must keep the last block for the FIS directory too. There is over 100KiB unused in that last block - let's just work out how best to use that space (e.g. for the APEX environment or NPE microcode or something else).
Marc, is it possible to access the APEX command line over the network at boot (assuming some means of setting up network parameters)? It would be great to have a fully-featured second-stage bootloader that people can actually interact with without having to solder on a serial port ...
-- Rod Whitby
-- NSLU2-Linux Project Lead
Reply to: