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

Re: apex-1.4.5

Marc Singer wrote:
> On Sat, Aug 19, 2006 at 01:40:00PM +0930, Rod Whitby wrote:
>> A kernel that is less than 1MB still has a valid SerComm header (and
> needs to do so for RedBoot-only slugs).  I don't want different
> partition formats depending on which first- or second-stage bootloader
> you happen to have in flash this week, or what size your kernel is
> this week.  I want a single format, which works for all bootloaders if
> the kernel is less than 1MB, and still has the same partition formats,
> but requires a smart second-stage bootloader if the kernel is larger
> than 1MB.  The format stays the same, the prerequisites for being able
> to load the kernel (needing apex) change.
> That is only sort-of true.  Once we put APEX into the mix, RedBoot can
> no longer load a kernel, even if it is less than 768K.  My point is
> that once we put APEX into flash, there is no way that RedBoot, on
> it's own, can load the system.  Maintaining compatibility with SERCOMM
> has no benefit except that it lets the tools have only one form they
> understand.  IMHO, this isn't very compelling.  I prefer to remove
> cruft when it has no purpose.

The tools is the big thing from my point of view, cause you're handling
all the bootloader stuff ;-)

The idea I have is that the Linux userland tools which deal with
upgrading kernel and ramdisk for NSLU2 can use the following simple
rules, irrespective of whether APEX is in the mix or not (although, of
course, for kernels larger than 1MB APEX or another bootloader *has* to
be in the mix):

1/ Find the mtd partition corresponding to "Kernel".
2/ Grab the full contents of that partition.
3/ Strip of the SerComm header (it's guaranteed to always be there,
irrespective of bootloader).
4/ If it's larger than 1MB, then strip out the SerComm header at the 1MB
mark (it's guaranteed to always be there, irrespective of bootloader).
5/ Steps 1 to 3 apply for the "Ramdisk" partition too.

Hmm - that makes me wonder how a Linux userland tool will update skip
regions in the FIS dir - I'm not sure that the FIS dir area is writeable
from userland ...

>> We will put a skip at the start of the ramdisk partition, to match
> the included SerComm header at the start of the RamDisk partition, no
> matter where the RamDisk partition appears in the flash (either at the
> stock location, or somewhere after that if you have a kernel larger
> than 1MB).  Just to be clear, we will *not* put a header or skip stuff
> on subsequent jff2 or other format partitions which optionally appear
> after the RamDisk partition (as in OpenSlug).  Those subsequent
> partitions do not have SerComm headers today, and e should leave that
> as it is.
> So, to be clear, I'm fine with whatever works for you.  I'll make a
> note about the data_length (at the very least) and I'll interpret it
> in a follow-up release of APEX so that we only copy (data_length -
> skips) from flash to SDRAM.
> Probably, we have sufficient agreement to move one.

I think we do, but I'll try and get to IRC when you're there in case
there is anything else we need to clarify.  Hopefully Martin can be
there too.

> P.S. You are allowed to wrap your lines.

Apologies for that.  Sometimes I need to reply using a Treo650, which
has very limited email editing capabilities.  It was hard enough just
getting it to not top-post :-)

-- Rod

Reply to: