On Thu, 27 Jan 2005, Peter Stuge wrote:
> That's how LinuxBIOS was initially designed. > > LinuxBIOS in itself is "only" minimal code for initializing a > mainboard with peripherals just enough for a Linux kernel to take > over and to the rest. > > LinuxBIOS does not contain a kernel per se. > > After the initialization, LinuxBIOS jumps to a payload and while > there has been discussion about stacking payloads that's currently > not in practice. > > The payload was originally intended to be a Linux kernel stored in > flash. Flash ROM grow rate was anticipated optimistically however, > today there are not many mainboards that actually have enough flash > ROM room for a kernel. 512KB can be seen here-and-there and a few > boards come with 1MB. Recent kernels really want that MB, and then > you'll only have room for 3-400 KB of initial ramdisk, which could > be too small too, depending on the application. > > So, other payloads are used; the two major ones are FILO and > Etherboot. FILE loads a kernel from a filesystem on an IDE device and > Etherboot loads a kernel from the network or from a filesystem on an > IDE device. > > If you're using FILO there is no Linux kernel until FILO loads it, > and the kernel loaded by FILO (or Etherboot) can absolutely be the > one you want to run in your system. Just set it up with the correct > root and init commandline so that it can start init. > > Another option is to chain two kernels after each other, this is > useful for loading a system kernel from some place that FILO or > Etherboot can not reach, but which a Linux kernel can. Imagine all > sorts of "strange" storage ranging from local JFS to "unusual" > network systems and beyond. This uses the kexec feature in 2.6, > where a kernel can execute another kernel. > > Hope this helps. looks like a great FAQ entry to me ron _______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
