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