[ re-send, hopefully having fixed subscription issues ]
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.
If it saves us several engineer-years in development, that's good.
The one problem with using Linux so far has been size constraints.
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.
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.
I'll be [very] interested in this.
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.
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.
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.
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.
Regards, Tarl Neustaedter, CST Firmware, Sun Microsystems
On Tue, 3 Feb 2004, Tarl Neustaedter wrote:
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.
You've just described the entire case for linuxbios we started with years ago :-)
So I am very happy to see it might make some sense :-)
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.
ow. ow. ow. Not with Infiniband, at least not yet ...
Is the price difference really that big?
ron
ron minnich rminnich@lanl.gov writes:
On Tue, 3 Feb 2004, Tarl Neustaedter wrote:
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.
ow. ow. ow. Not with Infiniband, at least not yet ...
I can believe that reflects anything but the poor quality of the IB stack and IB drivers.
Rom how big are the drivers you are using. And how big is that with compression?
Is the price difference really that big?
It is difficult to obtain larger than 1 megabyte. 2 Megabyte parts are advertised but they are difficult to get. And multiple parts lead to more complexity.
Eric
* Eric W. Biederman ebiederman@lnxi.com [040204 03:47]:
Is the price difference really that big?
It is difficult to obtain larger than 1 megabyte. 2 Megabyte parts are advertised but they are difficult to get. And multiple parts lead to more complexity.
Not to talk about the problems we've seen with some 8MBit parts..
Best regards, Stefan Reinauer
I am told that the big consumers of flash parts are MP3 players. The market there demands ever bigger parts. This was the reason why in 1999 we hoped that FLASH parts would grow.
The big "make flash grow" driver in the PC world is the desire to for DRM in the bios. So we may still get those big BIOS parts, for reasons we don't like.
ron
On 3 Feb 2004, Eric W. Biederman wrote:
Rom how big are the drivers you are using. And how big is that with compression?
Old data, from last year, showed our mvapi drivers on a mellanox blade system at several Mbytes.
It is difficult to obtain larger than 1 megabyte. 2 Megabyte parts are advertised but they are difficult to get.
cell phones, mpeg players :-)
ron
ron minnich wrote:
[...] Better if we can fit it in a 1MB prom, however.
ow. ow. ow. Not with Infiniband, at least not yet ...
Is the price difference really that big?
The issue is usually one of part availability and square millimeters. On the SPARC platforms, we've usually gotten larger proms than PCs would have, but it's been a struggle with the hardware team every time - we (firmware) always want more code space, the hardware team al. With the Opteron-based systems, there is a good chance we'll be using LPC-type parts, and nobody is bothering to manufacture large PROMs in that technology yet.
As for infiniband drivers, I lead the team which wrote the OpenFirmware drivers for sun, and they aren't that large. FCode is a *very* compact programming language. To give you an idea, the driver for the HCA is 35K, the driver for SRP (disk over infiniband) is 16K (both values are compressed, but with old-fashioned "compress"). The IPoIB driver was added as an integral part of the obptftp driver, and that's 20K total.
I don't have comparable information about the Linux binaries yet. We have Solaris drivers we wrote in-house, but they are tied into SVR4's streams and Sun's DDI interfaces, and not easily portable to Linux. We are likely to use an external vendor's Linux drivers, and I'll probably know their sizes fairly soon - giving me my first pass at feasability numbers.
[ Stefan Reinauer, on divergence of vendor's OpenFirmware ]
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)
Yah. We're continuing the write these kinds of documents (e.g., I wrote the IEEE 1275/Infiniband binding), but we no longer really have a forum in which to share them between companies. The last one I wrote that got published was the 1394 (Firewire) binding, which was several years ago. There had been interest expressed by from HP and IBM in the infiniband bindings, but it's been years since I heard any further - and nowadays I'd probably have to check with Sun Legal before exporting such a document. Sigh.
We haven't written an IEEE-1275/Hypertransport binding, largely because we haven't had HT on a SPARC. The Opteron stuff is quite recent (I recall we announced the alliance with AMD last november), and not all the implications have finished dribbling through our engineering organizations.
Tarl Neustaedter Tarl.Neustaedter@sun.com writes:
[ re-send, hopefully having fixed subscription issues ]
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.
If it saves us several engineer-years in development, that's good.
Sounds right. There is still some development needed to get the core kernel nice and tight. And in cases like Infiniband someone needs to write some good drivers...
The one problem with using Linux so far has been size constraints.
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.
1MB should be doable. Look at the 2.6 kernel tiny patch it really helps get the size down. My target is something usable in 512KB. For sake of doing calculations figure LinuxBIOS takes 128K (with two copies) in the rom chip.
Look at the MTD drivers for flashing the prom.
Look at kexec for loading a new kernel.
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.
I'll be [very] interested in this.
See above for the pieces I have found so far. I am in the middle of bringing up a board so I don't know what kind of time frame I really have to work with on the bootloader stuff.
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.
Yes the secrecy aspect of the video card manufacturers how to cope and then how to over come it is one of our more interesting hurdles.
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.
Ouch. Although it is good to see that so many people actually played with open firmware.
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.
Right. Usually video card vendors leave off the little bit to actually turn on their cards out of the Linux drivers so any little driver that gets the thing working is enough for the linux drivers to take it the rest of the way.
Eric
-
ebiederman＠lnxi.com -
ron minnich -
Stefan Reinauer -
Tarl Neustaedter