On 7 Feb, Eric W. Biederman wrote:
> [EMAIL PROTECTED] writes:
>> Could you give a very brief description of the kexec "api"? I'm
>> currious about how it is different and/or better than the current
>> system.
>
> It's intial target is booting kernels over the network, without having
> to change processor modes. It should not be operating system dependant.
>
> The image format is an elf executable. ELF is very suitable for
> this because the executable format after the elf header (which lists
> the entry point) is the program header. Which just where chunks of the
> file go into memory. Usually the ramdisk is one segment of the file,
> and the kernel is another.
>
> With a small wrapper program it is easy to encode command lines,
> ramdisk parameters, or anything else into the ELF image.
>
> There is also a slot for passing a command line, and some unprobeable
> hardware parameters.
>
> There are no callbacks.
>
> The advantage over what we currently do are:
> a) No weird changes from kernel to kernel
> b) You can have different kernel start addresses and load kernels into
> different places in memory.
> c) requires less code than what we currently do.
> d) You can test the kernel before flashing it into ram.
> And with a little care we can set the kernel and linuxBIOS as independantly
>flashable.
>
> This is what I have done with ron's lobos. Idea.
I like it. I have never really looked into what makes an ELF
executable but it looks like you have taken an existing standard to do
many of the things we are re-inventing for linuxbios.
Do you have an "ELF" loader for linuxbios or have you only tested this
from linux?
One "problem" I see is if you want to be able to use the same
filesystem image for 2 different kernels or two different filesystem
images with a single kernel image. In these cases you might want to be
able to upgrade one kernel but not the other kernel or the filesystem
image. Where the kernel image and filesystem are tightly bound
together this might be difficult.
My system doesn't need this flexibility so I can't say if this is
really a requirement for a good system or not.
>> >> (c) Implement a search algorithm in the rom where we look for a
>> >> ELF header to find the kernel. Instead of hardcoding its
>> >> location into ROM.
>>
>> I need to be able to boot either of at least 2 images from a paged
>> flash chip. Wouldn't a search algorithm work against me?
>
> Possibly. Maybe not. My thought was simply have something walk through
> rom, and for each image it found increment a counter. So you could
> boot kernel 1 or kernel 2 or kernel 3. You just set something in
> the CMOS or the flash saying what to boot. A pointer might be just
> as good. Figuring out what we need to boot multiple kernels from
> the flash and how to fallback and revert if a new one fails is my
> challenge. The trick is so you can make the kernels indepedently
> erasable without killing each other.
Keeping them from stepping on each other is easy. ...just make sure that
they are not in the same block for when erase time comes.
The policy for what image to boot when is likley to be
hardware/application dependent so I am still skeptical of this one.
> Eric
Ty
--
Tyson D Sawyer iRobot Corporation
Senior Systems Engineer Real World Interface Div.
[EMAIL PROTECTED] Robots for the Real World
603-532-6900 ext 206 http://www.irobot.com
