* Tarl Neustaedter Tarl.Neustaedter@sun.com [040204 01:05]:
Interesting. The observation that powerful firmware eventually becomes an OS so you might as well use an OS, seems true :)
One benefit we're hoping for is to not have to write multiple drivers every time we go to a new technology (e.g., infiniband). Right now, we're facing the possibility of needing to write a Solaris driver, a Linux driver, an IEEE-1275 FCode driver, and a real-mode BIOS driver. All for one technology, and with the probability of having to repeat for the next i/o technology to come along, since we are going forward with both SPARC and Opteron-based systems.
With LinuxBIOS, it looks like it should be possible to re-use the Linux driver in the PROM. If so, it would mean that a new platform based on a particular i/o technology could contain the drivers for that particular technology (e.g., for Infiniband, IPoIB and SRP drivers), and not have to worry about option ROMs.
Infiniband is a technology that you won't find on expansion cards iirc, so it makes sense to include support in the firmware. But is the setup work you do in firmware really the same as what an operating system driver does?
Many device option roms do a completely different job than the appropriate os device driver. As for graphics adapters, there is initialization code in the option rom, that initializes the onboard memory, sets an initial mode and allows some output. You won't get 3d acceleration on firmware level. OTOH, you won't get lowlevel initialization in most drivers.
I haven't seen any sun opteron hardware, but it seems that this hardware could, from the os level, be handled very similar to the current sparc hardware when using a combination of LinuxBIOS and OpenBIOS. IEEE 1275 provides a good layer of abstraction while still having the powerful and open LinuxBIOS base that lets you reuse drivers and such.
I can believe it. My task right now is to determine if LinuxBIOS is feasible, and if so, at what size. We have some flexibility in that we design our own boards, so if we can justify a large PROM, we could get it in. Better if we can fit it in a 1MB prom, however.
Opteron systems need a lot more complex initialization than most other x86(-like) systems, but with 1MB / 8MBit you won't run into flash rom limits except adding lots of additional code.
A Sun video card comes with an OpenFirmware driver. That means that Sun has either designed and built the card itself, or has signed a deal with a vendor to re-sell their video cards after writing a driver and putting it on the option ROM. The usual arrangement is that this driver is still intellectual property of the video card vendor, so that he can maintain secrecy on how to use his card. Don't know why.
This reminds me a lot of the discussion I have had with vendors when talking about getting initialization code for LinuxBIOS/OpenBIOS.
To some extent, cards can be moved between Suns, Apples, IBM PowerPC platforms and some HP systems, all of which use the IEEE 1275 standard. Each implementation has slightly diverged from each other, and now that the 1275 committee isn't meeting any more, quirks are tending cause further divergence.
With Hypertransport, Infiniband and other technologies, there might awake some demand for new supplements. Competing with EFI, Open Firmware should have at least recommendations on how to cope with this divergence (which is a natural fact looking at the number of contributors)
Note that an openfirmware video driver isn't particularly feature-rich. It primarily provides a dumb scrolling ascii text window. There are definitions for fancier capabilities (cursor positioning, color, character insertion), but I've never seen anyone use them - or even know if these capabilities work in our drivers.
Are you talking about the CHRP Linear Frame Buffer Display Device Binding and the Recommended Practices for 16 Colors and 8bit Framebuffers?
Best regards, Stefan Reinauer