Re: APEX, NSLU2, skip stuff

[Marc Singer <elf@buici.com>]

On Mon, Aug 14, 2006 at 09:31:48AM +0930, Rod Whitby wrote:
> Marc Singer wrote:
> > On Mon, Aug 14, 2006 at 09:02:33AM +0930, Rod Whitby wrote:
> >> Marc Singer wrote:
> >>> On Mon, Aug 14, 2006 at 12:25:43AM +0200, Martin Michlmayr wrote:
> >>>> * Marc Singer <elf@buici.com> [2006-08-13 12:44]:
> >>>>> All good.  I flashed the image the way I flash any upgrade.  Since
> >>>>> it booted, I believe it's all good.
> >>>> So, I can confirm that it also works for me.  I've booted both into
> >>>> debian-installer and into a Debian system, and I also tested a kernel
> >>>> which is bigger than 1 MB. :-)
> >>>>
> >>>> I noticed that APEX loads everything from a FIS partition into memory.
> >>>> Maybe it would be possible to honour the size entry from the Sercom
> >>>> header, but I don't think this is terribly important.
> >> APEX should honour the data size entry in the FIS directory, which
> >> should be correctly written by slugimage.  The SerComm header is only
> >> there for compatibility with the Linksys/SerComm hacked up RedBoot.
> > 
> > That's what I do, the FIS data and skip the SERCOMM headers.  I
> > suggested that we abolish the SERCOMM header on the initrd, but Martin
> > doesn't like that idea.  Considering that nothing can load our
> > modified firmware except for APEX, there doesn't seem to be much
> > reason to keep the SERCOMM header on the initrd.  It does mean that
> > slugimage would need a little more work.  Does't matter to me either
> > way.
> 
> It was my request that the FIS partition which starts at the Linksys
> RamDisk location contains a valid SerComm header (just like the first
> kernel partition).  As for subsequent partitions, I see no reason to put
> a SerComm header on them.

That's what I thought.  Perhaps you can convince Martin.  ;-)

> So an APEX-managed flash image has the same number of SerComm headers in
> the same locations as a standard Linksys flash image.  That's all I'm
> asking for.  I'd prefer that there were no other SerComm headers added
> to any other partitions.

I, too, would prefer that.  In fact, if we were to do that, we could
should the kernel partition to skip the initial sercomm header as well
as the one in the middle (which we are already skipping).  This would
then present the same view of the kernel we do for the initrd.


  apex> copy fis://kernel $bootaddr
  apex> copy fis://ramdisk $ramdiskaddr

Now that's clear.