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

Re: APEX and Debian



On Wed, Jul 19, 2006 at 06:31:06PM +0200, Martin Michlmayr wrote:
> * Marc Singer <elf@buici.com> [2006-07-19 09:17]:
> > Are you planning to use a ramdisk?
> 
> Yes, we use an initramfs which contains various modules, and that
> won't change even if we had enough space for the kernel to build in
> USB and stuff.

I'm confused.  ramdisks and initramfs are different.  I'm certain you
know this.  One is loaded with the kernel and the other is loaded
separately and a pointer is passed to the kernel so it can be found.

Are you planning to use both types?

> > How is this going to work when APEX is in the partition labeled
> > 'kernel' in the FIS table?
> 
> It's not.  RedBoot completely ignores the FIS headings and simply
> loads whatever is at a specific location in flash into memory and
> executes it.  We can create a FIS entry "APEX" there and have "kernel"
> somewhere else.

Hmm.  Sloppy of them.

> > My proposal is to use an environment instead of the FIS partition
> > table.
> ...
> > During the image flashing process, an environment is written to an
> > agreed upon location (e.g. portion of the sysconf partition) that
> > tells APEX what to do when it starts.
> 
> Actually, I don't think there's a conflict with that I suggested.
> You'd need such an environment anyway which tells APEX what to do.  In
> my case, this would be
>   fis load ramdisk
>   fis load kernel
> And in your case it would be something like
>   load kernel from location foo up to the next 2 MB
>   load ramdisk from bar

Grudgingly, I admit that the partition table has a utility in that the
region of flash for a given piece of data is in a know location and a
known format.  APEX's environment is a list of commands: copy from
here to here, etc.

> Which is essentially the same, just that using the FIS labels would be
> more generic/flexible.  However, assuming that you can change that
> environment (i.e. the commands executed by APEX) from Linux, it
> probably doesn't matter much.

Well, I'd like to recover the flash space.

> > I don't see a problem with reading the partition table, though IMHO
> > it is much more of a hack than the methods available in APEX.
> 
> Maybe I don't quite understand what APEX can do, but I don't see how
> using the FIS labels/partition table is more of a hack than harcoding
> some random memory values/lenghts.

Only that the partition table is modeled on hard-disk IO.  Editing the
partition table requires an erase and rewrite of the data.  APEX's
environment is tailored to flash such that changes do not require an
erase until so many changes have been made that the region needs
to be erased.

> > I'd be OK adding FIS support if you are certain that is what you
> > want.  I'd rather move away from the legacy RedBoot components.
> 
> Is there anything better than FIS?  Surely FIS is better than
> harcoding the position/lenght of things, which afaik is the only
> alternative.

Sort of.  APEX has a startup command that can come from the
environment.  It could say something like:

  copy nor:1M+2M $bootaddr ; boot

which means copy something from flash to SDRAM and then start
executing the code at whatever $bootaddr is set to be.  This isn't
hardcoded in that the source flash address doesn't come from the
executable.

> However, it's entirely possible that I'm missing something...

Here's what I think I'll do.  This will give us an opportunity to
explore the possibilities.  I'll add an FIS: partition driver to APEX
that can read flash partitions and use them as data sources for
copying.  I'll add environment support as well that can share a flash
block with other data.  Then, we can experiment.  APEX will use the
partitions, or not depending on the commands stored in the
environment.

Then, the startup command could be

  copy fis:/kernel $bootaddr ; copy fis:/ramdisk $ramdiskaddr ; boot 

Cheers.



Reply to: