Repository navigation
[FEATURE] IPC4: verify-firmware-presence.sh: use actual firmware #841
Description
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.
Activity
marc-hb commentedon Jan 28, 2022
The
/lib/firmware/intel/sof/community/part comes from./sof-test/tools/sof-dump-status.py --fwpathThe
tglpart comes from./sof-test/tools/sof-dump-status.py --platform--platformoutput comes from a table of PCI and DMI identifiers embedded insof-dump-status.py+ some/sys/exploration.--fwpathoutput is mostly hardcoded except for thecommunitypart that is added based on matching DMISystem Information -> Manufacturer, Product Nameagainst a list of values embedded in the script.Is
intel/avs/tgl/dsp_basefw.bina 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 commentedon Jan 28, 2022
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.riplbossart commentedon Jan 28, 2022
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.
run-all-tests.sh: don't test that the firmware is loaded
run-all-tests.sh: don't test that the firmware is loaded
run-all-tests.sh: don't test that the firmware is loaded
mengdonglin commentedon Feb 10, 2022
@miRoox I think we need to revise our DUT deployment script? What do you think?
marc-hb commentedon Feb 10, 2022
I will upgrade the
installer/Makefileso it supports the new /lib/firmware layout for IPC4We should all use the same scripts, laying out files in /lib/firmware/ is not a CI-specific task.
Probably off-topic.
mengdonglin commentedon Feb 14, 2022
@marc-hb Are you good to be the feature owner?
marc-hb commentedon Feb 14, 2022
Yes and the plan is in #855
marc-hb commentedon Feb 16, 2022
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)
marc-hb commentedon Feb 16, 2022
I think we should get rid of this test. At the SOF level we simply have no control on what the
request_firmware()loader does in the kernel.request_firmwaredoes not provide any feedback either and never tells what it loaded and where from (which is IMHO a security problem, I digress). I mean it never tells which of multiple paths it picked https://www.kernel.org/doc/html/latest/driver-api/firmware/fw_search_path.htmlThe good news is
./sof-test/tools/sof-dump-status.py --fwpathis used only once in sof-test, only in that test. We can change to printcommunity/or a blank string so it mimics the SOF driver exactly. Callers can then hardcode anything in they want in front of that if they so desire.plbossart commentedon Feb 16, 2022
we could also check that the request_firmware succeeds, but if that fails we'll also never see the boot complete stage, so no problem with removing this test.
plbossart commentedon Mar 7, 2022
@marc-hb I can't recall if we ever reached a consensus on this, and if we even have an issue to fix.
marc-hb commentedon Mar 8, 2022
I think people either agree to remove this test from every test plan where it is an issue, or they don't care. No one will miss it.
@thesofproject/test-maintainers