No sound using test image.

[Dave Mielke]

I have a Pixelbook Go, and have built a test image for it (using atlas for the
board name). After installing that test iamge, sound no longer works (neither
when booting it from USB nor after installing it to the disk). My need for
working sound is more than most as I'm blind and, without sound, can't navigate
the screen via speech.

Listing /dev/snd/ showed that only the seq and timer files had been created,
and /var/log/messages said:

ALSA device list:
No soundcards found.

lspci shows this for the soundcard:

Multimedia audio controller: Intel Corporation Device 9d71 (rev 21)
Subsystem: Intel Corporation Device 7270 Flags: bus master, fast devsel, latency 64, IRQ 16
Memory at d153c000 (64-bit, non-prefetchable) [size=16K]
Memory at d1520000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [50] Power Management version 3
Capabilities: [60] MSI: Enable- Count=1/1 Maskable- 64bit+
Kernel driver in use: snd_soc_skl
Kernel modules: snd_hda_intel, snd_soc_skl

Some searching led to discussion on missing ALSA topology firmware files. This
was confirmed by dmesg output saying that a number of direct firmware loads
failed because the corresponding files couldn't be found. Installing the
missing files seems to have made progress, but sound is still not working.

Listing /dev/snd/ now shows a proper set of files, but /var/log/messages still
says that no soundcards can be found.

The lspci output (above) includes this line:

Kernel modules: snd_hda_intel, snd_soc_skl

lsmod shows that snd_soc_skl is loaded but that snd_hda_itnel isn't. Perhaps
these lines from dmesg are related:

snd_soc_skl 0000:00:1f.3: bound 0000:00:02.0 (ops 0xffffffffbb089c30) HDMI HDA Codec ehdaudio0D2: Max dais supported: 3
snd_soc_skl 0000:00:1f.3: ASoC: old version of manifest
snd_soc_skl 0000:00:1f.3: ASoC: Parent card not yet available,Do not add new widgets now ~

And then there are these snd_soc_skl errors:

snd_soc_skl 0000:00:1f.3: Module list is empty
snd_soc_skl 0000:00:1f.3: ipc FW reply: 121 FW Error Code: 0
snd_soc_skl 0000:00:1f.3: ipc: set large config fail, err: -22
snd_soc_skl 0000:00:1f.3: ASoC: PRE_PMU: spk_pb_in cpr 0 event failed: -22
snd_soc_skl 0000:00:1f.3: ipc: Unhandled error msg=9b0a0000
snd_soc_skl 0000:00:1f.3: ipc: set pipeline state failed, err: -110
snd_soc_skl 0000:00:1f.3: Failed to pause pipe
snd_soc_skl 0000:00:1f.3: ipc: delete pipeline failed, err -110
snd_soc_skl 0000:00:1f.3: Failed to delete pipeline

There's another mystery, which may be something else entirely, but I'll mention
it here just in case. dmesg shows two firmware files that can't be loaded
because they're apparently not there even though they absolutely are in
/lib/firmware. Here's the dmesg output for that:

i915 0000:00:02.0: Direct firmware load for i915/kbl_huc_ver02_00_1810.bin failed with error -2
[drm] Failed to fetch valid uC firmware from i915/kbl_huc_ver02_00_1810.bin (error -2)
i915 0000:00:02.0: Direct firmware load for i915/kbl_guc_ver9_39.bin failed with error -2
[drm] Failed to fetch valid uC firmware from i915/kbl_guc_ver9_39.bin (error -2)
[drm:intel_huc_init_hw] *ERROR* Failed to complete HuC uCode load with ret -5
[drm:intel_uc_init_hw] *ERROR* GuC init failed
[drm] Initialized i915 1.6.0 20160411 for 0000:00:02.0 on minor 0
[drm] Initialized vgem 1.0.0 20120112 on minor 1

I'd appreciate it if someone can suggest how I should proceed.

--
I believe the Bible to be the very Word of God: http://Mielke.cc/bible/
Dave Mielke | 2213 Fox Crescent | WebHome: http://Mielke.cc/
EMail: Da...@Mielke.cc | Ottawa, Ontario | Twitter: @Dave_Mielke
Phone: +1 613 726 0014 | Canada K2A 1H7 |

[Mike Frysinger]

in the past, this was because we failed to move firmware from the private overlays to the public ones.  i know this was (is?) a problem for eve (pixelbook).  hopefully Dylan or Cheng-Yi will know the current state there.

-mike

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
https://groups.google.com/a/chromium.org/group/chromium-os-dev

[Cheng-yi Chiang]

Hi Dave,

Thanks for letting us know the issue.

This is tracked internally with Intel at issue b/155804429.

Hi Ben,

We should bring this up with Intel in the meeting to get their help on this issue.

Thanks!

[ggg]

On Monday, November 16, 2020 at 1:56:34 AM UTC Cheng-Yi Chiang wrote:

Hi Dave,

Thanks for letting us know the issue.

This is tracked internally with Intel at issue b/155804429.

I filed that bug in May, 2020. :/

The problem is the Google HW team choose to include proprietary audio processing ("Waves") in the audio processing pipeline and the binary distribution agreement does not allow chromium.org to distribute those binaries. :(  Some "clean up" is required to remove "Waves" references from files used in the public chromium.org builds.

Alternatively, you could extract the necessary binaries from the official Chrome OS builds and include those in your own chromium.builds.

Sorry, I don't have a list of the specific files other than through the errors that you saw regarding huc/guc files.

cheers,

grant

[Dave Mielke]

[quoted lines by ggg on 2020/11/16 at 18:42 -0800]

>The problem is the Google HW team choose to include proprietary audio
>processing ("Waves") in the audio processing pipeline and the binary
>distribution agreement does not allow chromium.org to distribute those
>binaries. :( Some "clean up" is required to remove "Waves" references from
>files used in the public chromium.org builds.

I did get and add dsp_lib_waves_spt_release.bin. Wouldn't that be adequate, or
does this file reference other things that aren't there?

>Alternatively, you could extract the necessary binaries from the official
>Chrome OS builds and include those in your own chromium.builds.
>
>Sorry, I don't have a list of the specific files other than through the
>errors that you saw regarding huc/guc files.

I'd appreciate an explanation regarding those error messages. Even though the
log says that the guc/huc files are missing, the files themselves are actually
there. Why would that be? Would replacing them with copies from an official
Chrome build fix that?

[Grant Grundler]

On Tue, Nov 17, 2020 at 5:27 PM Dave Mielke <dave.a...@gmail.com> wrote:

[quoted lines by ggg on 2020/11/16 at 18:42 -0800]

>The problem is the Google HW team choose to include proprietary audio
>processing ("Waves") in the audio processing pipeline and the binary
>distribution agreement does not allow chromium.org to distribute those
>binaries. :(  Some "clean up" is required to remove "Waves" references from
>files used in the public chromium.org builds.

I did get and add dsp_lib_waves_spt_release.bin. Wouldn't that be adequate, or
does this file reference other things that aren't there?

Sorry, I don't know offhand.

BTW, let me correct a previous statement I made: We have permission to distribute FW binary files provided by Maxim.

You might look at similar work done to enable audio on "eve" (2017 Pixelbook):

   https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1848859

   https://chromium-review.googlesource.com/c/chromiumos/overlays/board-overlays/+/1850209

Looking at these again, I'm realizing that applying the same changes to atlas builds is not quite enough to get audio working on atlas: an "updated topology config file" is still needed.

>Alternatively, you could extract the necessary binaries from the official
>Chrome OS builds and include those in your own chromium.builds.
>
>Sorry, I don't have a list of the specific files other than through the
>errors that you saw regarding huc/guc files.

I'd appreciate an explanation regarding those error messages. Even though the
log says that the guc/huc files are missing, the files themselves are actually
there. Why would that be? Would replacing them with copies from an official
Chrome build fix that?

My advice is to at least compare the files you have with the ones in a signed Chrome OS build.

Sorry, I can't explain the error messages (lack of technical knowledge, not any permissions).

cheers,

grant

[Dave Mielke]

There's a factory reset process for these devices, right? Does that mean that
the original /lib/firmware/ is there in some recovery partition? If so, is it
possible for me to get at it?

[Grant Grundler]

On Tue, Nov 17, 2020 at 7:35 PM Dave Mielke <dave.a...@gmail.com> wrote:

There's a factory reset process for these devices, right?

Yes. We have two methods:

1) "power wash": securely wipes all user data - "same as from the factory". (kernel boot and root partitions are untouched)

2) "USB recovery": rewrites the content of the boot and root partitions and creates a new "stateful" partition.

Does that mean that
the original /lib/firmware/ is there in some recovery partition?

Not on the chromebook. Recovery is a separate USB image:

    https://support.google.com/chromebook/answer/1080595?hl=en

 

If so, is it possible for me to get at it?

Yes. Follow recovery steps and go back into developer mode. Or figure out how to unpack the recovery image.

cheers,

grant

[Dave Mielke]

[quoted lines by Grant Grundler on 2020/11/17 at 18:36 +0000]

>Looking at these again, I'm realizing that applying the same changes to
>atlas builds is not quite enough to get audio working on atlas: an "updated
>topology config file" is still needed.

To confirm my understanding: Do you mean that one of the firmware files needs
to be regenerated (presumably with alsatplg) after updating its corresponding
configuration file?

Which one, and do we know what updates need to be made to it?

[Grant Grundler]

On Tue, Nov 17, 2020 at 10:45 PM Dave Mielke <dave.a...@gmail.com> wrote:

[quoted lines by Grant Grundler on 2020/11/17 at 18:36 +0000]

>Looking at these again, I'm realizing that applying the same changes to
>atlas builds is not quite enough to get audio working on atlas: an "updated
>topology config file" is still needed.

To confirm my understanding: Do you mean that one of the firmware files needs
to be regenerated (presumably with alsatplg) after updating its corresponding
configuration file?

I don't think so. Looking at the eve changes I posted earlier, just changes the topology conf file. But I'm not certain of that.

 

Which one,

The one not present in the public build under overlays/overlay-atlas/media-libs/lpe-support-topology.

I'll point out most other public builds also do not have "media-libs/lpe-support-topology" in their public build. I'm assuming audio is working for those (or at least most of those) platforms. And I can't explain what changed to require this file now. Someone from the audio team would have to explain this.

 

and do we know what updates need to be made to it?

Sorry, I don't - otherwise it would have been done already.

cheers,

grant

[Dave Mielke]

[quoted lines by Ben Zhang on 2020/11/19 at 02:55 -0500]

>The list of all audio related firmware, topology and parameters on Atlas is
>below. Attached is a zip of these files in their installed paths taken from
>the current Atlas stable release image R86 13421.99.0. Hope this makes things
>easier.

It sure did! Thank you very much! Sound is now working.

The GUC and HUC i915 files are still not loading. The error is -2 (so ENOENT),
which is very odd. They're in the root file system so it can't be that the file
system they're in hasn't been mounted yet.

There's actually one file still missing, but I didn't mention it here because I
think it has to do with WiFi. Since WiFi is working well enough, maybe it
doesn't matter. That file is iwl-debug-yoyo.bin.