Re: APEX and Debian
* 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.
> What about the option of putting two kernels into flash.
I don't think that would change. You could have kernel2 and then tell
APEX to do a "fis load kernel2" instead.
> 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.
> 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
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.
> 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.
> 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.
However, it's entirely possible that I'm missing something...
--
Martin Michlmayr
http://www.cyrius.com/
Reply to: