lib.sh: simplify the check for firmware rtos

[aiChaoSONG]

Previously we do a lot of test to get the firmware path, it is not necessary, because we can acquire it simply with journalctl. Then we can test if the firmware loaded is using zephyr rtos by checking the occurrence of 'zephyr' in the firmware binary as before.

First (maybe the only) step to unlock sof-test for mtl

[marc-hb]

My understanding of @plbossart's comment in thesofproject/linux#3867 (comment) is that we should always parse the debug logs, end of story. So this PR should not exist and 3867 should be closed as wontfix?

Blocking this PR until we have clear, final agreement from everyone on what the final solution must be (even if we tolerate short term hacks in sof-test in the mean time).

[miRoox]

We need this to enable mtrace on MTL

[kv2019i]

I think the patch looks good. The new dependency to

» » dev_dbg(sdev->dev, "request_firmware %s successful\n",
» » » fw_filename);

... in SOF kernel driver should be more explicit though.

[marc-hb]

Please create a new get_firmware_path() function that can be re-used elsewhere if needed (and easily changed to debugfs if/when thesofproject/linux#3867 happens)

Do not drop the URL to thesofproject/linux#3867, it has not been closed as wontfix.

The commit subject is too vague / misleading. How about: stop using PCI IDs to guess the firmware filename, always grep kernel logs instead.

awk has a built-in grep feature, use it. In fact awk can implement tail too, see example in tools/sof-get-default-tplg.sh where we already do something very similar. Also: add a comment referring to tools/sof-get-default-tplg.sh so they can be kept in sync (if thesofproject/linux#3867 or anything else happens)

This should do grep, tail, fix the conflict spotted by @libinyang and everything else with a single awk command but please test it again

journalctl_cmd -k |
awk '/sof.*request_firmware/ { sub(/^.*request_firmware/,""); last_loaded_file=$1 } END { print last_loaded_file }'

[marc-hb]

The commit subject is too vague / misleading. How about: stop using PCI IDs to guess the firmware filename, always grep kernel logs instead.

This patch stops using PCI IDs while PR #976 adds a new PCI ID at the same time. What is going on?

BTW have you looked for other places where sof-dump-status.py -p / -P are used? Don't they need the same fix?

[mengdonglin]

The commit subject is too vague / misleading. How about: stop using PCI IDs to guess the firmware filename, always grep kernel logs instead.>
This patch stops using PCI IDs while PR #976 adds a new PCI ID at the same time. What is going on?

@marc-hb I think sof-dump-status.py is for dumping platform info to debug FW bugs. So PR #976 seems not relevant to this. We don't really care what SoC is used.

BTW have you looked for other places where sof-dump-status.py -p / -P are used? Don't they need the same fix?

[kv2019i]

Thanks @aiChaoSONG , looks good to me!

[marc-hb]

Can someone check the internal test results for BOTH stable-2.2 and main before merging this?

@marc-hb I think sof-dump-status.py is for dumping platform info to debug FW bugs. So PR #976 seems not relevant to this. We don't really care what SoC is used.

sof-dump-status.py is still used in many sof-test places for many things including finding the firmware filename, either directly or indirectly.

[marc-hb]

You dropped this

# FIXME: the kernel driver should give us the FW path
# https://github.com/thesofproject/linux/issues/3867

out of date

[miRoox]

die here will lose "Test Result: FAIL!" and make our CI treat it as TIMEOUT. #979

[marc-hb]

Thanks @miRoox! The func_exit_handler() should print "Test Result: something", did you find why it does not?

[marc-hb]

To reproduce simply change the grep value to make it fail.

[miRoox]

The func_exit_handler() should print "Test Result: something", did you find why it does not?

As you said in #977, func_exit_handler will not be called again when exit inside it.

[marc-hb]

As you said in #977, func_exit_handler will not be called again when exit inside it.

Answering in bug #979 , let's move the discussion there.