[FEATURE] IPC4: verify-firmware-presence.sh: use actual firmware

[plbossart]

With the IPC4 file path and filename changes, this test needs to be updated:

[   40.931241] sof-audio-pci-intel-tgl 0000:00:1f.3: request_firmware intel/avs/tgl/dsp_basefw.bin successful

2022-01-27 23:55:25 UTC Sub-Test: [INFO] Checking file: /lib/firmware/intel/sof/sof-tgl.ri

The paths and filenames need to be updated.

[marc-hb]

Checking file: /lib/firmware/intel/sof/community/sof-tgl.ri

The /lib/firmware/intel/sof/community/ part comes from ./sof-test/tools/sof-dump-status.py --fwpath
The tgl part comes from ./sof-test/tools/sof-dump-status.py --platform

--platform output comes from a table of PCI and DMI identifiers embedded in sof-dump-status.py + some /sys/ exploration.

--fwpath output is mostly hardcoded except for the community part that is added based on matching DMI System Information -> Manufacturer, Product Name against a list of values embedded in the script.

Is intel/avs/tgl/dsp_basefw.bin a good model / good filename example representative of all configurations? For both open and closed source?

This test is designed to PASS before the firmware is loaded. I doubt it's possible to predict the IPC version before the firmware is loaded, is there? So should the test just look for both and pass when any is found?

If this gets too complicated this test should simply be removed from IPC4 test plans. It's never been terribly useful IMHO.

[marc-hb]

Is intel/avs/tgl/dsp_basefw.bin a good model / good filename example representative of all configurations? For both open and closed source?

Thanks @ranj063 for answering this: yes this is a good template for closed source. Open source will hopefully have a template too but a different one, probably something like intel/sof/community/sof-abc4.ri

[plbossart]

we are going to use a different path for SOF w/ IPC4, e.g. inte/sof-ipc4/. So I wonder if this test should be removed completely.
It makes no sense anyway because the distribution typically has firmwares installed, but likely not the ones you want to test. This model of hard-coding path and overriding distribution files is not good. We should use /lib/firmware/updates for CI and tests.

[mengdonglin]

we are going to use a different path for SOF w/ IPC4, e.g. inte/sof-ipc4/. So I wonder if this test should be removed completely. It makes no sense anyway because the distribution typically has firmwares installed, but likely not the ones you want to test. This model of hard-coding path and overriding distribution files is not good. We should use /lib/firmware/updates for CI and tests.

@miRoox I think we need to revise our DUT deployment script? What do you think?

[marc-hb]

I will upgrade the installer/Makefile so it supports the new /lib/firmware layout for IPC4

We should all use the same scripts, laying out files in /lib/firmware/ is not a CI-specific task.

Probably off-topic.

[mengdonglin]

@marc-hb Are you good to be the feature owner?

[marc-hb]

Yes and the plan is in #855

[marc-hb]

Sorry I got confused: the plan in #855 (PR #860) was for bugs #842 and #845, not for this.

... but I will have a look a this anyway tomorrow (I was focused on #860 and others)