Re: APEX and Debian

[Marc Singer <elf@buici.com>]

On Wed, Jul 19, 2006 at 02:47:58PM +0200, Martin Michlmayr wrote:
> * Marc Singer <elf@buici.com> [2006-07-18 15:20]:
> > It copies the kernel image, starting from 0x80000 for 2MiB to SDRAM
> > and then jumps to it.
> 
> > Have I missed anything?  Do we want to copy more than 2M of kernel?
> 
> I'd like to avoid harcoding any specific numbers.  While 2M is
> probably enough, I don't want to run into similar problems in the
> future as we have now with the 1M limit.  Ideally, what I'd like to
> see is that APEX would simply call the equivalent of RedBoot's
>    fis load ramdisk
>    fis load kernel
> And simply look at the FIS table to see where those can be found.

Are you planning to use a ramdisk?  What about the option of putting
two kernels into flash.  How is this going to work when APEX is in the
partition labeled 'kernel' in the FIS table?

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.

My proposal is to use an environment instead of the FIS partition
table.  It is more flexible and can be configured in the flashing
process.  In this scenario, APEX is written to the address where the
kernel used to be.  We leave the FIS partition table alone.  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.  It can be told to copy the kernel and, if
needed, copy a ramdisk.  Then, it will jump to the kernel with the
necessary parameters.

> Then we neither have to worry whether APEX will get bigger than 128K
> in the future or how big the kernel might be.  We can simply put APEX
> at the location where NSLU2's RedBoot loads Linux from and have APEX
> find the real kernel via the FIS table.

All of that holds true in this scenario , except that we don't depend
on the FIS partition table and it's limited concept of kernel and
ramdisk.  Also, we *can* put more two kernels into flash more easily
this way.

> The big downside I see is that this means breaking slugimage's
> assumption about the FIS layout on the slug and fixing it will need a
> fairly major rewrite, i.e. the ability to add more FIS partitions than
> it currently knows about.  Then again, this is a good opportunity to
> covert slugimage into a more general FIS flash generator...

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.

Cheers.