thesofproject
library manager: initial implementation
Library manager is part of loading external libraries responsible of handling data and placing it in proper order and places.
After receiving IPC4 load library command
- reads manifest
- after module_id choses module to load and verify it (WIP)
- loads manifest
- allocs propper memory size
- transfer module from IMR to HPSRAM (WIP)
Signed-off-by: Stelter, Jaroslaw [email protected] Signed-off-by: Dobrowolski, PawelX [email protected]
Can one of the admins verify this patch?
reply test this please to run this test once
@pjdobrowolski @lgirdwood aside from having this quick merged what stops us from implementing this feature in zephyr?
Most checkpatch warnings at https://sof-ci.01.org/sofpr/PR5796/build327/checkpatch/ seem valid (and easy to fix)
Some questions
- How are we testing this today ? and how should we test in CI
This PR is only small part responsible for loading library binary. More changes are required to have something testable.
- Does this version support the dynamic linking or just the dynamic loading today ?
We support now dynamic loading of library containing 3rd party module binary. Currently available libraries in IADK (Windows close source FW) are not supporting dynamic linking, however it could be supported in the future.
@pjdobrowolski is this really draft PR ? i.e untested and WIP ? @lgirdwood yes, indeed it is a draft PR. However it is tested on architectural level still WIP because of i.e. lack memory management features.
Unrelated BYT failures in https://sof-ci.01.org/sofpr/PR5796/build476/devicetest/ should be addressed by fresh sof-test PR
- https://github.com/thesofproject/sof-test/pull/911
Sorry for the inconvenience.
@pjdobrowolski ready for more review yet or still WIP ?
I'm open for any review. It is still WIP though.
@pjdobrowolski are all review comments resolved now or just an intermediate push for testing ?
@lgirdwood I've done that, not all conversations were valid and caused some compilator errors. I've added trace as you suggested and rebased to upstream.
@pjdobrowolski could you take a quick look at the CI, not sure why build would only fail for TGL (unless license server issue). @wszypelt fyi - may need to restart/check CI.
@pjdobrowolski pls check CI again in a few hours, not expecting a TGL build failure but pls do fix if it comes back.
@pjdobrowolski pls check CI again in a few hours, not expecting a TGL build failure but pls do fix if it comes back.
Please ignore me @pjdobrowolski - it seems CI is down for maintenance today. We can rerun tomorrow.
@lgirdwood I've to explain myself. Library manager might need slight refactor because of last changes to comp_drv. I'm checking it right now. So be patient I'm eager to finally marge it also.
@ranj063 I have a question about &md->cfg , from where comes configuration? Where is data from module init instance?
@ranj063 I have a question about &md->cfg , from where comes configuration? Where is data from module init instance?
@pjdobrowolski Fwiw, @ranj063 is out. I will try and answer (although you may need to dig) - this should mostly come from topology (via IPC) although some data may also come from set_large_config() after the module has been created. No config should be hard coded.
@lgirdwood I agree, mod_cfg should come from ipc4, and be stored for specific module. If I understand, now we are using mod_cfg from mailbox which is not copied to any other temporary buffer and can be overwritten by upcoming ipc. Before https://github.com/thesofproject/sof/pull/5994 space for mod_cfg was reserved for each module and that method was common for ipc3 and ipc4.
@lgirdwood I've resolved all issues. I think that it is ready to merge.