Is your feature request related to a problem? Please describe.

In the toml files we have a description of the platform hardware and a description of the modules (extended manifest) that are embedded in the firmware. I would like to separate the two and conduct some improvements.

With toml files I see the following problems:

• No support for file inclusion. We have a separate toml file for each platform. If a module is used by multiple platforms, we have an identical description of the module's capabilities/configuration duplicated in multiple files.
• Lack of support for labels. At this moment, some fields of the module's configuration is represented as hexadecimal bit masks that are completely unreadable by humans.
• Enabling/disabling building of a given module requires correcting toml files.

Describe the solution you'd like
My idea to solve these problems is to move the information from the toml files to the source code of the modules. While leaving in them only some basic description of the platform and its address space.
We can prepare a structure with the information necessary to generate the extended manifest and put it in a separate section of the elf file. It would be read by rimage (or any other tool in the future). In this way, we already provide some informations to rimage now. This is the module manifest (struct sof_man_module_manifest) in the ".module" section and the extended manifest (duplicated name, this is different informations than in toml files), (struct ext_man_header) section ".fw_metadata". Module manifest for all modules we can easily move to source code, because its reading is already implemented in rimage. The ext_man_header structure was designed to be extensible, so it could be used to pass the module's pin configuration, etc. to rimage. The advantage of this approach is that rimage (or separate tool) would build all manifests using only a compilation artifacts. Adding/removing a module would not involve updating multiple toml files for different platforms.
When creating a loadable library, we eliminate the risk of taking a toml file that does not match the compiled module. The module metadata would be included in the module file.

Describe alternatives you've considered
Alternatively, we should extend toml file support in rimage with:

• Toml file inclusion. Move module descriptions into separate files and include them in platform files.
• Textual value labels to make the configuration more readable.