[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: APEX, NSLU2, skip stuff

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.

> I'd rather not deal with that, but I could if we determine that it is
> important.  Doing so will mean that this work with the skip headers is
> void.  The SERCOMM header at the start of the kernel will be incorrect
> because it refers to the size of the first chunk of the kernel.  The
> time to copy isn't significant.

The SerComm header at the start of the first chunk should only refer to
the size of the first chunk.  The SerComm header at the start of the
second chunk should only refer to the size of the second chunk.  These
SerComm headers should only be read by the Linksys/SerComm hacked up

> Also, I don't know if the SERCOMM header is a standard part of the FIS
> spec, or if it was added by SERCOMM.  (Something which can be
> determined.)  If it is 'required' then we could add another layer of
> headers to make it work.  In other words, we would headerize the
> kernel, split it into two pieces, each with headers and store them in
> flash.  Then. we'd add a second skip to the kernel partition that
> skips the kernel1 SERCOMM header.  A little messy, but technically
> correct.

It was added by SerComm, and we should leave it to them (i.e. we should
put it in there for Linksys/SerComm RedBoot compatibility, but APEX
should ignore it).

-- Rod

Reply to: