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

Re: apex-1.4.5

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.

> > All I want is for us to come to an end with changing this stuff.
> Fully agree - it would be much easier to sort this out on IRC, for instance, but timezones and real life have gotten in the way.

We hadn't talked about that.  I'd be fine with a rendevous on IRC.
I'm in PDT (-7).  I can chat Sunday evening and, maybe, tonight

> 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.

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

Reply to: