Re: apex-1.3.31 and sercomm flash header
On Sun, Aug 06, 2006 at 08:28:19AM +0930, Rod Whitby wrote:
> Marc Singer wrote:
> > We *can* fake out Redboot by splitting the data we load across the 16
> > bytes where it expects the SERCOMM header. Redboot will still see
> > what it wants to see at FLASH_RAMDISK_OFFSET, but we insert this data
> > at the appropriate point in the firmware image. When APEX copies this
> > data to RAM, it elides the 16 byte of SERCOMM data and voila! we can
> > load any kernel and ramdisk that we want.
>
> Excellent idea. Frans on nslu2-developers concurrently had a similar idea.
:-)
>
> > The only downside is that this isn't likely to work with JFFS2 images
> > stored in flash unless we can get JFFS2 to skip a 'bad' block or
> > something like that.
>
> We've never put jffs2 stuff in before the ramdisk area before, so this
> shouldn't be a problem.
Ah. That hadn't occurred to me, but it makes sense. The only reason
to run over the start of the original ramdisk area is to make the
kernel larger. I suppose you could make the kernel smaller to get a
larger ramdisk, but that's an unlikely scenario.
> > While this is quite hacky and not the sort of thing I like to do, it
> > may be a good way to take back more of the system flash for something
> > useful. If we do it, I recommend that we come up with modifications
> > to the partition table that identify what we are doing to APEX so that
> > we don't have to hard-code what is going on. We should be able to use
> > some of the FIS fields that we don't presently define to cover the
> > load addresses for the partition data. We may need to add an extra
> > field to indicate that a certain number of bytes in a partition are to
> > be skipped.
>
> Apex currently has support for a kernel and ramdisk. Perhaps apex can
> be generalised to load N partitions on boot (each with start location in
> flash, length, and start location in ram, all recorded in the FIS
> directory in the fields already defined for that information by
> RedBoot), and then apex just loads those N partitions (some of which may
> just happen to end up merging at the destination by being placed
> directly next to each other) and jumps to the start address. We can put
> a sensible limit on N (i.e. 4).
Apex has no concept of kernel or ramdisk. You can copy as many things
as you like anywhere you like. It *does* have the idea of the start
addresses of the kernel and the ramdisk because these are passed to
the kernel in ATAGS.
> This has the benefit that for devices with RedBoots that have the fis
> load command implemented (e.g. the NAS100d), the behaviour of apex
> loading a partition will match the behaviour of redboot loading a partition:
>
> fis load ramdisk
> fis load kernel2
> fis load kernel1
> go
>
> (RedBoot remembers the entry address for the most recently loaded
> partition).
>
> Marc, Martin, I think this is a winner.
I'll tell you what I think we should do, then. I'll look at the FIS
format to make sure it makes sense. Let's add (at least) a descriptor
to the FIS record which is a pair (offset length). This will
communicate a span of bytes to omit in the partition. This has the
benefit of allowing a seamless integration of this 'skip' feature. In
APEX, the FIS driver will notice the skip information and bypass those
bytes without fuss. The UI will be the same to the user of APEX. All
we have to do is add the record to the FIS partition where the skip
occurs and then we have to insert those bytes into the partition data
when we write it.
If you like this idea, I can implement the feature in APEX without
much hassle. All we'd need is agreement on the format and a patch to
slugimage to cope with the new feature.
...
Here's what I suggest. We can put these skip descriptors into the
partition table.
struct fis_descriptor_skip {
char magic[4]; // Letter 's' 'k' 'i' 'p'
unsigned long offset; // Offset of skip from partition start
unsigned long size; // Count of bytes in the skip
}
We can put this anywhere in the _pad area of the fis_descriptor. I
recommend that we put it at the end so there is little chance of it
colliding with any possible changes to the FIS structure. Moreover,
it doesn't need to be at any particular place in the padding region.
APEX will scan the whole area for the magic numbers. There will be as
many skip regions as there are fis_descriptor_skip's found.
Thoughts?
Reply to: