Dependency: add support for loading auxiliary code as LLEXT modules #9399
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
also needs thesofproject/linux#5156 |
Can this PR be split into smaller PRs ? I suspect we have cosmetic. fixes and the new feature patches here? |
@lgirdwood yes, I'd say - this is just my current state dump, will be split |
Add a dedicated type for auxiliary LLEXT objects, not implementing the Module Adapter API. Signed-off-by: Guennadi Liakhovetski <[email protected]>
FIR support code is used by eq-fir and by tdfb. When both of them are built as LLEXT modules, FIR supporting functions can be dynamically loaded too. Signed-off-by: Guennadi Liakhovetski <[email protected]>
llext_manager_link() doesn't the whole of struct module_data, it only needs a pointer to a pointer to struct llext. Modify it to only receive the scope, that it needs. Signed-off-by: Guennadi Liakhovetski <[email protected]>
The LLEXT context is currently bound to the Module Adapter API which shouldn't be the case because we also need generic LLEXT-based loadable SOF objects. This patch moves the context to struct lib_manager_module which is safe, because the library manager is always needed when dynamically loading modules. Signed-off-by: Guennadi Liakhovetski <[email protected]>
Currently lib_manager_module_free() first checks, if an LLEXT module is being freed. If so, it first calls llext_unload() and then - if the use-count is reported as zero, calls llext_manager_free_module(). Simplify this process by just calling llext_manager_free_module() and letting it handle llext_unload() internally. Signed-off-by: Guennadi Liakhovetski <[email protected]>
This reverts commit cf31c9c. We do now need to store BSS information for auxiliary LLEXT management. When instantiating such a module for the second time, we don't have access to Zephyr LLEXT information any more, so we need to use our cached information for .bss allocation. Signed-off-by: Guennadi Liakhovetski <[email protected]>
Extract localisation and linking of a single LLEXT module into a separate function, it will be re-used for auxiliary modules. Signed-off-by: Guennadi Liakhovetski <[email protected]>
Auxiliary modules, implemented as LLEXT and used to provide functionality for other modules, don't have TOML configuration, make rimage skip that step for them. Signed-off-by: Guennadi Liakhovetski <[email protected]>
Add comments to two structure fields, whose meaning isn't immediately obvious otherwise. Signed-off-by: Guennadi Liakhovetski <[email protected]>
llext_manager_load_module()'s ebl argument is only used for .bss alignment. Calculate it automatically to eliminate ebl, because it isn't available during following loads. e.g. when reloading dependencies. Signed-off-by: Guennadi Liakhovetski <[email protected]>
Let llext_manager_mod_init() calculate mod_array itself internally, it has all the data for that. Signed-off-by: Guennadi Liakhovetski <[email protected]>
We need to initialise library context once for each loaded library. Instead of doing it at link time while checking, if it has already been initialised, we can do that at load time. Signed-off-by: Guennadi Liakhovetski <[email protected]>
Add support for auxiliary modules, exporting symbols to other modules. In such cases Zephyr LLEXT API generates a dependency list, but it is only available while the dependent module is loaded. SOF can unload that dependent module from SRAM while still relying on it being present in a resolved state in DRAM. Then on a subsequent loading of that dependent, we don't need to regenerate the dependency list. For that we store it ourselves in module context. Signed-off-by: Guennadi Liakhovetski <[email protected]>
Zephyr PR 84389 enables dependencies, but as it stands it will need some rework. Signed-off-by: Guennadi Liakhovetski <[email protected]>
|
@lyakh what the plan for this ? we have a similar PR, do you need to rebase ? |
@lgirdwood yes, this should be superseded by #9804 but since these two PRs use conceptually different approaches and the new one is still experimental, I'm keeping this one for now in case the new one doesn't work and I need to revert to this. |
|
#9804 now merged, closing this one |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
At the moment LLEXT modules can only be instances of the Module Adapter API. This PR adds ability to load arbitrary code as LLEXT into SOF e.g. to provide functionality by exporting symbols for other LLEXT modules. Requires a yet unmerged Zephyr PR