Re: comments about Linux BIOS
ron minnich <rminnich <at> gmail.com>
2007-01-08 14:50:05 GMT
On 1/8/07, Stefan Reinauer <stepan <at> coresystems.de> wrote:
> * Chris Cannon <burryme <at> hotmail.com> [070102 04:35]:
> > I am surprised that the list of payloads is not comprehensive; ie.
> > apparently Linux BIOS doesn't provide a straight boot from MBR. This
> > confused me. If this is not a goal, I would suggest making it a goal. This
> > reflects my own philosophy that end-user interests are best served by
> > compatibility.
>
> It is somewhat possible with ADLO, but at this time, there is a lot of
> fiddling involved to get it working.
if you're really determined to support this, I think the best way to
do it is to build on our emulator. I.e. load the MBR and support its
calls via emulation, not direct execution a la ADLO. We've found the
emulator to be very solid, and in fact, somebody is working on
plugging it in to plan 9 to improve their VESA support. So you would
load the MBR, run it under emulation, and take it from there.
The best way, in my view, is to boot linux in flash and have linux
kexec the actual OS you want to boot. But this is tricky. The
advantage is that you can debug such a system completely under Linux,
without linuxbios being involved, until you get it figured out.
But is it possible to boot Vista under Linux via kexec? That would be
interesting.
ron
--
--
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
> I wasn't aware that it requires OFW to be resident during the kernel > boot to handle the devtree. It depends. If all you want is a device tree, you can feed it into the kernel whatever way you want (see the current PowerPC implementation, for example). If you want real services from OF, sure you need it to be there (but not necessarily at "kernel boot" time, it can be a bit earlier, too (a kernel "bootwrapper"). > So it looks like its usefulness for > linuxbios is minimal. Nah, it's fine. > The good side is that it appears that a x86 implementation unified with > the sparc and powerpc code will be well received. There is no way the "OF" part can be easily unified -- but the _filesystem_ part surely can, with some per-architecture (or even more fine-grained) set of accessor routines to the actual device tree. I'll follow up to some of the mails on LKML tomorrow, it's bedtime now
RSS Feed