Repository navigation
provide interface to query loaded firmware and topology to userspace via debugfs #3867
Description
Activity
Thanks @kv2019i for initiating. This helps in case of Chrome too as we have multiple diffferent path for FW and TPLG as below
eg1 : intel/sof/community/
eg2 : intel/sof/<board_name>/We have multiple topology for same board name too:
eg1: intel/sof/board1/board1_2mic.tplg
eg2: intel/sof/board1/board1_4mic.tplgSo i was thinking we can either
(a) We get FW and TPLG path if we enable debug logs, the same print can be made dev_info - this might be easier but prone to extra log ( Also during long duration automation, the log might have been overwrittenBetter solution is to provide as debugfs
So the FW and TPLG path gets recorded ( we can pick the path when its about to load) to ensure we have all the suffix covered.
@sathyap-chrome the Chrome case is inextricable, since you have overlays the name of the files can be ambiguous and point to different topologies or firmware files. You will need a MD5 signature to identify the files I am afraid....
@plbossart The place where we request the final FW or TPLG to load has all the path information including the overlay names to be added. I can do some experiments and share more insights tomorrow.
Hopefully short digression: the https://www.kernel.org/doc/html/latest/driver-api/firmware/request_firmware.html API should really provide a list of all firmware names (not just audio FW and tplg) that were requested and successfully loaded somewhere in
/sys/. A checksum would be ideal. Unlike the audio (or other) driver it could also report about/lib/firmware/updates/etc.This seems like a very basic security requirement to me (even more basic that "Tainted!") but what do I know. Right now it does not even log the names by default.
I typically add a hack like this:
--- a/drivers/base/firmware_loader/main.c +++ b/drivers/base/firmware_loader/main.c @@ -552,7 +552,7 @@ fw_get_filesystem_firmware(struct device *device, struct fw_priv *fw_priv, size = rc; rc = 0; - dev_dbg(device, "Loading firmware from %s\n", path); + dev_warn(device, "MARC Loading firmware from %s\n", path); if (decompress) { dev_dbg(device, "f/w decompressing %s\n", fw_priv->fw_name); @@ -868,6 +868,10 @@ _request_firmware(const struct firmware **firmware_p, const char *name, fw = NULL; } + dev_warn(device, "MARC %s firmware=%s, ret=%d\n", + __func__, name, ret); + *firmware_p = fw; return ret; }
this enhancement request will be parked until we have more clarity on the ask.
@plbossart Isn't the sof-test need quite clear -> thesofproject/sof-test#956 (comment)
Let me retry then @plbossart . Maybe we need to also deepdive into the generic request_firmware() and why the information is not logged.
The kernel simply needs to tell userspace whether it loaded
sof-tgl.riorcommunity/sof-tgl.riorcavs-whatever.dsp. Same for the topology file. That's all, no need to read any sof-test pull request.Anything still unclear?
Maybe we need to also deepdive into the generic request_firmware() and why the information is not logged.
No, parsing logs is slow and unreliable when switching
ipc_typeor using some overrides (sof-test already does it in some places).The kernel simply needs to tell userspace whether it loaded
sof-tgl.riorcommunity/sof-tgl.riorcavs-whatever.dsp. Same for the topology file. That's all, no need to read any sof-test pull request.Anything still unclear?
@marc-hb dmesg already has this information doesnt it?
dmesgis a ring buffer in non-persistent RAM. So it wraps around and loses any information very quickly.dmesgis convenient in interactive use but totally useless in scripts (it's also missing userspace logs, timestamps,... I digress). Let's forgetdmesg. Rephrasing your question:@marc-hb
journalctl -balready has this information doesnt it?Yes and as I just mentioned above (we posted at almost the same time) we already have code in some sof-test places that tries to parse
journalctl. However this parsing has bugs and limitations (e.g: switchingipc_type, not failing after unloading the driver, dependency on the log level, lack of test developers and shell expertise, ...), hence this request.However this parsing has bugs and limitations (e.g: switching
ipc_type, not failing after unloading the driver, dependency on the log level, lack of test developers and shell expertise, ...), hence this request.I am not aware of any bugs or request to fix the existing solution. Seriously we've provided this firmware name forever and there's been no ask for any change for a very long time, and now we need a TDB interface to fix everything. Allow me to be reasonably suspicious on this one. We have to prioritize and that feels like a low low priority to me.
Here's the latest example of how brittle and hard to maintain is the current solution:
There are many others in the sof-test git log and there will be more.
The brittleness of parsing debug logs seems pretty obvious to me (while 973 does something different, I can't even remember why. Good luck)
Seriously we've provided this firmware name forever
I'm lost sorry: who provided what?
and there's been no ask for any change for a very long time,
IPC4 /
dsp_basefw.binis the straw that breaks the camel's back.8 remaining items
I'd still like to do (some of) this and I think it's more needed than ever (see all backlinks above) but I'm soon going away for a long vacation until Sept 2023. Unassigning myself.
- added 5 commits that reference this issue
on Apr 3, 2024 - added a commit that references this issue
on Apr 8, 2024 - added a commit that references this issue
on Apr 8, 2024 - added a commit that references this issue
on Apr 10, 2024 fw_profileis brand new and still a bit buggy (e.g. thesofproject/sof-test#1178) bit it's there and it works.- added a commit that references this issue
on Oct 1, 2024
As the logic has got more complicated to select the SOF firmware and topology filenames to load, it is getting more and more difficult to write robust test-cases that need to match test-content with the topology and firmware loaded.
To make test case development easier and more robust, the kernel should expose the firmware and topologies that have been loaded via debugfs or sysfs.
Example discussion in sof-test: thesofproject/sof-test#956 (comment)
@marc-hb EDIT: this "example" discussion is actually a MUST READ FIRST. It's about deciding what logging solution to use based on the firmware type.