Hello again from Gregg C Levine More things are working. Eric, about your draft proposal, "draft1_elf_boot_proposal.txt", that you posted here, a while ago. In the contents pages, you've got a typo, you had misspelled the word "network". So far the patches that I had applied to my kernel tree, that are normally applied when we are building kernels for LinuxBIOS work. I configured my system to boot, and then make use a of a serial console, and was able to see some of the output. I say some, because I, ah, didn't get it to work correctly. I can see the notes that the bootloader functions for LinuxBIOS puts into the kernel at work. Its an interesting process. Going to try again later. And it's nice to see that this thread that I've started is off and running like this. ------------------- Gregg C Levine [EMAIL PROTECTED] ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke."� Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda )
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:owner- > [EMAIL PROTECTED]] On Behalf Of Eric W Biederman > Sent: Saturday, August 10, 2002 8:27 PM > To: Ronald G Minnich > Cc: Preston L. Bannister; Linuxbios > Subject: Re: A question for the audience > > Ronald G Minnich <[EMAIL PROTECTED]> writes: > > > On 10 Aug 2002, Eric W Biederman wrote: > > > > > > > > > A couple motherboard manufacturers are talking to us and they understand > > > > the need for bigger flash, so will do it. > > > > > > We will see. > > > > I should mention they're not all in the x86 space. When you get out of > > that x86 mess things get much more reasonable. > > Which is why I have implemented relocation in etherboot like I have, > it forces most of the driver portability issues out into the open, as it > breaks the 1-1 virtual-bus address mapping on x86. > > > > As for performance you would have to make a good case of how Linux > > > equals etherboot. The actual Linux drivers are more highly tuned, but > > > it takes seconds to get the loaded, at which point etherboot is > > > already gone, and has loaded the final kernel. > > > > assuming modules .. > > Actually that was with the drivers compiled in. I need to try modules > and see if the kernel initializes faster if the needed modules are loaded > on demand. > > > > There is a very big disadvantage to using Linux as a bootloader, and > > > that is you need to ask it shutdown all of the the hardware it has > > > initialized, and restore the hardware to it's boot time settings or > > > some approxmimation thereof. > > > > this is important. You're on the money. We either have to get clean > > shutdown or we have to have a way to tell linux "it's done already". Or we > > give up on linux as a bootloader. > > Right. And I will revisit that problem when I have a functional bootloader > that works on the hardware most people can buy. > > Eric
