Thinking out loud again...
The basic requirement of the BIOS core is to place the hardware in in legacy compatibility mode, which all OS software expect to find the system in. This really includes setting up a VGA compatible adapter if it is present.
So if the emulator is small and a compile time option I don't have a problem with putting it in LinuxBIOS exclusively for early video initialization of plug in video cards. Running code through emulation is likely to give us the most predictable results of boards working across different systems, especially non-x86 hardware.
From what I understand there are only very few x86 BIOS services that video
cards depend on, or can depend on at that stage so we should be in reasonably good shape long term. At least until x86 BIOS compatibility is given up.
An important thing to verify here is that the standard cpu identification steps will show the emulated cpu to be a 386 or whatever minimal processor we support. And we should tightly restrict the emulated codes access to memory, presenting it with a virtual not a real view of what is going on. Keeping the code chained as much as possible.
Beyond that...
If we want the video card to provide int 0x10 services to a pcbios compatibility layer we need to rerun the video card initialization in the bochs bios.
I think the simplest path to a flexible LinuxBIOS solution is to have a native LinuxBIOS loader like etherboot, the Linux kernel or possibly something much simpler act as a switch between the different personalities we can wear, PCBIOS openfirmware, efi, arc, etc. And we will boot with whichever one the user selects.
Using a bootloader as a switch to select among the others is the only easy way I can see to have my cake and it too with supporting multiple personalities. You get only one at a time but I think that is easier to verify.
Eric
On 8 Mar 2004, Eric W. Biederman wrote:
An important thing to verify here is that the standard cpu identification steps will show the emulated cpu to be a 386 or whatever minimal processor we support. And we should tightly restrict the emulated codes access to memory, presenting it with a virtual not a real view of what is going on. Keeping the code chained as much as possible.
That is pretty much what we are doing now. We will be plugging the emulator into linuxbios, Ollie is working out the design.
I think the simplest path to a flexible LinuxBIOS solution is to have a native LinuxBIOS loader like etherboot, the Linux kernel or possibly something much simpler act as a switch between the different personalities we can wear, PCBIOS openfirmware, efi, arc, etc. And we will boot with whichever one the user selects.
I'm currenly liking FILO or the linux kernel the best.
Using a bootloader as a switch to select among the others is the only easy way I can see to have my cake and it too with supporting multiple personalities. You get only one at a time but I think that is easier to verify.
we'll see how it goes...
ron
ron minnich rminnich@lanl.gov writes:
On 8 Mar 2004, Eric W. Biederman wrote:
An important thing to verify here is that the standard cpu identification steps will show the emulated cpu to be a 386 or whatever minimal processor we support. And we should tightly restrict the emulated codes access to memory, presenting it with a virtual not a real view of what is going on. Keeping the code chained as much as possible.
That is pretty much what we are doing now. We will be plugging the emulator into linuxbios, Ollie is working out the design.
Right.
I think the simplest path to a flexible LinuxBIOS solution is to have a native LinuxBIOS loader like etherboot, the Linux kernel or possibly something much simpler act as a switch between the different personalities we can wear, PCBIOS openfirmware, efi, arc, etc. And we will boot with whichever one the user selects.
I'm currenly liking FILO or the linux kernel the best.
The Linux kernel is my favored candidate as a general purpose bootloader. FILO has it's uses especially for interactive use. FILO at least at the moment is not targeted at the behind the scenes long term stable interfaces that let a bootloader fade into the background and be forgotten.
If we are going to have a native LinuxBIOS personality this is something we need to consider agree to and write up.
Using a bootloader as a switch to select among the others is the only easy way I can see to have my cake and it too with supporting multiple personalities. You get only one at a time but I think that is easier to verify.
we'll see how it goes...
Yes.
Eric
On 9 Mar 2004, Eric W. Biederman wrote:
The Linux kernel is my favored candidate as a general purpose bootloader.
yes, assuming it fits. We didn't call it linuxbios for no reason: the plan has always been to use linux. We got forced into other options for space reasons at first.
The attraction of FILO is that it lets users, today, boot an install CDROM and load up a system.
ron
-
ebiederman＠lnxi.com -
ron minnich