Opened 5 years ago

Closed 5 years ago

Last modified 21 months ago

#11311 closed defect (fixed)

Secure boot makes Linux audio unusable on XO-1

Reported by: greenfeld Owned by: wmb@…
Priority: high Milestone:
Component: ofw - open firmware Version: not specified
Keywords: Cc: dsd, Quozl
Blocked By: Blocking:
Deployments affected: Action Needed: test in build
Verified: no


  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.

Attachments (1)

dmesg (19.2 KB) - added by greenfeld 5 years ago.
Boot dmesg log with failed audio initialization

Download all attachments as: .zip

Change History (15)

Changed 5 years ago by greenfeld

Boot dmesg log with failed audio initialization

comment:1 Changed 5 years ago by greenfeld

  • Summary changed from Secure boot make Linux audio unusable on XO-1 to Secure boot makes Linux audio unusable on XO-1

comment:2 Changed 5 years ago by dsd

  • Milestone changed from Not Triaged to 11.3.0
  • Owner changed from saadia to dsd

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

comment:3 Changed 5 years ago by dsd

  • Component changed from kernel to ofw - open firmware

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

comment:4 Changed 5 years ago by dsd

  • Cc dsd added
  • Owner changed from dsd to wmb@…

Mitch, please see diagnosis/bisection above.

comment:5 Changed 5 years ago by 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.

comment:6 Changed 5 years ago by 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?

comment:7 Changed 5 years ago by wmb@…

  • Action Needed changed from diagnose to add to release

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

comment:8 Changed 5 years ago by dsd

  • Cc Quozl added

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

comment:9 Changed 5 years ago by Quozl

Q2E47 released, containing this fix.

comment:10 Changed 5 years ago by dsd

  • Action Needed changed from add to release to add to build

Thanks a lot, looks good!

comment:11 Changed 5 years ago by dsd

  • Action Needed changed from add to build to test in build

test in 11.3.0 candidate build 881

comment:12 Changed 5 years ago by godiard

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

comment:13 Changed 5 years ago by wmb@…

  • Resolution set to fixed
  • Status changed from new to closed

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

comment:14 Changed 21 months ago by Quozl

  • Milestone 11.3.0 deleted

Milestone 11.3.0 deleted

Note: See TracTickets for help on using tickets.