Re: [Fwd: Re: OpenFirmware and interrupt-map]

[Stefan Reinauer]

* Tarl Neustaedter  [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