|
From: David C. <hos...@rc...> - 2001-06-19 06:43:34
|
> > >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 > > --__--__-- > Thanks for Eric's suggestions. I have already deploy etherboot and integrated with our firmware in our prototypes. We are developing a single board computing device experimentaly. LinuxBIOS still lack of some important features over traditional BIOS like Phoenix, Award. We have being working hard on studying hardware specifications and writing drivers for Linux, but the point is lack of support from chips manufacturers. Using etherboot can be easy in deploying code from model to model. On some of our models we will use LinuxBIOS since they are designed to be embedded with Linux and running Linux as their only OS. For other usage, we have to stick with Award and Phoenix since we need some features from them which LinuxBIOS doesn't have. And yes, we are planning to add more and more stuff to the firmware which is originaly based on etherboot which makes etherboot a good start on firmware development and OS loader. It is also good to hear from LinuxBIOS that they can contribute in the development of new features and new designs. We would like to contribute.. Thanks. regards, David |
