intel_debug: introduction: Split firmware lookup table into two for m… #506

ujfalusi · 2024-12-16T16:25:00Z

…onolithic and modular

Separate the firmware lookup table for monolithic and modular SOF release to be able to document the locations and file names the firmware will be looking for the individual files.

Extend the description of the two type of SOF release and convert the list-table to a normal table for better descriptions for the configurations.

lyakh · 2024-12-17T07:37:05Z

getting_started/intel_debug/introduction.rst

-See :ref:`loadable-libraries` for details about library support in general.
+The release contains:
+ - **sof-PLAT.ri** : The firmware binary
+ - **UUID.bin** : Mainly 3rd party libraries identified by UUID. If the library contains multiple modules then a UUID symlink must be provided for each one. Optional, only supported with IPC4 and on Meteor Lake and newer platforms.


should this really still be called "monolithic?" To me "monolithic" is when you have no loadable modules at all, no run-time code loading. Do we need to document 3 types then? Monolithic, individual modules and bundled modules?

I think it was a mistake to release the DRC as module in a tech demo style for LNL, but my point here is:
monolithic: basefw (+optional UUID libraries, if any)
modular: basefw + openmodules + debug (+optional UUID libraries, if any)

The item tells that the UUID.bin is only supported on MTL+, which is correct.

@ujfalusi Github ate my comment (or user error), but I did intend to comment at this as well. I get @lyakh 's concern here, were are in fact shipping a modular build in 2024.09 , so it is what it is.

I do like the "Modular Release" name, so not sure how to name the "before" and "after" layouts. Maybe just call it what is, "SOF Modular Release Layout V2 (for PTL and newer)", and "SOF Modular Release Layout V1" (for LNL/ARL/MTL)". Not pretty but describes what it is.

I consider the UUID based loading as monolithic+library. The LNL is a short sighted tech demo to show that we can load a single module (as library) to the firmware.

But technically MTL+ will be able to load modular release (basefw+openmodules+debug+UUID), it is just that sof-bin will only going top ship modular release for PTL+.

My distinction criteria is:
If there is basefw and openmodules and/or debug) in the firmware path then it is a modular release, if there is only the basefw in there, it is monolithic.

The kernel will not care about any of these platform names, it will try to see if these fixed named libraries are there and if they are, load them.

and the UUID based library loading is also supported from MTL+ So, on PTL also.

Monolithic release == single library in fw path
Modular release == multiple libraries in fw path

Note: basefw is a library.

Right, I now get approach. So you want to keep this generic so that driver can detect the scheme used and in theory if sof-bin ever releases a modular release layout for MTL, kernel could pick it up (unlikely as we don't want to break systems with older kernels, but alas, technically this could be done -- it's just a question of release logistics and dependencies then).

I still don't like the "monolithic release" name, but I like "modular release" I can't come with a better alternative.

I agree with the name monolithic being a bit of a misnomer too. It hints at not supporting loadable modules.

I have a suggestion, how about legacy(for the old releases) and bespoke (for the multiple binaries version) releases?

I don't really understand what bespoke means here...
I was thinking of:

1.3.1 Single firmware releases blah blah blah. 1.3.1.1 Support for external libraries UUID loading for mtl+ 1.3.2 Modular firmware release as it is documented now.

The reason why we are defining the 'modular SOF' is that we don't want multiple UUIDs in the library path (either as files or symlinks to a bundle).

Yes, technically the library loading is going to be used for the openmodules and debug, but the distinction is that their name is hardwired, defined. Whereas the external libraries are loaded on demand based on UUID.

kv2019i

Naming is hard. Some comments inline...

kv2019i · 2024-12-17T11:21:59Z

getting_started/intel_debug/introduction.rst

-     - PLAT = mtl, lnl, ...
+Linux SOF will look up firmware files at the following paths.
+
+Look-up paths per Intel platform for **mopnolithic releases**


Not sure world is ready for mopnolithic releases yet...?

kv2019i · 2024-12-17T11:34:29Z

getting_started/intel_debug/introduction.rst

+-----------------------------------------------------------+------------------------------------------------+-------------------------+--------------------+
+|Platform                                                   |Load path                                       |File name                |Notes               |
+===========================================================+================================================+=========================+====================+
+|Meteor Lake and newer                                      |/lib/firmware/intel/sof-ipc4/PLAT/              ||                        |PLAT = mtl, lnl, ...|


We already know we won't support this for MTL, LNL, so why mention these at all?

Don't say never... Technically it is possible.

ujfalusi · 2024-12-17T11:53:51Z

Changes since v1:

fix typo mopnolithic -> monolithic
Clarify that the modular release is PTL+ targeted (Moving MTL/LNL to this mode can break users system with older kernels)

kv2019i · 2024-12-17T15:06:47Z

getting_started/intel_debug/introduction.rst

+|Panther Lake and newer (community signed)                   |/lib/firmware/intel/sof-ipc4/PLAT/community/    |                         |               |
+------------------------------------------------------------+------------------------------------------------+-------------------------+            -- |
+|Panther Lake and newer Loadable libraries                   |/lib/firmware/intel/sof-ipc4-lib/PLAT/          |UUID.bin                 |               |
+------------------------------------------------------------+------------------------------------------------+                         |            -- |


@ujfalusi Also, why not just put UUID.bins to the main directory? The UUID namespace is unique by definition, so what do we gain by putting these to sof-ipc4-lib versus sof-ipc4?

I cannot find the thread on why we ended up with a separate directory for the libraries, it is mentioned here at least: thesofproject/linux#3826 (comment)

I think it has something to do with the fact that libraries can be signed with a vendor key and in that case they cannot be alongside of the Intel or community signed basefw, but the basefw can be only signed with Intel or community key.

But this has been the rule ever since we have the UUID based library lookup. Initially I wanted to toss them alongside of the basefw, but then we have changed direction and there were a good reason to do that (but what? I cannot recall).

Ack, thanks @ujfalusi . So this goes to "water under the bridge" category, let's stick to what we've done already and be consistent with previous IPC4 FW releases.

kv2019i

Some grumblings on "monolithic release" term, but I don't have better alternatives, so +1 for this.

kv2019i · 2024-12-17T15:43:43Z

getting_started/intel_debug/introduction.rst

+|Panther Lake and newer (community signed)                   |/lib/firmware/intel/sof-ipc4/PLAT/community/    |                         |               |
+------------------------------------------------------------+------------------------------------------------+-------------------------+            -- |
+|Panther Lake and newer Loadable libraries                   |/lib/firmware/intel/sof-ipc4-lib/PLAT/          |UUID.bin                 |               |
+------------------------------------------------------------+------------------------------------------------+                         |            -- |


Ack, thanks @ujfalusi . So this goes to "water under the bridge" category, let's stick to what we've done already and be consistent with previous IPC4 FW releases.

kv2019i · 2024-12-17T15:46:06Z

getting_started/intel_debug/introduction.rst

-See :ref:`loadable-libraries` for details about library support in general.
+The release contains:
+ - **sof-PLAT.ri** : The firmware binary
+ - **UUID.bin** : Mainly 3rd party libraries identified by UUID. If the library contains multiple modules then a UUID symlink must be provided for each one. Optional, only supported with IPC4 and on Meteor Lake and newer platforms.


Right, I now get approach. So you want to keep this generic so that driver can detect the scheme used and in theory if sof-bin ever releases a modular release layout for MTL, kernel could pick it up (unlikely as we don't want to break systems with older kernels, but alas, technically this could be done -- it's just a question of release logistics and dependencies then).

I still don't like the "monolithic release" name, but I like "modular release" I can't come with a better alternative.

ujfalusi · 2024-12-17T16:41:22Z

Changes since v2:

rename the monolithic to single firmware.

ujfalusi · 2024-12-17T18:55:22Z

What about this naming:
1.3.1 Single firmware release + UUID on demand library support on MTL+
1.3.2 Split firmware release (basefw+openmodules+debug) + UUID on demand library support

instead of the Single/Modular.

ranj063 · 2024-12-18T00:02:16Z

What about this naming: 1.3.1 Single firmware release + UUID on demand library support on MTL+ 1.3.2 Split firmware release (basefw+openmodules+debug) + UUID on demand library support

instead of the Single/Modular.

or how about unified/fragmented? I'm good with single/split too.

…elease Separate the firmware lookup table for non-modular and modular SOF releases to be able to document the locations and file names the firmware will be looking for the individual files. Extend the description of the two type of SOF release and convert the list-table to a normal table for better descriptions for the configurations. Signed-off-by: Peter Ujfalusi <[email protected]>

ujfalusi · 2024-12-18T07:53:41Z

Changes since v3:
new terms to use: Non-modular and Modular SOF:
non-modular: No loadable library support (IPC3, IPC4 prior to MTL)
modular: supports library loading, two distribution mode: single firmware and split firmware

lyakh · 2024-12-18T08:47:42Z

What about this naming: 1.3.1 Single firmware release + UUID on demand library support on MTL+ 1.3.2 Split firmware release (basefw+openmodules+debug) + UUID on demand library support

instead of the Single/Modular.

@ujfalusi I like it! I was about to propose something like multi-part / single-part / modular, but split is ok too!

kv2019i

Even better!

ujfalusi requested review from lyakh and kv2019i December 16, 2024 16:25

ujfalusi requested review from lgirdwood, deb-intel, intelkevinputnam, mmaka1 and mwasko as code owners December 16, 2024 16:25

ujfalusi mentioned this pull request Dec 16, 2024

ASoC: SOF: ipc4: Add support for split firmware releases thesofproject/linux#5270

Open

lyakh reviewed Dec 17, 2024

View reviewed changes

kv2019i reviewed Dec 17, 2024

View reviewed changes

ujfalusi force-pushed the pr/intel_ipc4_baselibs_with_basefw_01 branch from 6cd4788 to 7d5c67e Compare December 17, 2024 11:52

kv2019i reviewed Dec 17, 2024

View reviewed changes

kv2019i previously approved these changes Dec 17, 2024

View reviewed changes

ujfalusi dismissed kv2019i’s stale review via 155fa2a December 17, 2024 16:40

ujfalusi force-pushed the pr/intel_ipc4_baselibs_with_basefw_01 branch from 7d5c67e to 155fa2a Compare December 17, 2024 16:40

ujfalusi force-pushed the pr/intel_ipc4_baselibs_with_basefw_01 branch from 155fa2a to 0576be4 Compare December 18, 2024 07:48

kv2019i approved these changes Dec 18, 2024

View reviewed changes

ranj063 approved these changes Dec 18, 2024

View reviewed changes

lgirdwood approved these changes Dec 20, 2024

View reviewed changes

lgirdwood merged commit 6eee88f into thesofproject:master Dec 20, 2024
3 of 4 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

intel_debug: introduction: Split firmware lookup table into two for m… #506

intel_debug: introduction: Split firmware lookup table into two for m… #506

ujfalusi commented Dec 16, 2024

lyakh Dec 17, 2024

ujfalusi Dec 17, 2024

kv2019i Dec 17, 2024

ujfalusi Dec 17, 2024

kv2019i Dec 17, 2024

ranj063 Dec 17, 2024

ujfalusi Dec 17, 2024

kv2019i left a comment

kv2019i Dec 17, 2024

kv2019i Dec 17, 2024

ujfalusi Dec 17, 2024

ujfalusi commented Dec 17, 2024

kv2019i Dec 17, 2024

ujfalusi Dec 17, 2024

kv2019i Dec 17, 2024

kv2019i left a comment

kv2019i Dec 17, 2024

kv2019i Dec 17, 2024

ujfalusi commented Dec 17, 2024

ujfalusi commented Dec 17, 2024 •

edited

Loading

ranj063 commented Dec 18, 2024

ujfalusi commented Dec 18, 2024

lyakh commented Dec 18, 2024

kv2019i left a comment

intel_debug: introduction: Split firmware lookup table into two for m… #506

intel_debug: introduction: Split firmware lookup table into two for m… #506

Conversation

ujfalusi commented Dec 16, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kv2019i left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ujfalusi commented Dec 17, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kv2019i left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ujfalusi commented Dec 17, 2024

ujfalusi commented Dec 17, 2024 • edited Loading

ranj063 commented Dec 18, 2024

ujfalusi commented Dec 18, 2024

lyakh commented Dec 18, 2024

kv2019i left a comment

Choose a reason for hiding this comment

ujfalusi commented Dec 17, 2024 •

edited

Loading