Device Configuration by ACPI

I just got a bug report for the Intel AC97 audio driver that i wrote a while ago. Bummer, but let's investigate what goes wrong.

Someone bought a shiny new Asus notebook, and noticed that he gets no sound. Installing the driver debug version thats available from BeBits, he created a debugging log file, which reveals these details:

MMBAR = 0
MBBAR = 0
INTR_LN = 0xff
INTR_PN = 0x02
IRQ not assigned to pin 2
ERROR: memory mapped IO not configured

You know what this means? The sound chipset resources are not configured, memory addresses are not assigned to the BARs (base address register), and the interrupt line is also not assigned (0xff or 0 means not assigned). The driver can't do these assignments, its the responsibility of computer BIOS and operating system. The driver can only do one thing: return B_ERROR and exit.

The important thing is: This is a notebook. Notebooks need to preserve power, and thus most notebook BIOS only enable the few devices that are needed for booting, like video card and harddisk controller. Most other devices are not touched, and not even configured. They need to be configured by the operating system.

Some BIOS have a setting like "PNP OS installed" which can be set to "no" or "disabled", indicating that a dumb OS is installed. Then all devices will be configured by the BIOS. This is available on many desktop motherboard, but almost never on notebooks.

On Notebooks, exclusivlely ACPI is used. ACPI means Advanced Configuration and Power Interface, and is available since spring 2001 in almost every desktop computer and notebook system. It's a specification that describes how the operating system can query which hardware is installed, and allows to configure them and assign resources. Some older systems can be configured by chipset specific PCI functions, but ACPI is better and doesn't depend on proprietary vendor specifications.

Unfortunately, BeOS and also Zeta is based on a design that is slightly older than 2001, and has neither PCI chipset specific, nor ACPI based device configuration implemented. If the motherboard doesn't have a "PNP OS installed" = "no" option, chances are that many devices like sound chipset, USB controller, network or TV cards won't work.

This is bad, very bad. Not only for the user, but also for us "your f***ing driver doesn't work here" driver writers.

DVB driver development, some thoughts

This is no introduction about how to do driver development. Just a short intro showing that you usually don't write one in a single day, and about the progress of the DVB driver.

On windows, we can use Tortoise SVN to manage SVN sourcecode repositories. Especially the history view is convenient, it also allows to select arbitrary versions, to check them out or compare them. Using a good revision control system is always a helpful idea. Whatever you did to your working copy, you can revert it to the last version with a simple command.

The DVB-T driver is still not finished, for example automatic tuning is still missing, but so far it's fairly complete. I made a image of the history of this driver available for those who are curious.

As you can see, I worked on it on 26 days during the last 8 month. A have no accourate number about the hours spend for development, but I'm fairly sure that it was better than spending them watching TV, or surfing in the internet. What are you doing right now?

Assuming a average of 5 hours each day, this means 130 hours kernel driver development. But I'm sure I spend much more time on it, I just didn't always do a SVN checkin. 180 to 200 hours, including the needed research, seems proper to me. This is still not including the time spend on the userspace things, like the demultiplexing and decoding media add-on, or the TV application.

The driver is still not published. I'm not sure if I'll ever publish it. The majority of the BeOS community doesn't want to pay for drivers. But cconsidering all the work spend on it, giving it away for free seems to be a stupid idea.