FW authentication questions regarding Apollo Lake chromebooks

[coolstar]

Hi, I have an Apollo lake Chromebook and had a few questions with SOF

According to the docs, they say that Apollo Lake is supported but it requires a BIOS change. What changes are required in the BIOS for this to work? I have a custom coreboot + tianocore firmware loaded on my Apollo lake Chromebook already (and don’t boot chrome os on there), so if the BIOS change could be documented or upstreamed into coreboot that would be great to get audio working with SOF (it seems audio does work on geminilake already with the same coreboot tree).

[MrChromebox]

ditto. I'm not seeing any differences between APL and GLK Chromebooks firmware-wise on the audio side, so clarification on what needs to be changed would be appreciated

[marc-hb]

According to the docs, they say...

Which docs, this one? https://thesofproject.github.io/latest/platforms/intel-cavs/apollolake/index.html

This section is a bit confusing, ~chromebooks never require any BIOS change~ (only Chromebooks after some date), I mean at least not for authentication reasons. Switching to developer mode is enough, all chromebooks (EDIT: after some date) ship with the community key: https://thesofproject.github.io/latest/getting_started/intel_debug/introduction.html#chromebooks-and-sof

See confirmation in https://github.com/thesofproject/sof-docs/pull/379

Please submit doc fixes to https://github.com/thesofproject/sof-docs , thanks!

I'm not seeing any differences between APL and GLK Chromebooks firmware-wise on the audio side

Indeed, check the symbolic links in https://github.com/thesofproject/sof-bin/tree/main/v2.0.x/sof-v2.0 (cloning may make that easier). They're created by https://github.com/thesofproject/sof/blob/main/installer/GNUmakefile where you can find this:

target_of_glk := apl

[plbossart]

@coolstar @MrChromebox the issue is the CSME keys used for the SOF firmware authentication. ApolloLake Chromebooks rely on the Intel production key - which means an SOF firmware that you compile yourself would simply be rejected during the boot time. Starting with GeminiLake the key used changed, and you CAN generate the SOF firmware yourself as long as you have access to the Tensilica tools, put the device in developer mode and remove the write protection.

I did test SOF some 3 years ago on ApolloLake, but we had to find devices where we could update coreBoot with the Servo board. It failed on all devices past a specific production milestone, I have exactly ONE device that I could configure with SOF. It's also impossible to update that key with a regular update.

Bottom line: ApolloLake Chromebooks, despite using the same audio DSP as GeminiLake, will not support SOF. It is what it is, there's nothing we can do about it.

[MrChromebox]

ok, so same issue as SKL/KBL then =(

[plbossart]

ok, so same issue as SKL/KBL then =(

yes indeed.

[coolstar]

@plbossart just wondering, is it possible to update the key with a custom coreboot (even if an external flasher is required to write over the ME region), or are Apollo Lake chromebooks SOL when it comes to SOF?

[marc-hb]

@cujomalainey , in the docs you helped review recently we have:

As stated above, starting from 2019/2020, Intel Chromeboooks have been configured with the community key.

Could we add more specific product references there? It would obviously help answer the questions here. Thanks!

[marc-hb]

(even if an external flasher is required to write over the ME region)

Note merely adding a key does AFAIK not require replacing any firmware code. However I'm not familiar with the flash layout so I unfortunately don't know which region(s) it requires to overwrite (if possible)

This looks relevant: https://www.chromium.org/chromium-os/firmware-porting-guide/2-concepts/

[plbossart]

@plbossart just wondering, is it possible to update the key with a custom coreboot (even if an external flasher is required to write over the ME region), or are Apollo Lake chromebooks SOL when it comes to SOF?

I don't fully recall the details but there was something fused or preventing updates at or after the DVT1 hw prototype stage. In other words none of the actual products can be updated.

[marc-hb]

Starting with GeminiLake [...] as long as you have access to the Tensilica tools,

For non-performance sensitive testing you can use the free, crosstool-ng-based toolchain: https://thesofproject.github.io/latest/introduction/index.html?highlight=toolchain#toolchain-faq Don't release binaries compiled with it.

All binaries released in https://github.com/thesofproject/sof-bin are compiled with XCC.

[cujomalainey]

@plbossart just wondering, is it possible to update the key with a custom coreboot (even if an external flasher is required to write over the ME region), or are Apollo Lake chromebooks SOL when it comes to SOF?

I don't fully recall the details but there was something fused or preventing updates at or after the DVT1 hw prototype stage. In other words none of the actual products can be updated.

I am pretty sure if you disable RO FW write protect you can still get in there and change the key. How to do that is a completely different question as I am not a coreboot guy. Also note the many warnings you will see if you venture down that path.

@cujomalainey , in the docs you helped review recently we have:

As stated above, starting from 2019/2020, Intel Chromeboooks have been configured with the community key.

Could we add more specific product references there? It would obviously help answer the questions here. Thanks!

GLK/CML/TGL/JSL/ADL and all following intel chips are signed with the community key. IIRC BYT/CHT/BDW can also run unsigned FW. There is just that gap of APL/SKL/KBL/AML/HSW that can't be switched over easily. Any AMD/MTK platform supported here will also have the community keys. This is again specific to chromebooks.

[plbossart]

I am pretty sure if you disable RO FW write protect you can still get in there and change the key. How to do that is a completely different question as I am not a coreboot guy. Also note the many warnings you will see if you venture down that path.

@cujomalainey you are very optimistic on this one. I tried with the support of the Intel team and the Google team (Dylan, Duncan et. al) and did not succeed except on the 'Elektro' device which was pre-production hardware. The same process failed on all other devices. It would take master hacker skills to make this work without any formal support.

[cujomalainey]

I am pretty sure if you disable RO FW write protect you can still get in there and change the key. How to do that is a completely different question as I am not a coreboot guy. Also note the many warnings you will see if you venture down that path.

@cujomalainey you are very optimistic on this one. I tried with the support of the Intel team and the Google team (Dylan, Duncan et. al) and did not succeed except on the 'Elektro' device which was pre-production hardware. The same process failed on all other devices. It would take master hacker skills to make this work without any formal support.

I don't doubt, I have yet to see anything happen easily in that space. And this would be a high risk activity too, even with servod/ccd

[MrChromebox]

Q: Since APL Chromebooks can load, and SoF provides as part of sof-bin, the intel-signed firmware for Apollolake, why can't that be used instead? Seems others have gotten that to work by disabling route checking on the bxt-da7219-max98357a driver (ref: https://github.com/EMLommers/Apollolake_Audio/)

[plbossart]

@MrChromebox I think this should work indeed, I didn't realize we had signed versions for APL. The SOF driver would need to be selected manually with 'options snd-intel-dspconfig dsp_driver=3' since 'officially' Intel does not support this product configuration.

I am not sure why a machine driver change would be needed though, the same topology/machine driver is used for GLK and should work as is. I'd be curious to get logs with and without this .disable_route_check setting.

Here's what I used at the time for the UCM file: https://github.com/plbossart/UCM/tree/master/sof-bxtda7219max. It's loosely based on the Chrome version.

BTW I just realized we're both located in ATX, small world :-)

[MrChromebox]

@plbossart small world indeed :)

I just tested a 5.16.9 mainline kernel with snd-intel-dspconfig dsp_driver=3' and get the following:

[    3.151290] da7219 i2c-DLGS7219:00: Using default DAI clk names: da7219-dai-wclk, da7219-dai-bclk
[    3.497627] sof-audio-pci-intel-apl 0000:00:0e.0: DSP detected with PCI class/subclass/prog-if 0x040100
[    3.865307] sof-audio-pci-intel-apl 0000:00:0e.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[    3.913398] sof-audio-pci-intel-apl 0000:00:0e.0: use msi interrupt mode
[    3.959218] sof-audio-pci-intel-apl 0000:00:0e.0: hda codecs found, mask 4
[    3.967466] sof-audio-pci-intel-apl 0000:00:0e.0: Firmware info: version 2:0:0-b678a
[    3.967478] sof-audio-pci-intel-apl 0000:00:0e.0: Firmware: ABI 3:20:0 Kernel ABI 3:18:0
[    3.967482] sof-audio-pci-intel-apl 0000:00:0e.0: warn: FW ABI is more recent than kernel
[    3.967495] sof-audio-pci-intel-apl 0000:00:0e.0: unknown sof_ext_man header type 3 size 0x30
[    4.017054] sof-audio-pci-intel-apl 0000:00:0e.0: Firmware info: version 2:0:0-b678a
[    4.017065] sof-audio-pci-intel-apl 0000:00:0e.0: Firmware: ABI 3:20:0 Kernel ABI 3:18:0
[    4.017069] sof-audio-pci-intel-apl 0000:00:0e.0: warn: FW ABI is more recent than kernel
[    4.203061] sof-audio-pci-intel-apl 0000:00:0e.0: Topology: ABI 3:20:0 Kernel ABI 3:18:0
[    4.203075] sof-audio-pci-intel-apl 0000:00:0e.0: warn: topology ABI is more recent than kernel
[    4.203686] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: Parent card not yet available, widget card binding deferred
[    4.211725] da7219 i2c-DLGS7219:00: supply VDD not found, using dummy regulator
[    4.211824] da7219 i2c-DLGS7219:00: supply VDDMIC not found, using dummy regulator
[    4.211839] da7219 i2c-DLGS7219:00: supply VDDIO not found, using dummy regulator
[    4.211863] da7219 i2c-DLGS7219:00: Invalid VDDIO voltage
[    4.224496] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: sink widget DMic overwritten
[    4.224516] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: no source widget found for iDisp3 Tx
[    4.224518] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: Failed to add route iDisp3 Tx -> direct -> hifi3
[    4.224522] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: no sink widget found for iDisp3 Tx
[    4.224524] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: Failed to add route iDisp3_out -> direct -> iDisp3 Tx
[    4.224529] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: no source widget found for iDisp2 Tx
[    4.224531] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: Failed to add route iDisp2 Tx -> direct -> hifi2
[    4.224535] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: no sink widget found for iDisp2 Tx
[    4.224537] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: Failed to add route iDisp2_out -> direct -> iDisp2 Tx
[    4.224542] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: no source widget found for iDisp1 Tx
[    4.224544] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: Failed to add route iDisp1 Tx -> direct -> hifi1
[    4.224549] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: no sink widget found for iDisp1 Tx
[    4.224551] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: Failed to add route iDisp1_out -> direct -> iDisp1 Tx
[    4.224559] bxt_da7219_max98357a bxt_da7219_mx98357a: snd_soc_bind_card: snd_soc_dapm_add_routes failed: -19

I get the same output (and non-functional audio) with the .disable_route_check added. I believe I had to copy the signed apl firmware over the community to get it to load still.

[plbossart]

[ 4.224496] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: sink widget DMic overwritten

I think this one is harmless, though maybe @ranj063 can help clarify what this means.

[ 4.224516] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: no source widget found for iDisp3 Tx [ 4.224518] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: Failed to add route iDisp3 Tx -> direct -> hifi3 [ 4.224522] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: no sink widget found for iDisp3 Tx [ 4.224524] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: Failed to add route iDisp3_out -> direct -> iDisp3 Tx [ 4.224529] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: no source widget found for iDisp2 Tx [ 4.224531] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: Failed to add route iDisp2 Tx -> direct -> hifi2 [ 4.224535] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: no sink widget found for iDisp2 Tx [ 4.224537] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: Failed to add route iDisp2_out -> direct -> iDisp2 Tx [ 4.224542] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: no source widget found for iDisp1 Tx [ 4.224544] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: Failed to add route iDisp1 Tx -> direct -> hifi1 [ 4.224549] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: no sink widget found for iDisp1 Tx [ 4.224551] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: Failed to add route iDisp1_out -> direct -> iDisp1 Tx

Humm, I think I faced that problem before. I can't recall what I had to do, it could be as bad as commenting out the DAPM routes. I'll look into this.

I get the same output (and non-functional audio) with the .disable_route_check added. I believe I had to copy the signed apl firmware over the community to get it to load still.

Yes, for Google we default to the community key on all platforms. You can work around that by using

options snd-sof-pci fw_path="intel/sof"

[plbossart]

Humm, I think we didn't update the topology, there's a difference compared to the GLK version. I think we need to use this to remove the errors on widgets we don't care about.

diff --git a/tools/topology/topology1/sof-apl-da7219.m4 b/tools/topology/topology1/sof-apl-da7219.m4
index 5ce3ea8f0..08a45e894 100644
--- a/tools/topology/topology1/sof-apl-da7219.m4
+++ b/tools/topology/topology1/sof-apl-da7219.m4
@@ -194,6 +194,9 @@ DAI_CONFIG(HDA, 5, 5, iDisp3,
 VIRTUAL_WIDGET(ssp5 Tx, out_drv, 0)
 VIRTUAL_WIDGET(ssp1 Rx, out_drv, 1)
 VIRTUAL_WIDGET(ssp1 Tx, out_drv, 2)
+VIRTUAL_WIDGET(iDisp3 Tx, out_drv, 15)
+VIRTUAL_WIDGET(iDisp2 Tx, out_drv, 16)
+VIRTUAL_WIDGET(iDisp1 Tx, out_drv, 17)
 VIRTUAL_WIDGET(DMIC01 Rx, out_drv, 3)
 VIRTUAL_WIDGET(DMic, out_drv, 4)
 VIRTUAL_WIDGET(dmic01_hifi, out_drv, 5)

[ranj063]

[ 4.224496] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: sink widget DMic overwritten

I think this one is harmless, though maybe @ranj063 can help clarify what this means.

[ 4.224516] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: no source widget found for iDisp3 Tx [ 4.224518] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: Failed to add route iDisp3 Tx -> direct -> hifi3 [ 4.224522] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: no sink widget found for iDisp3 Tx [ 4.224524] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: Failed to add route iDisp3_out -> direct -> iDisp3 Tx [ 4.224529] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: no source widget found for iDisp2 Tx [ 4.224531] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: Failed to add route iDisp2 Tx -> direct -> hifi2 [ 4.224535] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: no sink widget found for iDisp2 Tx [ 4.224537] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: Failed to add route iDisp2_out -> direct -> iDisp2 Tx [ 4.224542] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: no source widget found for iDisp1 Tx [ 4.224544] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: Failed to add route iDisp1 Tx -> direct -> hifi1 [ 4.224549] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: no sink widget found for iDisp1 Tx [ 4.224551] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: Failed to add route iDisp1_out -> direct -> iDisp1 Tx

Humm, I think I faced that problem before. I can't recall what I had to do, it could be as bad as commenting out the DAPM routes. I'll look into this. @plbossart all of the above are because of incorrect virtual widgets in the topology. We need to remove the "DMiC" virtual widget and add virtual widgets for each of the ones missing above.

[plbossart]

@ranj063 GLK still have the DMIC widgets? Are they not needed?

VIRTUAL_WIDGET(DMIC01 Rx, out_drv, 3)
VIRTUAL_WIDGET(DMic, out_drv, 4)
VIRTUAL_WIDGET(dmic01_hifi, out_drv, 5)

[plbossart]

@MrChromebox Can you try this topology? it needs to replace the existing one in /lib/firmware/sof-tplg (edit: need to unzip it)

sof-apl-da7219.tplg.gz

[ranj063]

@ranj063 GLK still have the DMIC widgets? Are they not needed? VIRTUAL_WIDGET(DMic, out_drv, 4)

I think this one's not needed but the other two are

[MrChromebox]

@MrChromebox Can you try this topology? it needs to replace the existing one in /lib/firmware/sof-tplg (edit: need to unzip it)

sof-apl-da7219.tplg.gz

that fixes it, although the audio output is listed as Headphones (vs internal speakers). I'll need to find a pair of wired headphones to test JD/HP output

[MrChromebox]

Yes, for Google we default to the community key on all platforms. You can work around that by using

options snd-sof-pci fw_path="intel/sof"

possible to default to that if SMBIOS bios-vendor is 'coreboot' (and system-manufacturer is 'Google')? That would cover APL Chromebooks running my upstream coreboot firmware

[MrChromebox]

one additional note - the volume control seems to be a bit off - it scales from 0-10%, but 11-100 is constant. So 10% is full volume (and quite loud)

[plbossart]

possible to default to that if SMBIOS bios-vendor is 'coreboot' (and system-manufacturer is 'Google')? That would cover APL Chromebooks running my upstream coreboot firmware

this is the DMI quirk in sound/soc/sof/sof-pci-dev.c that changes the fw_path and adds the community prefix.

static const struct dmi_system_id community_key_platforms[] = {
    {
        .ident = "Up boards",
        .matches = {
            DMI_MATCH(DMI_SYS_VENDOR, "AAEON"),
        }
    },
    {
        .ident = "Google Chromebooks",
        .matches = {
            DMI_MATCH(DMI_SYS_VENDOR, "Google"),
        }
    },
    {},
};

we'd want a quirk that works only for APL but only for Chromebooks. not sure how to go about this.

[cujomalainey]

@MrChromebox you could pass a boot parameter to change the path from your firmware to the driver.

[MrChromebox]

@cujomalainey yup that's easy enough, was just wondering if there were a way to work around via a DMI quirk. Sadly most Chromebook users wanting to run Linux are not terribly experienced and asking them to add a kernel boot param can be challenging at times =D

[cujomalainey]

I mean you could pass straight from your AP build, no need to add alsa-conf options. No user intervention needed. Although why you need it is a bit fuzzy since it appears like this bug might warrant a fix that will be released as part of the basic build and the signing on APL should be the same as Windows so you should be able use the default paths.

[ellyq]

Hello everyone :)

Board: reef/snappy (HP Chromebook X360 11 G1 EE) OS: Fedora 35 w/mainline (5.17-rc5) Firmware: alsa-sof-firmware from fedora repos (/lib/firmware/intel/sof/) Topology posted by @plbossart Additional kernel commandline: snd-intel-dspcfg.dsp_driver=3 loglevel=4 snd_sof_pci.fw_path="intel/sof"

[   37.663651] sof-audio-pci-intel-apl 0000:00:0e.0: DSP detected with PCI class/subclass/prog-if 0x040100
[   37.664916] sof-audio-pci-intel-apl 0000:00:0e.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[   37.670749] sof-audio-pci-intel-apl 0000:00:0e.0: use msi interrupt mode
[   37.709619] sof-audio-pci-intel-apl 0000:00:0e.0: hda codecs found, mask 4
[   37.716195] sof-audio-pci-intel-apl 0000:00:0e.0: Firmware info: version 1:9:3-a9780
[   37.716206] sof-audio-pci-intel-apl 0000:00:0e.0: Firmware: ABI 3:20:0 Kernel ABI 3:18:0
[   37.716210] sof-audio-pci-intel-apl 0000:00:0e.0: warn: FW ABI is more recent than kernel
[   37.716245] sof-audio-pci-intel-apl 0000:00:0e.0: unknown sof_ext_man header type 3 size 0x30
[   37.765641] sof-audio-pci-intel-apl 0000:00:0e.0: Firmware info: version 1:9:3-a9780
[   37.765652] sof-audio-pci-intel-apl 0000:00:0e.0: Firmware: ABI 3:20:0 Kernel ABI 3:18:0
[   37.765655] sof-audio-pci-intel-apl 0000:00:0e.0: warn: FW ABI is more recent than kernel
[   38.082427] sof-audio-pci-intel-apl 0000:00:0e.0: Topology: ABI 3:20:1 Kernel ABI 3:18:0
[   38.082440] sof-audio-pci-intel-apl 0000:00:0e.0: warn: topology ABI is more recent than kernel
[   38.082851] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: Parent card not yet available, widget card binding deferred
[   38.094804] da7219 i2c-DLGS7219:00: supply VDD not found, using dummy regulator
[   38.094913] da7219 i2c-DLGS7219:00: supply VDDMIC not found, using dummy regulator
[   38.096133] da7219 i2c-DLGS7219:00: supply VDDIO not found, using dummy regulator
[   38.096182] da7219 i2c-DLGS7219:00: Invalid VDDIO voltage
[   38.127849] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: sink widget DMic overwritten
[   38.128599] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: source widget Capture overwritten
[   38.145248] input: sof-bxtda7219max Headset Jack as /devices/pci0000:00/0000:00:0e.0/bxt_da7219_mx98357a/sound/card0/input10
[   38.145659] input: sof-bxtda7219max HDMI/DP,pcm=5 as /devices/pci0000:00/0000:00:0e.0/bxt_da7219_mx98357a/sound/card0/input11
[   38.146081] input: sof-bxtda7219max HDMI/DP,pcm=6 as /devices/pci0000:00/0000:00:0e.0/bxt_da7219_mx98357a/sound/card0/input12
[   38.146483] input: sof-bxtda7219max HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:0e.0/bxt_da7219_mx98357a/sound/card0/input13

Tested 3 and 4-pole jack, detection did not work (posted video in #apollolake-testing on chultrabook server).

[MrChromebox]

@cujomalainey not sure what you mean by AP build here. And there are at least 5 issues distinct issues that I'm seeing here with APL Chromebooks:

• need to force use of SOF driver (via options snd-intel-dspconfig dsp_driver=3)
• need to use intel-signed APL DSP firmware (via options snd-sof-pci fw_path="intel/sof")
• need for fixed topology (as provided above)
• need to fix volume scaling (yet unresolved)
• need to fix headphone jack detection (yet unresolved)

[coolstar]

I’m noticing similar volume scaling issues on Skylake/Kaby Lake with max98357a in Windows (not using SOF and not on Apollo lake) but it’s the same Maxim Amp chip

I’m wondering if it might be the gain GPIO on the max98357a chip but there doesn’t seem to be a way to configure it from coreboot or from a driver

(my max98357a driver is using reverse engineered Intel SST driver api implementation [Intel Windows folks mind sending me headers/docs pls?] but I don’t see anything that suggests a gain parameter to SST)

I can do some testing on Apollo Lake later today both with SOF and with writing direct to I2S from the AP and see if I can repro the volume issues there

[cujomalainey]

So depthcharge can pass additional parameters to the kernel if you using it. So you can pass these parameters to the driver like this https://chromium-review.googlesource.com/c/chromiumos/platform/depthcharge/+/2623109

We didnt end up using this method but it might be something you are interested in.

[MrChromebox]

@cujomalainey ok that's what I thought you meant; my upstream coreboot builds don't use depthcharge, only Tianocore/edk2

[coolstar]

@MrChromebox @cujomalainey yeah edk2 by default can't pass params and I'm not sure how users would take to it if we baked rEFInd in with kernel parameters (which still only would work with EFISTUB linux kernels)

[plbossart]

I looked back at the work from 2019, and I don't think jack detection ever worked.

the UCM file has this:

Value { PlaybackPCM "hw:sofbxtda7219max,0" MixerName "Headphone" JackName "sofbxtda7219max Headset Jack" JackType "gpio" JackSwitch "2" OutputDspName "" }

and that seems to be a set of Chrome-specific UCM extensions that were never upstreamed to alsa-utils.

I have no idea what the MixerName is,and a JackType.

@cujomalainey I know there was an intent to upstream UCM files, is this still on your radar?

[plbossart]

@MrChromebox any instructions to install your setup? I think my device is no longer write protected, since I installed a different kernel with SOF back in 2018-2019, but I never used the legacy boot - Chrome only.

[cujomalainey]

@plbossart unfortunately all my UCM cleanup projects have been ignored since dgreid left. Been too busy since until last week I was the only audio member in MTV. Would love to continue but got much more important fish to fry first.

Also note the snippet is very old. I deprecated JackName, JackType, and MixerName out of our repo to use upstream equivalents.

This is what ToT looks like now.

SectionDevice."Mic".0 {
        Value {
                CapturePCM "hw:bxtda7219max,1"
                CaptureMixerElem "Headset Mic"
                JackDev "bxtda7219max Headset Jack"
        }
        EnableSequence [
                cdev "hw:bxtda7219max"
                cset "name='Headset Mic Switch' on"
                cset "name='media0_out mo codec0_in mi Switch' on"
                cset "name='Mic Switch' on"
        ]
        DisableSequence [
                cdev "hw:bxtda7219max"
                cset "name='Headset Mic Switch' off"
                cset "name='media0_out mo codec0_in mi Switch' off"
                cset "name='Mic Switch' off"
        ]
}

Also this is in a private code base and I have no clue why. I have been asking another team who is working with the code right now to move it public which is where it should be.

[plbossart]

@MrChromebox Tentative autodetection for APL added in https://github.com/thesofproject/linux/pull/3453. Compile-tested only, and not the most elegant code in the world. I just didn't see an alternative.

[plbossart]

SectionDevice."Mic".0 {
        Value {
                CapturePCM "hw:bxtda7219max,1"
                CaptureMixerElem "Headset Mic"
                JackDev "bxtda7219max Headset Jack"
        }
        EnableSequence [
                cdev "hw:bxtda7219max"
                cset "name='Headset Mic Switch' on"
                cset "name='media0_out mo codec0_in mi Switch' on"
                cset "name='Mic Switch' on"
        ]
        DisableSequence [
                cdev "hw:bxtda7219max"
                cset "name='Headset Mic Switch' off"
                cset "name='media0_out mo codec0_in mi Switch' off"
                cset "name='Mic Switch' off"
        ]
}

Also this is in a private code base and I have no clue why. I have been asking another team who is working with the code right now to move it public which is where it should be.

we could really have a single UCM file, @perexg added support for conditional setting of a control, and the only difference between SOF and SST drivers is that this type of mixers don't exist for SOF...Even the card name can be auto-populated.

cset "name='media0_out mo codec0_in mi Switch' on"

[coolstar]

Testing on whitetip (Apollo Lake) in Manjaro with SOF, I can confirm working speakers here, but I notice the same volume scaling issue where 6% is 100% (odd it's the same issue I see in Windows on Skylake without SOF -- I guess max98357a is the common thing here)

Jack detection appears to be broken as well, and the speakers show up as "Headphones" but otherwise sound is indeed working

[MrChromebox]

@MrChromebox any instructions to install your setup? I think my device is no longer write protected, since I installed a different kernel with SOF back in 2018-2019, but I never used the legacy boot - Chrome only.

I've currently only officially released RW_LEGACY firmware (w/SeaBIOS) for APL, which can be flashed via my CrOS Firmware Utility Script (from ChromeOS or Linux) at https://mrchromebox.tech/#fwscript

I'm prepping to release upstream coreboot + UEFI firmware for all APL/GLK devices coinciding with the next coreboot release (4.16), but can provide you a link to test now - just shoot me an email @ mrchromebox at gmail and include the CrOS board name / HWID so I can ensure the correct build.

[cujomalainey]

@coolstar check that the jack name in the ucm matches the name under the evtest tool. I know the kernel changed the names at some point which our kernel uprev teams keep hitting

SectionDevice."Mic".0 {
        Value {
                CapturePCM "hw:bxtda7219max,1"
                CaptureMixerElem "Headset Mic"
                JackDev "bxtda7219max Headset Jack"
        }
        EnableSequence [
                cdev "hw:bxtda7219max"
                cset "name='Headset Mic Switch' on"
                cset "name='media0_out mo codec0_in mi Switch' on"
                cset "name='Mic Switch' on"
        ]
        DisableSequence [
                cdev "hw:bxtda7219max"
                cset "name='Headset Mic Switch' off"
                cset "name='media0_out mo codec0_in mi Switch' off"
                cset "name='Mic Switch' off"
        ]
}

Also this is in a private code base and I have no clue why. I have been asking another team who is working with the code right now to move it public which is where it should be.

we could really have a single UCM file, @perexg added support for conditional setting of a control, and the only difference between SOF and SST drivers is that this type of mixers don't exist for SOF...Even the card name can be auto-populated.

cset "name='media0_out mo codec0_in mi Switch' on"

@plbossart you have no idea how much I want to refactor our UCMs to use that so we can stop duplicating the UCMs all over our overlays....

[marc-hb]

you have no idea how much I want to refactor our UCMs to use that so we can stop duplicating the UCMs all over our overlays....

Good old copy/paste/diverge? I don't know about UCM specifically but in general any configuration "language" that does not implement some basic "code re-use" feature should be... banned? At the very least some include feature. Imagine a new programming language without function calls. Everyone would laugh at that but for some reason it's widely accepted for configuration files, they're not important enough... until it hurts. https://www.google.com/search?q=configuration+as+code

/off-topic rant sorry.

[plbossart]

include the CrOS board name / HWID so I can ensure the correct build.

I am so bad I can't even recall how to get this information. DMI decode tells me the serial number is 123456789 :-)

[MrChromebox]

I am so bad I can't even recall how to get this information. DMI decode tells me the serial number is 123456789 :-)

from CrOS? sudo crossystem hwid - board name is part pre-hyphen

[plbossart]

I am so bad I can't even recall how to get this information. DMI decode tells me the serial number is 123456789 :-)

from CrOS? sudo crossystem hwid - board name is part pre-hyphen

that gives me "REEF TEST 3240", no hyphen

[MrChromebox]

that gives me "REEF TEST 3240", no hyphen

ok, that means it's running a firmware image that doesn't have any device-specific info added (likely extracted from a recovery image and manually flashed). Is it an Acer Spin 11 or Asus Chromebook 213?

[plbossart]

that gives me "REEF TEST 3240", no hyphen

ok, that means it's running a firmware image that doesn't have any device-specific info added (likely extracted from a recovery image and manually flashed). Is it an Acer Spin 11 or Asus Chromebook 213?

it's an Acer pre-production prototype, no specific labels or versions.

[cujomalainey]

dmidecode should also give you some information on the board name.

you have no idea how much I want to refactor our UCMs to use that so we can stop duplicating the UCMs all over our overlays....

Good old copy/paste/diverge? I don't know about UCM specifically but in general any configuration "language" that does not implement some basic "code re-use" feature should be... banned? At the very least some include feature. Imagine a new programming language without function calls. Everyone would laugh at that but for some reason it's widely accepted for configuration files, they're not important enough... until it hurts. https://www.google.com/search?q=configuration+as+code

/off-topic rant sorry.

@marc-hb ALSA has it, ChromeOS just never adopted it, I was working on it till we had a re-org last year