Re: APEX and Debian
On Thu, Jul 20, 2006 at 05:51:00AM +0930, Rod Whitby wrote:
> 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.
NP.
> 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.
Good to know. How will these be affected if we start munging the FIS
directory? What i there is no ramdisk partition?
> 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.
NP.
> 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).
NP. We could put he NPE firmware in a partition named in the FIS
directory. All of the FIS records refer to flash block aligned
images, but I doubt that that is required.
> 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 ...
Yeah. This has been a long standing issue. The IAL just isn't
feasible for interfacing APEX to the NPE. I spent a couple of days
just getting it to compile and link. The result was a 200KiB library.
Blech. Christian Hohnstaedt's work has the potential of enabling
network access in APEX for IXP targets. We've also discussed a USB
driver for a USB console. I think that adding an ethernet driver is
more likely to be useful than the USB console. What this means is
that I want to add the NPE driver. It will have to wait until we get
these other issues hammered out.
My goal is to make APEX a reasonable replacement for Redboot. Once we
have an ethernet driver, we can work out the upgrade details such that
there is nothing that Redboot does that APEX cannot do as well or do
better.
Reply to: