[EMAIL PROTECTED] writes:
> >Assuming that a clean approach can be found to use etherboot in
> >linuxBIOS. Would you be willing for etherboot to go in that direction?
> >The expectation here is that the linuxBIOS developers would contribute
> >the code to work with linuxBIOS.
>
> Speaking for myself, I'm all for it. I think that accepting fresh
> challenges will bring a wider audience to both linuxBIOS and Etherboot.
> I know that various experimenters have deployed Etherboot on bare metal
> so I'm sure a clean solution can be found. When do we start?
Some preliminary implementations have already been done.
If you are really interested you can follow the discussion on
the linuxbios mailing list (now CC'd).
Look at www.linuxbios.org
Somewhere there should be a link to the linuxbios mailing list archive.
Tiara is the farthest along of the work that has been done.
The challenge that keeps us from accepting just about anything
is that interesting firmware seems to keep evolving into it's own OS
and we really don't want to do that, with linuxBIOS.
Conceptually linuxBIOS is made up of 3 parts.
stage1 -- ram initialization.
(Everything cannot be done in normal C code).
stage2 -- Basic system initialization.
stage3/1 -- Failsafe bootloader.
stage3/2 -- Bootloader.
The model is still being refined because we have some widely varing
targets.
Primarily for the bootloader in stage3 we intend to use linux.
Reusing an entire OS for where you need one somehow makes so
much sense.
We are still working on a backup booting strategy, and how
to deal with kernels that don't have drivers to all of the hardware.
So we are looking at using etherboot as our failsafe bootloader, and a
bootloader for when we don't have enough flash, to include the linux
kernel.
My hunch right now is that the cleanest way to work together is to
have etherboot compile into a network bootable ELF executable, and we
could just reuse it whole. I have already written an ELF bootloader
for linuxBIOS, so that end is covered.
There seem to be a few other ideas out there as well.
I suspect it will take a couple of months of playing with ideas
to come up with a good design and see it implemented and accepted.
On the linuxBIOS side the difficult part is to figure out where
to place code that is needed for system iniitialization where the
drivers have not been written for linux yet. Will they go into
a kernel patch? Will they go in a bootloader? Somewhere else?
They must be cleanly seperated from the rest of the linuxBIOS code
because the intention is to remove them long term. But we are stuck
with them shortterm. Because the BIOS developers tend to get access
to a board before the kernel developers do. For obvious reasons :)
Eric
