There are some interesting points of comparing experience between Open firmware and LinuxBIOS so I am copying the list.
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.
Cool. Stefan Reinauer stepan@suse.de is more likely to ask questions as he is the primary implementor of OpenBIOS. Which is a payload from the LinuxBIOS context. As a standard for running code in options roms it does not look too bad.
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.
Interesting. The observation that powerful firmware eventually becomes an OS so you might as well use an OS, seems true :)
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.
I have recently found some kernel patches that start to shrink the Linux kernel by allowing you to compile out unnecessary pieces so I about ready to make a foray into using Linux as our bootloader again. But until I have squeezed a lot of the size bloat out I won't be convinced it is the way to go.
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.
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.
Eric
On 3 Feb 2004, Eric W. Biederman wrote:
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.
Interesting. The observation that powerful firmware eventually becomes an OS so you might as well use an OS, seems true :)
I don't expect the cards to come with fcode any time soon, if ever. Four reasons: first, the market is more or less zero, and the all the non-x86 systems support x86 emulators to support the x86 option roms; second, if they support two option roms (fcode, x86) that makes for lots more work; third, the PC market will probably never go to fcode; and fourth, I bet they (naively) think that fcode would make reverse engineering easier.
ron
ron minnich rminnich@lanl.gov writes:
I don't expect the cards to come with fcode any time soon, if ever. Four reasons: first, the market is more or less zero, and the all the non-x86 systems support x86 emulators to support the x86 option roms;
For video. Does any one support anything else? RAID cards?
second, if they support two option roms (fcode, x86) that makes for lots more work; third, the PC market will probably never go to fcode; and fourth, I bet they (naively) think that fcode would make reverse engineering easier.
Yes, there are reasons it is unlikely to happen and those are reasons I really have not done much. Stefan believes in it so I think it makes a good test case of what we can support in LinuxBIOS. Mostly this is if I had to support the interface it would not suck to support :)
What I am actually thinking is the long term solution is to just use everyones driver disks (or the equivalent) for linux and if the BIOS does not contain the drivers you need it is just a rebuild of your boot loader away. Yes this means you have to boot your system once to load the driver for your new cool boot device but that should always be possible.
Eric
On 3 Feb 2004, Eric W. Biederman wrote:
For video. Does any one support anything else? RAID cards?
Not sure on PPC. The Alpha doesn't matter any more but my memory says that if you put a card with an option rom on the Alpha it would run the ROM. But that's very old memory.
ron
* ron minnich rminnich@lanl.gov [040204 04:49]:
On 3 Feb 2004, Eric W. Biederman wrote:
For video. Does any one support anything else? RAID cards?
Not sure on PPC. The Alpha doesn't matter any more but my memory says that if you put a card with an option rom on the Alpha it would run the ROM. But that's very old memory.
Yes, the Alpha was able to initialize RAID/SCSI x86 option roms. SRM was even defining an os callback to execute intXX calls from a running operating system. Unfortunately it was never implemented.
Best regards, Stefan Reinauer
Stefan Reinauer stepan@suse.de writes:
- ron minnich rminnich@lanl.gov [040204 04:49]:
On 3 Feb 2004, Eric W. Biederman wrote:
For video. Does any one support anything else? RAID cards?
Not sure on PPC. The Alpha doesn't matter any more but my memory says that if you put a card with an option rom on the Alpha it would run the ROM. But that's very old memory.
Yes, the Alpha was able to initialize RAID/SCSI x86 option roms. SRM was even defining an os callback to execute intXX calls from a running operating system. Unfortunately it was never implemented.
Interesting. I do know that the RAID/SCSI x86 option roms in general were not needed on the Alpha. Do you know of any RAID/SCSI cards that actually need their option ROM to be run?
Every one I have research it is a non issue.
Eric
On 4 Feb 2004, Eric W. Biederman wrote:
Interesting. I do know that the RAID/SCSI x86 option roms in general were not needed on the Alpha. Do you know of any RAID/SCSI cards that actually need their option ROM to be run?
Every one I have research it is a non issue.
I forget which card it was, but we did have a problem here at one point with a card that really needed that scsi bios to be run. We junked the card.
ron
* Eric W. Biederman ebiederman@lnxi.com [040205 00:39]:
Yes, the Alpha was able to initialize RAID/SCSI x86 option roms. SRM was even defining an os callback to execute intXX calls from a running operating system. Unfortunately it was never implemented.
Interesting. I do know that the RAID/SCSI x86 option roms in general were not needed on the Alpha. Do you know of any RAID/SCSI cards that actually need their option ROM to be run?
I think the DAC960 was one of those. It even needed a special firmware version to run through the CPU emulation iirc.
Stefan
* ron minnich rminnich@lanl.gov [040203 22:46]:
I don't expect the cards to come with fcode any time soon, if ever. Four reasons: first, the market is more or less zero, and the all the non-x86 systems support x86 emulators to support the x86 option roms; second, if they support two option roms (fcode, x86) that makes for lots more work; third, the PC market will probably never go to fcode; and fourth, I bet they (naively) think that fcode would make reverse engineering easier.
I fully agree that using ndisasm is by no means more complicated than using my fcode detokenizer detok. All x86/efi option rom discussion sounds rather like a game of not stepping on the others' toes rather than technologically driven reasoning.
OpenBIOS can be used on top of a PC BIOS as well, thus it could allow to use any Open Firmware compliant pci card in a machine that still has different firmware in rom. This is one step towards the great unification..
If the concept of having a diversity of hardware architectures available is going to survive, there has to be a generic solution to the early initialization issues.
Best regards, Stefan Reinauer
On Wed, 4 Feb 2004, Stefan Reinauer wrote:
If the concept of having a diversity of hardware architectures available is going to survive, there has to be a generic solution to the early initialization issues.
I agree completely. It is sad that the generic solution so far is x86 instructions.
We can hope this improves, but I am pessimistic.
ron
On Wed, Feb 04, 2004 at 10:23:17AM -0700, ron minnich wrote:
On Wed, 4 Feb 2004, Stefan Reinauer wrote:
If the concept of having a diversity of hardware architectures available is going to survive, there has to be a generic solution to the early initialization issues.
I agree completely. It is sad that the generic solution so far is x86 instructions.
Actually, I think the generic solution has been to not use option roms at all. :-) After all, most cards don't use them (VGA being the notable exception).
Frankly, if I had any pull with manufactures or vendors, I'd try to convince them to avoid option roms instead of trying to convince them to support a different option rom format.
Having cards that conform to standards (or can emulate them during bootup) will be a lot more productive IMO, then a cross platform byte code.
-Kevin
On Wed, 4 Feb 2004, Kevin O'Connor wrote:
Frankly, if I had any pull with manufactures or vendors, I'd try to convince them to avoid option roms instead of trying to convince them to support a different option rom format.
True. But vendors often hide hardware bug fixes in option roms.
Just FYI, we just now got an Nvidia agp card to initialize and work much better with the emulator, in the agp slot, on the tyan s2885. We get the little nvidia startup message, and then the vga console works.
We have a bit of fixup to do now in linuxbios for the things we found, including some MTRR and northbridge stuff. But it is nice to see it getting that far.
ron
"Kevin O'Connor" kevin@koconnor.net writes:
Actually, I think the generic solution has been to not use option roms at all. :-) After all, most cards don't use them (VGA being the notable exception).
Agreed.
Frankly, if I had any pull with manufactures or vendors, I'd try to convince them to avoid option roms instead of trying to convince them to support a different option rom format.
Yes. There are cases where multiple vendors need some input on what the firmware is doing and in those cases option roms come into play.
So for high enough volumes the firmware simply can't be solely controlled by the board vendors.
This does not make option roms the only business solution but one of them.
Having cards that conform to standards (or can emulate them during bootup) will be a lot more productive IMO, then a cross platform byte code.
That is the one place where it is the hardest. Usually hardware can be put into an emulation mode but only after it is initialized. I believe one of the important functions of an option roms on video cards is to turn on the memory for the video card.
Eric
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
Stefan Reinauer wrote: [...]
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
Actually, my understanding is that the multi-megabyte flash is only required for the IA-64 implementation. The IA-32 implementation of EFI from some vendors is reported to fit comfortably in 1MB.
One thing we've discovered recently is that the x86 firmware world is rife in rumors, FUD, and propaganda. It's pretty startling.
I've dropped the illusion of getting convinced some day that EFI is the way to go,
It certainly looks good; they seem to have learned a bunch of lessons from the OpenFirmware experience. Unfortunately, we got stopped by license issues - to go any further than just the basic spec, there is a "click to agree" license button on the web page which our legal team told us not to click.
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.
Sun pushed for this for many years; the IEEE 1275 specification and firmworks.com were both funded by Sun exporting technology they had developed in the early '90s, with an eye to moving the industry along in this direction. It sputtered along with minimal industry acceptance and largely fizzled out before 2000.
The specification (IEEE 1275-1994) is now obsolete; it's supposed to be renewed every five years, and there just wasn't the funding and interest level to get it done. We still use the specification in our day-to-day operations, but I don't think IEEE will even sell copies any more.
If you can revive interest in OpenFirmware, I'll be delighted. My personal opinion is that it's a sisyphean task, but don't let that stop you :-) Tarl Neustaedter
On Wed, 4 Feb 2004, Tarl Neustaedter wrote:
Actually, my understanding is that the multi-megabyte flash is only required for the IA-64 implementation. The IA-32 implementation of EFI from some vendors is reported to fit comfortably in 1MB.
that may change when people start to use it, not sure. Some of the Intel boards we got recently had really large flash parts.
One thing we've discovered recently is that the x86 firmware world is rife in rumors, FUD, and propaganda. It's pretty startling.
it's pretty weird. I've gotten all kinds of strange stuff from different places :-)
It certainly looks good; they seem to have learned a bunch of lessons from the OpenFirmware experience. Unfortunately, we got stopped by license issues - to go any further than just the basic spec, there is a "click to agree" license button on the web page which our legal team told us not to click.
and that's the way it will stay, I'm told. I'm unhappy with a bios that needs CHKDSK in any event.
ron
Tarl Neustaedter Tarl.Neustaedter@sun.com writes:
Stefan Reinauer wrote: [...]
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
Actually, my understanding is that the multi-megabyte flash is only required for the IA-64 implementation. The IA-32 implementation of EFI from some vendors is reported to fit comfortably in 1MB.
The EFI guys have been working really hard to get their footprint down. IA-64 native code gives you an automatic 3x code bloat so it trivially requires 3x more rom space.
One thing we've discovered recently is that the x86 firmware world is rife in rumors, FUD, and propaganda. It's pretty startling.
I've dropped the illusion of getting convinced some day that EFI is the way to go,
It certainly looks good; they seem to have learned a bunch of lessons from the OpenFirmware experience. Unfortunately, we got stopped by license issues - to go any further than just the basic spec, there is a "click to agree" license button on the web page which our legal team told us not to click.
They missed the simplicity part. But they did at least spec something that did not use interrupts.
OF was not picked at least in part because they did not want to dilute ACPI.
Eric
On Wed, 2004-02-04 at 14:31, Stefan Reinauer wrote:
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.
Digressing slightly, please note that Etherboot is more than just the drivers - there is a significant amount of network code (now even TCP if one wants it), and it would benefit us all to share as much as possible; there is, for instance, an NFS client already.
For some reason best known to themselves, the GRUB developers decided to use only Etherboot's drivers and brew their own network code. The result is that GRUB netboot is now lagging noticeably behind Etherboot in functionality, drivers etc - GRUB people now discuss "porting" Etherboot drivers, which is disappointing (have a look at the GRUB support forum and FAQ to see how little help there is on the network code compared to disk and fs). It would have made far more sense to co-operate on an open firmware network API, but hey ho... I'd like to see this happening fairly soon, so that any driver created for Etherboot immediately works with GRUB. So I encourage OpenBIOS to peacefully co-exist with GRUB and Etherboot rather than fork which is not a good way to encourage driver writers.
BTW, there is work now on implementing PXE on top of Etherboot - pxelinux has already been demonstrated on top of Etherboot. This may force the issue somewhat, since even if PXE isn't the API one wants, it will at least help focus people into deciding what APIs they *do* want.
Peter Lister prl@peterlister.co.uk writes:
On Wed, 2004-02-04 at 14:31, Stefan Reinauer wrote:
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.
Digressing slightly, please note that Etherboot is more than just the drivers - there is a significant amount of network code (now even TCP if one wants it), and it would benefit us all to share as much as possible; there is, for instance, an NFS client already.
Regardless the etherboot driver model and the open firmware driver model are essentially the same. (Independently derived though). The big difference is I believe OF drivers can have multiple cards working at once.
For some reason best known to themselves, the GRUB developers decided to use only Etherboot's drivers and brew their own network code. The result is that GRUB netboot is now lagging noticeably behind Etherboot in functionality, drivers etc - GRUB people now discuss "porting" Etherboot drivers, which is disappointing (have a look at the GRUB support forum and FAQ to see how little help there is on the network code compared to disk and fs). It would have made far more sense to co-operate on an open firmware network API, but hey ho... I'd like to see this happening fairly soon, so that any driver created for Etherboot immediately works with GRUB. So I encourage OpenBIOS to peacefully co-exist with GRUB and Etherboot rather than fork which is not a good way to encourage driver writers.
After seeing the GRUB code the amazing part is that it works. The problem is totally GRUB, the etherboot core is much more powerful. Some pieces of GRUB at the periphery are OK, like the FS drivers but the rest is not even worth thinking about. There is a reason GRUB has never been ported to run under LinuxBIOS.
BTW, there is work now on implementing PXE on top of Etherboot - pxelinux has already been demonstrated on top of Etherboot. This may force the issue somewhat, since even if PXE isn't the API one wants, it will at least help focus people into deciding what APIs they *do* want.
I've already implemented the API I do want. Open source and no callbacks.
Eric
-
ebiederman＠lnxi.com -
Kevin O'Connor -
Peter Lister -
ron minnich -
Stefan Reinauer -
Tarl Neustaedter