Re: OpenFirmware and interrupt-map

[Stefan Reinauer]

CCing the OpenBIOS mailinglist.

* Eric W. Biederman  [040203 20:07]:
> Tarl Neustaedter  writes:
> > Eric W. Biederman wrote:
> > > Tarl Neustaedter  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