Adam Agnew <[EMAIL PROTECTED]> writes: > > > Ron, what do you think about adding a bootloader (in the linuxBIOS > > > tree), that uses the fill_inbuf architecture we already have for > > > booting. I don't want to add boot policy in the core of the tree but > > > if we had an optional bootloader that shouldn't be a problem. > > > > I think it's a good idea, it would extend what steve james has already > > done for ethernet. You know me, I would rather have linux do this work, > > but the mainboard manufacturers are NOT cooperating in giving us those > > big FLASH parts :-) > > > > > And if it shared it's drivers with the main linuxBIOS we could load > > > one kernel from anywhere... > > > > > It might make sense to work with something like etherboot on this but > > > having it internal looks easier... > > > > It just seems like we have no choice. > > > > Question, though: What do we do about people who want to interact with > > the boot loader and use graphics? do we put graphics into linuxbios? Then > > it may grow big! > > > > We've got a problem here ... it's bigger then just the bootloader, maybe. > > > > Can we rewind for just a second here? We don't need a bootloader IN > linuxbios. We can have a very simple scheme that uses the existing elf > loader code in linuxbios well. I'm surprised at you Eric, you of all > people should appreciate the beauty of the elf-loader scheme you were > pushing so hard for earlier.
Clarification I meant in the linuxBIOS tree, and sharing source. Not in the linuxBIOS build. Passing a file something like: <<EOF target /home/eric/projects/freebios/p4dc6-build/bootloader bootloader miniboot option USE_FLOPPY_FILL_INBUF=1 option USE_SERIAL_FILL_INBUF=1 option USE_ELF_BOOT=1 EOF And then the bootloader is built seperately, and loaded by my ELF bootloader... > > Several possibilities. > > Although it will be hard to convert, lets assume we want to use Grub for > our bootloader. > > Step 1) Linuxbios's elf loader grabs an image from ROM just like it does > now. On to step 2. > > Step 2) This elf image of about 10k in size probably loads another elf > image from the mbr of the hard disk controller. It is so small because it > doesn't need to worry about file systems or anything like that. The image > it just loaded off of the mbr brings us to step 3. > > Step 3) This elf image would be grub's stage1.5, which is only smart > enough to load a grub stage 2 image from a real filesystem because a grub > stage 2 image is far too large for an mbr. This brings us to step 4. > > Step 4) Grub is a huge honkin' bootloader that will give us pretty menus > and lots of functionality. > > Okay, maybe it's not terribly simple, but it will be mostly transparent > and fast. Sounds about what I'm thinking. The Step 2 bootloader I just want to put in the tree. And instead of Grub I'd use something built on top of the linux kernel, but that is six of one 1/2 dozen of the other. > > If someone just wants a bootloader that understands ext2fs and loads a > multiboot kernel with an already given filename, I'm almost done that. I > can't finish it right now however as I have a test tomorrow, but it's > reading the kernel image correctly and merely needs to pass the image to > etherboot's internal elf loader which is being a bit of a pain. But I can > release that shortly, all of Redboot's code is gone. Eric if you have some > time and are interested, I'd be happy to send you what I have now so you > can take a look at it. It's a bit of a mess but looking very promising. Yes I do, and am interested. > If someone just wants etherboot functionality, again it should be just a > simple elf image, Eric has already done that. > > And it sounds like Eric is done making a bootloader that grabs from a > floppy in a raw manner. It doesn't sound like he made it a seperate elf > image, but I'd be happy to work on making it one. Right. I like the possibility of the core linuxBIOS code being able to share the drivers between a linuxBIOS miniboot loader, and the core of linuxBIOS. > In short, I feel that yes we have to give up on loading linux as a > bootloader for most cases. But that doesn't mean we have to go to the > horrible extreme of throwing everything and the kitchen sink into > linuxbios. > > *sigh* Sorry, i just thought we had all came to an understanding about > this just a few days ago. We did, but if we are going to hack up something to get a policy change I'd rather have it in the linuxBIOS core. My apologies for not repling sooner. I had a small distraction I had to get rid of. Eric
