Secure boot makes Linux audio unusable on XO-1

[greenfeld]

1. Start an XO-1 with os880 installed & the "ak" tag set but the "X" button held down for secure mode ("X" and checkmark also can be used).
2. The audio driver will fail to initialize and ALSA will have no devices.

This definitely happens on reboots, but may also happen if you just boot the XO in secure mode.

Seen with os880 (dsd pre-release version), Q2E46 on SHC93004B6F.

[greenfeld]

Boot dmesg log with failed audio initialization

[dsd]

Reproduced. This is a regression caused by firmware Q2E46, and does not reproduce with Q2E45.

[dsd]

Reproduced on svn head (r2584).

Bisecting tracked this down to r2072 being the cause: "close audio device after playing startup sound so subsequent test /audio works right (resets the sample rate)" (#10521).

It is strange how the problem only appears in the secure boot path, not unsecure mode.

While looking at this I am reminded of a similar XO-1 issue that was fixed in r880. That commit might be a good memory-jogger for XO-1 audio related stuff (or perhaps its unrelated).

[dsd]

Mitch, please see diagnosis/bisection above.

[wmb@…]

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.

[dsd]

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:

select /audio
unmap-regs boot

However this booted up with working audio.

Any further ideas? Could something else be at play?

[wmb@…]

Okay, so there is an elephant in the closet.

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

[dsd]

James, could we please have a new XO-1 release?

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).

[Quozl]

Q2E47 released, containing this fix.

[dsd]

Thanks a lot, looks good!

[dsd]

test in 11.3.0 candidate build 881

[godiard]

Tested in os881, with activities Speak and Pippy, "speaker-test -t sine" and "gst-launch audiotestsrc ! audio/x-raw-int,rate=4800 ! alsasink"

[wmb@…]

I take the last comment to mean that it was tested with success.