Hello,
It turns out that the VGABIOS support can be made pretty generic for all kinds of PCI expansion ROM. So I have the emulator the .init method of default_pci_ops_dev. I am going to add the following directories, if there is no objection, I will commit it next week.
src/include/x86emu -- public header file of x86emu src/devices/pci_rom.c -- expansion ROM loading and execution src/devices/emulator -- the emulator and supporting functions src/devices/emulator/x86emu -- the emulator itself src/devices/emulator/pcbios -- legacy PC BIOS handler for the emulator src/devices/emulator/biosemu.c -- glue between pci_rom.c and the emulator
Any comments ?
Ollie
Li-Ta Lo ollie@lanl.gov writes:
Hello,
It turns out that the VGABIOS support can be made pretty generic for all kinds of PCI expansion ROM. So I have the emulator the .init method of default_pci_ops_dev. I am going to add the following directories, if there is no objection, I will commit it next week.
Except for plug in video cards I don't think this is a direction we want to go in. So at least for now pleas don't make the emulator the default .init method.
src/include/x86emu -- public header file of x86emu src/devices/pci_rom.c -- expansion ROM loading and execution src/devices/emulator -- the emulator and supporting functions src/devices/emulator/x86emu -- the emulator itself src/devices/emulator/pcbios -- legacy PC BIOS handler for the emulator src/devices/emulator/biosemu.c -- glue between pci_rom.c and the
emulator
Any comments ?
Your structure looks fairly sane.
Eric
On Thu, 6 Jan 2005, Li-Ta Lo wrote:
Any comments ?
This is wonderful, as it may solve the SCSI problem too.
ron
On Thu, 6 Jan 2005, Ronald G. Minnich wrote:
On Thu, 6 Jan 2005, Li-Ta Lo wrote:
Any comments ?
This is wonderful, as it may solve the SCSI problem too.
I agree with eric that in general going to expansion roms as an option is undesirable, but ... sometimes you have no choice. I have friends at one lab who will be able to use linuxbios on 64 machines if we can init the SCSI BIOS on their RAIDs.
ron
* Ronald G. Minnich rminnich@lanl.gov [050107 05:54]:
On Thu, 6 Jan 2005, Li-Ta Lo wrote:
Any comments ?
This is wonderful, as it may solve the SCSI problem too.
I agree with eric that in general going to expansion roms as an option is undesirable, but ... sometimes you have no choice. I have friends at one lab who will be able to use linuxbios on 64 machines if we can init the SCSI BIOS on their RAIDs.
Definitely! Pragmatic decisions are not always those with the nicest design, but in this case it will no doubt help LinuxBIOS gain a lot of momentum against the other alternatives (ie. http://www.tianocore.org/)
getting scsi to work will be some more work than vga due to int13 overloading, but given how far things have come in the last couple of days this will happen rather sooner than later.
Stefan
* Stefan Reinauer stepan@openbios.org [050107 15:40]:
Definitely! Pragmatic decisions are not always those with the nicest design, but in this case it will no doubt help LinuxBIOS gain a lot of momentum against the other alternatives (ie. http://www.tianocore.org/)
They are _really_ _honestly_ making their EFI stuff _freely_ available:
Excerpt of the Usage Agreements for the source code
Grant of License to Use [..] You acknowledge and agree that You will not, directly or indirectly: (i) reverse engineer, decompile, disassemble or otherwise attempt to discover the underlying source code or underlying ideas or algorithms of the Software; (ii) modify, translate, or create derivative works based on the Software; (iii) rent, lease, distribute, sell, resell or assign, or otherwise transfer rights to the Software; or (iv) remove any proprietary notices in the Software. [..]
IANAL, but do I get it right that before I am allowed to see their sources for _participating_ in their neat little project I have to accept that I am not going to _modify_ them or discover the way they work?
The derivative work clause almost seems like nothing compared to this.
There are 17 more paragraphs which I did not even dare reading anymore.
Poor guys who made the mistake clicking on "I agree".. "All your bases are belong to us".
Stefan
On Fri, 7 Jan 2005, Stefan Reinauer wrote:
They are _really_ _honestly_ making their EFI stuff _freely_ available:
sarcasm?
I've pinged Intel about this agreement, I am asking if there will be an anonymous download capability. Also, Stefan, does it look like redistribution is ok?
ron
On Fri, 7 Jan 2005, Stefan Reinauer wrote:
momentum against the other alternatives (ie. http://www.tianocore.org/)
now that stefan has mentioned this ... will anyone who feels interested please take a look at tianocore.org and let us know what you think? I'm interested in hearing your thoughts.
ron
On Fri, 2005-01-07 at 07:40, Stefan Reinauer wrote:
getting scsi to work will be some more work than vga due to int13 overloading, but given how far things have come in the last couple of days this will happen rather sooner than later.
For scsi, do we need the 'runtime' part as well as the 'init' part ? The emulator has support to install an int handler (the real thing from the BIOS image, not our C code emulation) and call the int handler. Since in the LinuxBIOS, the emulator uses virtual==physical address, we can just keep the scsi bios in the memory and do some int13 call if we have to.
Ollie
* Li-Ta Lo ollie@lanl.gov [050107 16:26]:
For scsi, do we need the 'runtime' part as well as the 'init' part ? The emulator has support to install an int handler (the real thing from the BIOS image, not our C code emulation) and call the int handler.
This is exactly what we need.
Since in the LinuxBIOS, the emulator uses virtual==physical address, we can just keep the scsi bios in the memory and do some int13 call if we have to.
There should be some streaming driver such as ROM_STREAM, IDE_STREAM or FS_STREAM: INT13_STREAM which allows reading a kernel image from disk. I would guess this allows to use a whole couple of other devices that "misuse" int13 to become bootable as well.
Stefan.