[STABLE-v2.2] topology1: sof-hda-generic: support BT offload pipelines

[brentlu]

Add new pipelines to sof-hda-generic.m4 to support BT audio offload on SSP2 and also add an new topology sof-hda-generic-4ch-bt.tplg with BT audio offload enabled.

[brentlu]

Linux PR to support this topology: thesofproject/linux#5123

[plbossart]

stable-v2.2 is supposed to be, well, stable. It's not typically where we add new features.

And then there's the question of distributing those changes, I don't see how we can support a new feature and add it to sof-bin, given that this will break ALL platforms until users have the modified machine driver available.

There's also the risk of breaking stuff with more resources being used, on firmware that's only updated for major issues.

[brentlu]

stable-v2.2 is supposed to be, well, stable. It's not typically where we add new features.

And then there's the question of distributing those changes, I don't see how we can support a new feature and add it to sof-bin, given that this will break ALL platforms until users have the modified machine driver available.

There's also the risk of breaking stuff with more resources being used, on firmware that's only updated for major issues.

I agree we shouldn't add new feature to a stable branch but our difficulty is that ODMs are continuing developing new RPL/ADL-N/TWL Chromebooks with cavs2.5 branch.

This patch adds two new topologies, sof-hda-generic-2ch-bt-ssp2.tplg and sof-hda-generic-4ch-bt-ssp2.tplg, to make file without changing existing ones. So if user is using old machine driver, it will load existing topology (sof-hda-generic-2ch.tplg or sof-hda-generic-4ch.tplg) and ignore new BT offload topologies.

The two new topologies come with dynamic pipeline enabled so I think resource may not be a problem. I have tested them on a RPL Chromebook and the BT offload function is working good.

[marc-hb]

And then there's the question of distributing those changes, I don't see how we can support a new feature and add it to sof-bin,

I agree we shouldn't add new feature to a stable branch but our difficulty is that ODMs are continuing developing new RPL/ADL-N/TWL Chromebooks with cavs2.5 branch.

AFAIK Chromebooks don't use sof-bin releases "as is", so that should help. @andyross, @cujomalainey confirm?

[marc-hb]

without changing existing ones.

As of your commit 1901c59, this is true only BT_OFFLOAD is false everywhere else. Even if correct now, this could change in the future.

You're trying not to change existing topologies but you are changing two existing and common files.

BTW why is sof-hda-generic-idisp.m4 also changing? This commit does not seem to use it...

[marc-hb]

I don't remember seeing this "error code: 0x2c (error: signature verification failed)" in this configuration ever before:

https://sof-ci.01.org/sofpr/PR9336/build6765/devicetest/index.html?model=TGLU_SKU0A32_SDCA-ipc3&testcase=verify-kernel-boot-log

EDIT: root-caused to

• [BUG] rimage + openssl3 is broken in the stable-v2.2 and cavs25 branches, always have been #9340

Jul 29 03:46:55 jf-tglu-sku0a32-sdca-01 kernel: snd_sof_intel_hda_common:cl_dsp_init: sof-audio-pci-intel-tgl 0000:00:1f.3: FW Poll Status: reg[0xd4]=0x80000000 successful
Jul 29 03:46:55 jf-tglu-sku0a32-sdca-01 kernel: snd_sof_intel_hda_common:cl_dsp_init: sof-audio-pci-intel-tgl 0000:00:1f.3: FW Poll Status: reg[0x80000]=0x5000001 successful
Jul 29 03:46:55 jf-tglu-sku0a32-sdca-01 kernel: snd_sof_intel_hda_common:hda_cl_copy_fw: sof-audio-pci-intel-tgl 0000:00:1f.3: Code loader DMA starting
Jul 29 03:46:55 jf-tglu-sku0a32-sdca-01 kernel: snd_sof_intel_hda_common:hda_cl_copy_fw: sof-audio-pci-intel-tgl 0000:00:1f.3: waiting for FW_ENTERED status
Jul 29 03:46:55 jf-tglu-sku0a32-sdca-01 kernel: ax88179_178a 4-1.2:1.0 eth0: register 'ax88179_178a' at usb-0000:00:14.0-1.2, ASIX AX88179 USB 3.0 Gigabit Ethernet, 00:0e:c6:82:cb:ee
Jul 29 03:46:55 jf-tglu-sku0a32-sdca-01 kernel: usbcore: registered new interface driver ax88179_178a
Jul 29 03:46:55 jf-tglu-sku0a32-sdca-01 kernel: ax88179_178a 4-1.2:1.0 enx000ec682cbee: renamed from eth0
Jul 29 03:46:55 jf-tglu-sku0a32-sdca-01 kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_TZ.ETMD], AE_NOT_FOUND (20240322/psargs-330)
Jul 29 03:46:55 jf-tglu-sku0a32-sdca-01 kernel: ACPI Error: Aborting method \_SB.IETM._OSC due to previous error (AE_NOT_FOUND) (20240322/psparse-529)
Jul 29 03:46:58 jf-tglu-sku0a32-sdca-01 kernel: snd_sof_intel_hda_common:hda_cl_copy_fw: sof-audio-pci-intel-tgl 0000:00:1f.3: FW Poll Status: reg[0x80000]=0x80000012 timedout
Jul 29 03:46:58 jf-tglu-sku0a32-sdca-01 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: hda_cl_copy_fw: timeout with rom_status_reg (0x80000) read
Jul 29 03:46:58 jf-tglu-sku0a32-sdca-01 kernel: snd_sof_intel_hda_common:hda_dsp_stream_trigger: sof-audio-pci-intel-tgl 0000:00:1f.3: FW Poll Status: reg[0x160]=0x140000 successful
Jul 29 03:46:58 jf-tglu-sku0a32-sdca-01 kernel: snd_sof_intel_hda_common:hda_cl_copy_fw: sof-audio-pci-intel-tgl 0000:00:1f.3: Code loader DMA stopped
Jul 29 03:46:58 jf-tglu-sku0a32-sdca-01 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: ------------[ DSP dump start ]------------
Jul 29 03:46:58 jf-tglu-sku0a32-sdca-01 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware download failed
Jul 29 03:46:58 jf-tglu-sku0a32-sdca-01 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: fw_state: SOF_FW_BOOT_IN_PROGRESS (3)
Jul 29 03:46:58 jf-tglu-sku0a32-sdca-01 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: 0x80000012: module: ROM, state: CSE_VALIDATE_IMAGE_REQUEST, not running
Jul 29 03:46:58 jf-tglu-sku0a32-sdca-01 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: error code: 0x2c (error: signature verification failed)
Jul 29 03:46:58 jf-tglu-sku0a32-sdca-01 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: extended rom status:  0x80000012 0x2c 0x0 0x0 0x0 0x0 0x25101c2 0x0
Jul 29 03:46:58 jf-tglu-sku0a32-sdca-01 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: ------------[ DSP dump end ]------------
Jul 29 03:46:58 jf-tglu-sku0a32-sdca-01 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: Failed to start DSP
Jul 29 03:46:58 jf-tglu-sku0a32-sdca-01 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: error: failed to boot DSP firmware -110
Jul 29 03:46:58 jf-tglu-sku0a32-sdca-01 kernel: snd_sof:sof_set_fw_state: sof-audio-pci-intel-tgl 0000:00:1f.3: fw_state change: 3 -> 4
Jul 29 03:46:58 jf-tglu-sku0a32-sdca-01 kernel: soundwire_intel:intel_resume_child_device: rt711-sdca sdw:0:0:025d:0711:01: skipping device, never detected on bus
Jul 29 03:46:58 jf-tglu-sku0a32-sdca-01 kernel: soundwire_intel:intel_resume_child_device: rt1316-sdca sdw:0:1:025d:1316:01: skipping device, never detected on bus

[marc-hb]

SOFCI TEST

[cujomalainey]

And then there's the question of distributing those changes, I don't see how we can support a new feature and add it to sof-bin,

I agree we shouldn't add new feature to a stable branch but our difficulty is that ODMs are continuing developing new RPL/ADL-N/TWL Chromebooks with cavs2.5 branch.

AFAIK Chromebooks don't use sof-bin releases "as is", so that should help. @andyross, @cujomalainey confirm?

correct, we pull the branch and build ourselves

[marc-hb]

Firmware failed to load again in https://sof-ci.01.org/sofpr/PR9336/build6786/devicetest/index.html?model=TGLU_SKU0A32_SDCA-ipc3&testcase=verify-kernel-boot-log, this time on jf-tglu-sku0a32-sdca-02.

This failure did not happen in latest daily 44369 and did not happen in your recent https://sof-ci.01.org/linuxpr/PR5123/build4200/devicetest/index.html and it did not happen in https://sof-ci.01.org/softestpr/PR546/build707/devicetest/index.html either.

So this PR seems to blame. Yet I built before and after it and I only found two new topologies and no change to existing topologies... so how is this failure possible? Very confused.

Linux PR to support this topology: thesofproject/linux#5123

Does this mean 5123 is a required dependency? How so?

[brentlu]

without changing existing ones.

As of your commit 1901c59, this is true only BT_OFFLOAD is false everywhere else. Even if correct now, this could change in the future.

You're trying not to change existing topologies but you are changing two existing and common files.

BTW why is sof-hda-generic-idisp.m4 also changing? This commit does not seem to use it...

It not true of false, it's defined or not defined. If BT_OFFLOAD is not defined, intel-generic-bt.m4 will not be included.

The reason to change sof-hda-generic-idisp.m4 is to support topologies like sof-hda-generic-idisp-Xch-bt-sspY.m4 if needed.

[marc-hb]

If BT_OFFLOAD is not defined, intel-generic-bt.m4 will not be included.

and my question is: how do you make sure this does not happen in the future?

[marc-hb]

I don't remember seeing this "error code: 0x2c (error: signature verification failed)" in this configuration ever before:

I just reproduced on a different TGL device with a clean, v2.2.10 checkout. I think we just entered the rimage / CSE twilight zone. I will keep testing and file a new issue.

[brentlu]

Firmware failed to load again in https://sof-ci.01.org/sofpr/PR9336/build6786/devicetest/index.html?model=TGLU_SKU0A32_SDCA-ipc3&testcase=verify-kernel-boot-log, this time on jf-tglu-sku0a32-sdca-02.

This failure did not happen in latest daily 44369 and did not happen in your recent https://sof-ci.01.org/linuxpr/PR5123/build4200/devicetest/index.html and it did not happen in https://sof-ci.01.org/softestpr/PR546/build707/devicetest/index.html either.

So this PR seems to blame. Yet I built before and after it and I only found two new topologies and no change to existing topologies... so how is this failure possible? Very confused.

Linux PR to support this topology: thesofproject/linux#5123

Does this mean 5123 is a required dependency? How so?

This happens to me also. Once I upgraded my toolchain for MTL FW, I couldn't generate a valid FW image for platforms using stable-v2.2 so now I have two build machines, one for MTL and the other one for ADL/TGL/JSL. My best guess is signing tool/process is not backward compatible due to toolchain upgrade. Once you upgraded to MTL, you could not sign old FW correctly.

FW loading comes before topology loading and this commit only changes topology so I think this commit is not related to FW signing error.

[plbossart]

"Once I upgraded my toolchain for MTL FW, I couldn't generate a valid FW image for platforms using stable-v2.2"

Oh that's not good at all. scripts should hide any sort of dependency on tools. Having two build machines should not be a requirement.

we just had a similar weird problem on a Lenovo device, where with the same kernel different firmware releases work or don't work... see #9339. this issue seems to be solved by taking latest firmware and latest kernel, but something's definitively fishy on signing/authentication.

@lgirdwood @kv2019i FYI.

[plbossart]

@brentlu can we clarify one point: are you trying to enable BT_OFFLOAD for Chromebooks based on HDaudio, or the generic Linux devices?

I don't have any issues on Chromebooks, because the release of kernel+firmware is coupled. I don't see how we can update generic Linux devices since we can't control how topology and machine driver changes are picked by distributions.

If you are trying to enable BT_OFFLOAD for HDaudio-based Chromebooks, then we should use a different target in a Chrome-specific directory to avoid polluting the rest of the platforms.

The machine driver changes can be done independently, it's ok if we create a link that is not used by the topology. The other way around will be a topology load failure, we can't have this happen.

[ujfalusi]

BT offload is tied to DMIC? Why? Can we have BT offload with non DMIC setups?

[plbossart]

and can we have 2ch+bt-ssp2? or 2ch-pdm1-bt-ssp1?

If it's only for Chromebooks then by default it's 4ch always and Chrome discards channels, but for generic Linux this is becoming unmanageable.

[ujfalusi]

@marc-hb, @plbossart, the installed firmware on tglu-sku0a32-sdca is strange for sure.
The 202403/06 release have these:

# md5sum /lib/firmware/intel/sof/intel-signed/sof-tgl.ri     
bc9d7a6ee8efff7318d608192155c061  /lib/firmware/intel/sof/intel-signed/sof-tgl.ri
# md5sum /lib/firmware/intel/sof/community/sof-tgl.ri 
25a6b8c2201ac4da9fedb0bc2d06f487  /lib/firmware/intel/sof/community/sof-tgl.ri

on the device:

md5sum /lib/firmware/intel/sof/sof-tgl.ri
745a2277d1329697482e7877a7185b6d  /lib/firmware/intel/sof/sof-tgl.ri

ls -al /lib/firmware/intel/sof/community/sof-tgl.ri 
lrwxrwxrwx 1 root root 34 Jul 30 05:59 /lib/firmware/intel/sof/community/sof-tgl.ri -> /lib/firmware/intel/sof/sof-tgl.ri

It is supposed to be the community keyed firmware, but it is not matching with the release version for sure.

[marc-hb]

I just reproduced on a different TGL device with a clean, v2.2.10 checkout. I think we just entered the rimage / CSE twilight zone. I will keep testing and file a new issue.

I found a way to git bisect this and we have been missing a critical openssl3 fix in the stable-v2.2 branch since forever, see all details in brand new issue #9340 that I filed so we can stop polluting this unrelated BT offload pull request.

(I still have no idea why some SOF commits boot without that openssl3 fix while others don't)

Once I upgraded my toolchain for MTL FW, I couldn't generate a valid FW image for platforms using stable-v2.2 so now I have two build machines, one for MTL and the other one for ADL/TGL/JSL. My best guess is signing tool/process is not backward compatible due to toolchain upgrade

It is possible that some toolchains generate binaries that trigger the bug more easily than others. In any case, please try cherry-pick the rimage fix and confirm that this fixes all toolchains. Hopefully you can then go back to a single build machine :-)

[brentlu]

@brentlu can we clarify one point: are you trying to enable BT_OFFLOAD for Chromebooks based on HDaudio, or the generic Linux devices?

I don't have any issues on Chromebooks, because the release of kernel+firmware is coupled. I don't see how we can update generic Linux devices since we can't control how topology and machine driver changes are picked by distributions.

If you are trying to enable BT_OFFLOAD for HDaudio-based Chromebooks, then we should use a different target in a Chrome-specific directory to avoid polluting the rest of the platforms.

The machine driver changes can be done independently, it's ok if we create a link that is not used by the topology. The other way around will be a topology load failure, we can't have this happen.

Now I understand it will be unmanageable if we just enable it for generic Linux. And the enabling should be based on distribution since there are several software components involves like BT stack, audio server, and SOF driver/tplg. So this PR would be focusing on HDA-based Chromebooks. I removed unrelated config.

I also updated Linux PR by removing topology name fixup for BT offload and let OSV to decide which topology they want. So generic Linux could keep using existing topology without being affected.

[plbossart]

So this PR would be focusing on HDA-based Chromebooks.

The Linux kernel side relies on NHLT to detect the presence of the BT link. Is this supported on CHrome? I always thought Chrome didn't have any NHLT? @cujomalainey can you chime in?

[cujomalainey]

So this PR would be focusing on HDA-based Chromebooks.

The Linux kernel side relies on NHLT to detect the presence of the BT link. Is this supported on CHrome? I always thought Chrome didn't have any NHLT? @cujomalainey can you chime in?

AFAIK we still use tplg for DAI config, in tplg2 its just an NHLT blob baked into the tplg from what I have seen. We don't use any NHLT from coreboot. @andyross to confirm my observations.

[andyross]

Yeah, ChromeOS devices don't have an NHLT ACPI table per se (at least ones I've looked at directly, I wouldn't be shocked if some have leaked into firmware somewhere). The kernel gets the NHLT via the topology file, where it's specified as the private data buffer in (IIRC) the manifest record. It's defined via alsaconf out of topology2. (I'm still ignorant about how that interacts with/overrides the older dapm/backend data in the same .tplg file, FWIW).

[brentlu]

So far I test the driver/tplg on brox by adding module option 'bt_link_mask' to /etc/modprobe.d/alsa-brox.conf. HDA driver also needs 'dmic_num' module option to fixup topology file name on Chromebooks.

# Use the SOF driver for PCI_DEVICE(0x8086, 0x54c8) instead of snd_hda_intel
options snd_intel_dspcfg dsp_driver=3
# Disable runtime suspend temporarily to fix jack detection
options snd-sof-pci sof_pci_debug=0x01
options snd_sof_intel_hda_common hda_model=alc-headset-jack
options snd_sof_intel_hda_common always_enable_dmi_l1=1
options snd_sof_intel_hda_common dmic_num=2
options snd_sof_intel_hda_common bt_link_mask=4
blacklist snd_hda_intel

[plbossart]

The topology file only contains the NHLT blobs for DMICs and SSP, not the full NHLT that describes the endpoints. So Chromebooks cannot really figure out how many mics are present and BT offload is also not detectable from platform firmware.

I am fine with the detection of BT offload from NHLT and the additions in the machine driver, but it's a strong NO on all the topology file suffix additions (with BT, with dmics, etc). Chromebooks, or people wanting to experiment on Linux, can set the topology filename with a kernel parameter to select this new BT-offload-capable HDA topology.

We don't want to break existing HDAudio user setups with a kernel update that unlocks a new unsupported option and causes probe failures.

[brentlu]

The topology file only contains the NHLT blobs for DMICs and SSP, not the full NHLT that describes the endpoints. So Chromebooks cannot really figure out how many mics are present and BT offload is also not detectable from platform firmware.

I am fine with the detection of BT offload from NHLT and the additions in the machine driver, but it's a strong NO on all the topology file suffix additions (with BT, with dmics, etc). Chromebooks, or people wanting to experiment on Linux, can set the topology filename with a kernel parameter to select this new BT-offload-capable HDA topology.

We don't want to break existing HDAudio user setups with a kernel update that unlocks a new unsupported option and causes probe failures.

Yes, that's the current status of thesofproject/linux#5123. The topology name is untouched when BT offload is detected. Userspace (udev) need to use tplg_filename module option to load the topology which supports BT offload. Following is my test udev rule file:

# RPL audio device pci id is changed to 0x51ca
SUBSYSTEM=="pci", ATTR{vendor}=="0x8086", ATTR{device}=="0x51ca", ATTR{class}=="0x040100", PROGRAM=="/usr/bin/cros_config / name", RESULT=="brox", RUN+="/sbin/modprobe snd_sof_pci tplg_filename=sof-hda-generic-4ch-bt.tplg"

[lgirdwood]

"Once I upgraded my toolchain for MTL FW, I couldn't generate a valid FW image for platforms using stable-v2.2"

Oh that's not good at all. scripts should hide any sort of dependency on tools. Having two build machines should not be a requirement.

we just had a similar weird problem on a Lenovo device, where with the same kernel different firmware releases work or don't work... see #9339. this issue seems to be solved by taking latest firmware and latest kernel, but something's definitively fishy on signing/authentication.

@lgirdwood @kv2019i FYI.

@brentlu you should not need different machines, I suspect your $PATH may have a mix of tools from main and stable-2.2 branches. Since this is Chrome only I would send straight to the cavs stable branch and not here.

[marc-hb]

you should not need different machines,

@lgirdwood I think @brentlu confirmed that the fix #9342 for this 2 years-old, "non-deterministic" rimage bug worked for him.

[marc-hb]

SOFCI TEST