Re: apex-1.4.5
> And, if we return to this, I think we should add a skip (@0+16) to the ramdisk partition so that APEX still has a plain view of the data.
Agreed. That was in the comments that I made on the slugimage patch from Martin. Every SerComm header must have a corresponding skip descriptor.
> Which forces us to ask the question: what does the data length mean when there are skips?
The data_length field is defined by the non-hacked RedBoot, and is the full length of the data in the partition. For any partition which includes a header, this will include the size of the header. For any partition which includes skip areas, this will include the size of those areas. You should be able to add the start_address and the data-size in the flash area, and be able to overwrite with impunity from that address onward to the next partition in flash (ordered by address) without affecting any real, header, or skipped data.
> Perhaps we should make two ramdisk partitions. One with no skip and a data_length equal to the ramdisk as well as the 16 byte SERCOMM
header; one with a skip @0+16 and a data_length describing only the
ramdisk data.
No, data-length should be independent of any skip regions. Anything that understands skip regions needs to subtract them from data-length as it processes the partition.
> This way, we can reasonably make the
data_length reflect the true count of valid bytes in the partition.
As far as data-length is concerned, header and skipped bytes are just as valid as the bytes that are left after skip processing. Remember that not all tools which operate on the mtd partition will (or will need to) know about skip regions. We didn't define data-length - it's in the kernel source already in the mtd driver header files, and my understanding is that it corresponds to the full area of bytes written (no matter what those bytes are used for) as opposed to the full area which is erased (which is determined by the erase block size).
> it doesn't really matter to me one way or another except that
I'd really like to present a clean view of the ramdisk to APEX just as we've done for the kernel.
Due to the skip regions covering the headers in the kernel and ramdisk partitions, we get the clean apex view that we all desire.
> That isn't true anymore. The kernel no longer has a SERCOMM header. At least, not a valid one.
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.
> 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.
> Pusing out a new release of APEX for each little change is a bit of a hassle. Unless there are objections, I would urge that we either put a skip at the start of the ramdisk partition, or we make two
partitions where one has the skip and one doesn't.
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.
-- Rod
Reply to: