CCing the OpenBIOS mailinglist.
* Eric W. Biederman ebiederman@lnxi.com [040203 20:07]:
Tarl Neustaedter Tarl.Neustaedter@sun.com writes:
Eric W. Biederman wrote:
Tarl Neustaedter Tarl.Neustaedter@sun.com writes:
If you have any specific questions about OpenFirmware, I'd be delighted to provide assistance. I've been doing IEEE 1275 since 1996, and was at one time a voting member of that committee (since pretty much defunct). The specs are engraved upon my skull by now.
:-) That is good to know. There will be a lot of things to clarify when the base implementation of OpenBIOS is complete and operable.
The main problem is that cards don't usually come with IEEE 1275 FCode on them. We've pretty much had to write all of ours, and have gotten tired of it - we're actually looking at LinuxBIOS as a way to get out of that business, and just build in the drivers we care to in the Linux kernel on the prom. But I can answer questions any questions about writing FCode, it's most of what I've done in recent years.
One big problem in the picture is that there is a certain amount of hardware that assumes firmware did a job before running the linux driver.
So basically there is no real way around having an x86 option rom. It seems. Intel is trying to break out and move firmware developers to their EFI bytecode, which does the same thing OpenFirmware FCode does, just with the need of 4*8MBit Flash to store all of the virtual machine in (An OpenBIOS+LinuxBIOS solution easily fits in 2MBit) I've dropped the illusion of getting convinced some day that EFI is the way to go, but if there's a wave of change now anyway, it's high time for some educational advertising of using "long term industry proven standards" instead of KUAI-Implementations.
I don't see it all that negative for FCode firmware in option roms. It's just not going to happen in small numbers. For this to happen, there have to be _many_many_many_ machines with an IEEE 1275 compliant boot firmware. Such a system could for example still use expansion cards with x86 pcbios compliant option roms - Generating the needed OpenFirmware wrapper nodes based on the device type (display, block, ... ) is no magic once the initialization of the device itself is done. This would allow to use such cards in an open firmware environment while the OS can rely on the fact that there is a device that can be operated using the Open Firmware interface.
Interesting. The observation that powerful firmware eventually becomes an OS so you might as well use an OS, seems true :)
If you use EFI, you even get all the old DOS tools.
The one problem with using Linux so far has been size constraints. The primary interim solution has been to use etherboot. You have to port the Linux drivers to it but it close enough you don't have to rewrite them from scratch, and it is small. 16K-32K is typical with one network driver and a IP stack. 128K when you build in all the network drivers.
OpenBIOS is currently only reusing filesystem drivers from grub, but an interface for network booting so that etherboot drivers can be used should not overtop the fs efforts a lot.
The location where option roms come into play in the pc world are scsi adapters, raid controllers, and video. For scsi adapters and raid controllers every case I have looked at the linux drivers are good enough that you don't need the option roms. Video drivers are still problematic.
This is not true for many Opteron boards, ie those coming with the LSI 1020/1030 scsi controllers. There might be a fix for this on the horizon, but it only solves the problem for this specific controller. If there is a way to clean out these issues generically without having to think in terms of single controller or video cards, we should definitely provide this as an option.
How has sun coped with getting video drivers for high end video cards. I know Apple seems to have succeeded in working with NVIDIA. I suspect that is with open firmware side but I don't know.
Apple succeeded by putting all of the actual driver code in a special property of the device node, and have the fcode rom not initialize the device but just create the device node. A good example of how _not_ to do it.
Stefan