The most likely cause is the phrase "0 4 my-w!" in dev/geode/ac97/ac97.fth:unmap-regs .

That has the effect of turning off the decoding for the audio registers that otherwise appear in PCI memory space.

Arguably, the Linux driver should turn on the register decoding for its device. It's a general OFW policy to leave devices in the non-decoding state when they are not in use.

In this case, we could violate that rule if necessary, but I'd like to understand whether or not the Linux driver could be changed to ensure that its registers are being decoded.

The argument for OFW's "off unless used" policy is based on the fact that some PCI devices have multiple "windows" onto the same set of internal registers, and by enabling only the one that the driver is going to use, the risk of spurious access through the other one is minimized.

Removing that line does indeed work around the problem. But, like you, I'd prefer to fix this properly.

I'm not having much luck here though. In both the working and failure case, at the point of the audio driver probe routine, the PCI_COMMAND byte reads 0x41. The driver does try to enable bus mastering by writing 0x45, however upon reading immediately after, the value is still 0x41 in both the success and failure case.

I used "lspci -vvvxxx" to dump the configuration space between working and failure cases after booting into Linux, there is no difference in the output.

Also, based on your diagnosis I was expecting to be able to reproduce the failure in unsecure mode with:

The Geode chipset doesn't really have PCI config registers. They are emulated in firmware via a System Management Interrupt (which is not always used) and in Linux by spoofing PCI configuration cycles.

Fixing that Linux emulation is too risky, so we will just leave the device turned on. Fixed by svn 2585

If possible, same as q2e46 (r2393) but with this specific fix added. And if I'm not asking too much, packaged as bootfw with the old olpc.fth (instead of olpc-firmware, which we'll gladly switch to later).