Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

copy zephyr based sof image toml files from rimage to sof and split to platform and module toml #8243

Closed
wants to merge 4 commits into from

Conversation

aiChaoSONG
Copy link
Collaborator

@aiChaoSONG aiChaoSONG commented Sep 22, 2023

This patch copies Intel IPC4 toml files from rimage to sof repo, and split toml files
to platform related toml and module related toml.
Also update build scripts.

cc:

Copy link
Collaborator

@marc-hb marc-hb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • In the relevant commit message, please add the exact rimage commit you copied the .toml files from.
  • Rename the copied files in a separate commit.

This will make it easy to compare and follow the git history of the copied files across multiple repos.

PS: it is possible to merge the git histories of several repos but that would a bit overkill for so few files.

scripts/xtensa-build-zephyr.py Outdated Show resolved Hide resolved
scripts/xtensa-build-zephyr.py Outdated Show resolved Hide resolved
@marc-hb
Copy link
Collaborator

marc-hb commented Sep 22, 2023

Looks like we have a problem with IPC3:

https://github.com/thesofproject/sof/actions/runs/6269606713/job/17026293267?pr=8243

FileNotFoundError: [Errno 2] No such file or directory:
 '/zep_workspace/sof/config/platform/imx8.toml'

Too bad you just removed the -i IPC4 option?

@marc-hb
Copy link
Collaborator

marc-hb commented Sep 22, 2023

The "ninja not found" failures are worrying but unrelated to this PR, I've seen them elsewhere. Re-running the job in the Github interface usually gets rid of them.

EDIT, filed new:

@aiChaoSONG
Copy link
Collaborator Author

aiChaoSONG commented Sep 22, 2023

@marc-hb Didn't expect the failures on non-intel platforms, I need to add fallback for non-intel platforms to still read toml file from rimage.
@kv2019i Or should I also copy imx toml files to sof? can we have someone from IMX help to comment here?

@marc-hb
Copy link
Collaborator

marc-hb commented Sep 22, 2023

Or should I also copy imx toml files to sof?

Yes I was wondering what makes this move IPC4-specific so far - if anything? Couldn't it be for everything Zephyr? Would be much simpler.

BTW there is a LOT of context here and so far this PR links to none. @aiChaoSONG please add a link to at least #7270 and maybe to #8178 as well

cc: @dbaluta, @andyross

@aiChaoSONG
Copy link
Collaborator Author

@marc-hb Ok, I am thinking(and working) to move toml for zephyr base sof, instead of only moving toml for intel IPC4.

Copy link
Collaborator

@marc-hb marc-hb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rather than:

config/
├── module
│   └── lnl.toml
└── platform
    └── lnl.toml

... could we have this instead?

config/
└── lnl
    ├── module.toml
    └── platform.toml

Then the script can concatenate config/$platf/*.toml without any hardcoded name. More flexible and future proof.

Also, git log -- config/lnl/ is easier and more logical.

Or if needed

config/
└── lnl
    ├── 10-module.toml
    └── 20-platform.toml

Chao Song added 4 commits September 22, 2023 15:49
This patch copies zephyr RTOS base SOF image toml
files from rimage repo to SOF repo.

Files are copied from rimage main branch, commit ID:
7bc2958 Config: Add DCblock to TGL, TGL-H, MTL, and LNL

Link: thesofproject#7270

Signed-off-by: Chao Song <[email protected]>
The default build config in mainline SOF for CAVS2.5
platforms is IPC4, there is no need to keep cavs suffix
for image toml files.

Signed-off-by: Chao Song <[email protected]>
This patch splits toml configs to platform
related configs and module related configs.

Link: thesofproject#7270

Signed-off-by: Chao Song <[email protected]>
As image toml files are copied to sof repo now,
use them for image signing.

Signed-off-by: Chao Song <[email protected]>
@kv2019i
Copy link
Collaborator

kv2019i commented Sep 22, 2023

@marc-hb @aiChaoSONG I'm wondering why not move everyone over. If conceptually rimage is made just a tool with configuration data elsewhere, then all platforms (supported in mailine) move. Limiting to Zephyr doesn't make too much sense as the toml contents is just the same for Zephyr and non-Zephyr.

@thesofproject/amd @thesofproject/mediatek @thesofproject/nxp inputs? This probably doesn't affect you much as long as builds continue to work as before.

@aiChaoSONG
Copy link
Collaborator Author

@kv2019i We have deprecated XTOS and IPC3 on sof mainline, so I only move those with zephyr RTOS. As we won't touch xtensa-build-all.sh anymore, can we count on AMD/NXP/MTK to move their own toml and do script update? The main problem for me is that we don't have their xtensa toolchain and could never build their firmware successfully, let along test signing correctness.

@aiChaoSONG aiChaoSONG changed the title copy IPC4 toml files from rimage to sof and split to platform and module toml copy zephyr based sof image toml files from rimage to sof and split to platform and module toml Sep 22, 2023
@kv2019i
Copy link
Collaborator

kv2019i commented Sep 22, 2023

@aiChaoSONG Aa right. We do have "gcc-build-default-platforms" that covers all platforms and if I checked right, only place where the toml path is defined is work/sof/src/arch/xtensa/CMakeLists.txt (in two make rules plus one comment). So if you change that, that should work for all XTOS builds.

But ack. This gets iffier if we want to use a different layout for the toml files in SOF repo. E.g. for IMX targets that support both XTOS and Zephyr still, this gets really complicated.

So maybe in this PR:

  • copy all Zephyr platforms to SOF
  • keep IPC3 only targets intact
  • once ready, remove the IPC4 algorithm sections from rimage repository
    - removing Intel platform definitions is potentially a problem as that would break Zephyr unit tests now (FYI @nashif ), so this can be done only once Zephyr is ready for removal
    - toml files used by both Zephyr/XTOS (like IMX) cannot be removed as that would break XTOS IMX builds

FYI @nashif - I think in Zephyr, the platform toml file should be generated from DTS data at build time, but that has to be done first, before we can remove any of the current toml data from the repository.

@aiChaoSONG
Copy link
Collaborator Author

aiChaoSONG commented Sep 22, 2023

@kv2019i After looking at cmake files, firmware using xtos is signed with cmake steps. As there is only platform related toml contents for XTOS, I could file another PR(or maybe add more commits in this PR), which copies xtos based sof toml files to sof, and update below cmake, it will be quite smooth transition.

Talking about toml files shared between Zephyr and XTOS, they are imx8.toml, imx8m.toml and imx8x.toml, they are still shared after copying the rest of toml files (because only intel platform tomls have those module related configuration).

-c "${PROJECT_SOURCE_DIR}/rimage/config/${fw_name}.toml" will be changed to -c "${PROJECT_SOURCE_DIR}/config/${fw_name}/10-platform.toml"

		run_rimage
		COMMAND ${PROJECT_BINARY_DIR}/rimage_ep/build/rimage
			-o sof-${fw_name}.ri
			-c "${PROJECT_SOURCE_DIR}/rimage/config/${fw_name}.toml"
			-s ${MEU_OFFSET}
			-k ${RIMAGE_PRIVATE_KEY}
			-i ${RIMAGE_IMR_TYPE}
			-f ${SOF_MAJOR}.${SOF_MINOR}.${SOF_MICRO}
			-b ${SOF_BUILD}
			-e
			sof-${fw_name}

I suggest the copying of the rest of xtos toml files a new PR, because I cannot test it, we can count on amd/mtk/nxp to test it while not block our progress.

@@ -0,0 +1,57 @@
version = [3, 0]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ehm, not following why we have a 10 prefix in our filenames. I want to #include these via the pre-processor.

@@ -585,8 +582,32 @@ def build_rimage():
rimage_build_cmd.append("-v")
execute_command(rimage_build_cmd, cwd=west_top)


def rimage_options(platform_dict):
def concat_rimage_configs(platform_name, dest_dir):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nak, lets use the pre-processor. We also need to add Kconfig detail into the toml too.

@lgirdwood
Copy link
Member

@aiChaoSONG we are going to pre-process our toml files in teh same way we pre-process linker scripts. I would split this PR into 2 PRs.
PR 1 ) just moves the existing tomls files.
PR 2 ) adds pre-processing support to toml. i.e.

/* Intel platform.toml.in */
#include <zephyr/meteorlake/memory-defs.h>
// define all memory regions using macros from C header

Then this would be included by the product toml.in

/* meteorlake toml.in */
#include <platform.toml>
#include <cse.toml>
#if CONFIG_VOLUME 
    #include <volume.toml>
#endif
// and so on

@marc-hb
Copy link
Collaborator

marc-hb commented Sep 25, 2023

The main problem for me is that we don't have their xtensa toolchain and could never build their firmware successfully,

Our docker container has most toolchains, this is what CI uses everyday:

https://github.com/thesofproject/sof/actions/runs/6271755640/job/17031962306?pr=8243

I would split this PR into 2 PRs.

+1, please only one breakage at a time.

@marc-hb
Copy link
Collaborator

marc-hb commented Sep 25, 2023

removing Intel platform definitions is potentially a problem as that would break Zephyr unit tests now (FYI @nashif ), so this can be done only once Zephyr is ready for removal

Yes this will break that. BTW this is why rimage was moved out of SOF: to make it possible to run Zephyr tests on hardware _independently from sof.git.

With hindsight we know that extracting rimage.git from sof.git was a mistake and we'd like to go back and put everything in a single sof.git repo like it was. But this is not happening right now. So this is where we are right now: moving ALL .toml files out of rimage will break Zephyr tests big time.

I think this PR is losing sight of the main objective. The main and most important objective is: support multiple .toml files. So this generic feature must be the first PR, before splitting and moving files around. Once the ability and main feature is merged in the main branch(es) and available for everyone, then it will become easier in a SECOND step for every developer, test suite and CI to try and see what breaks when .toml files get sliced and diced.

Now jumping the gun to this second requirement: the location of .toml files. #7270 considered an interesting possibility: moving only the modules / IPC4 specific .toml to sof.git. Why? Simply because locating modules .toml files out of rimage.git is the only thing actually required! This is the only actual problem to solve. Having the platform .toml files in rimage.git never caused any real problem. Then #7270 assumed that moving ALL .toml files would be "an easier solution". But now we now this assumption was wrong: it's actually much more complex to move all platform .toml files - and it's NOT a requirement. Moving everything just "sounds cool" like extracting rimage.git sounded cool but it's just a lot of extra work and breakages with zero value.

Copy link
Collaborator

@marc-hb marc-hb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've been at last spending some time reading, thinking about the issues here.

==> tl;dr: do NOT implement any multi-toml logic in xtensa-build-zephyr.py. It's just the wrong place.

"All problems in computer science can be solved by another level of indirection"

"...except for the problem of too many layers of indirection/obfuscation".

xtensa-build-zephyr.py is a very good demonstration of the latter.

Every time there are too many layers of indirection, debugging and fixing issues becomes a nightmare because every layer obscures everything below it.

The number of build indirection layers involved when using xtensa-build-zephyr.py is insane: https://docs.zephyrproject.org/latest/develop/west/sign.html#rimage
This page does not even list xtensa-build-zephyr.py, Github Actions and Docker!

Debugging build issues is always like "peeling an onion": trying to reproduce with fewer and fewer layers until you can finally see where the problem is. I know because I'm one of the very rare persons fixing the build (just last week: zephyrproject-rtos/zephyr#63003, #8250, #8253, ...)

The more logic there is a layer of indirection, the harder it is to peel. For that reason, everyone who has ever worked on xtensa-build-zephyr.py always agreed it should be kept as simple and thin as possible.

As a matter of fact I just spent a number of weeks moving rimage-related logic OUT of xtensa-build-zephyr.py:

Ideally, configuring rimage with multiple configuration files belongs to rimage (or maybe even better: in https://github.com/thesofproject/tomlc99) So I don't understand why you abandoned thesofproject/rimage#179.

In 179 @lgirdwood requested C pre-processing of .toml files. Then you closed 179 and replaced it with this PR which still does NOT use the C pre-processor...? I'm not following. Instead you moved file concatenation and rimage-related logic to xtensa-build-zephyr.py = as far away from rimage as possible :-(

If multi-toml can't be done directly in rimage for whatever reason, then the second best choice is a place that is much closer to rimage: either Zephyr's CMake or west sign.

BTW using the C pre-processor feels overly complex and somewhat overkill to me but if we go that route then you definitely want that to be either part of or below the build system The build system knows about the C pre-processor, Kconfig, toolchains etc. unlike xtensa-build-zephyr.py which is quite a distance away from it.

Last but not least: some developers don't even use xtensa-build-zephyr.py. I've seen internal wiki pages documenting how to use west directly and avoid xtensa-build-zephyr.py. One less layer of indirection.

@aiChaoSONG
Copy link
Collaborator Author

aiChaoSONG commented Sep 25, 2023

@marc-hb I suppose this is better to be done with CMake if we choose to use GNU preprocessor, because it is much close to C codes and kconfig, which unfortunately is not my expertise yet.

@RanderWang Chrome asked Rander if we could make the values in toml file more readable, I don't think this could be easily done with preprocessor. Maybe Intergrate some python scripts as a CMake custom command would help, I don't know.

@marc-hb If you have any good idea, and familiar with CMake, maybe you can take over this task?

@lgirdwood
Copy link
Member

@aiChaoSONG pls work with @lyakh on pre-processor for toml modules

@marc-hb
Copy link
Collaborator

marc-hb commented Oct 5, 2023

I'm making very good progress moving the rimage git repo back into sof:

config/imx8.toml Outdated
@@ -0,0 +1,20 @@
version = [1, 0] # use simple file write
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

imx platform also support zephyr build, right?

@kv2019i
Copy link
Collaborator

kv2019i commented Oct 13, 2023

Converted back to draft. Please mark again for review when/if you update this after the recent rimage change #8178. If we go for a different PR (to introduce preprocessor for toml), then this can be closed.

@aiChaoSONG
Copy link
Collaborator Author

aiChaoSONG commented Oct 31, 2023

close, rimage movement is done by Marc, I think Guennadi will do toml preprocess. this is not the right direction to fix.

@aiChaoSONG aiChaoSONG closed this Oct 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants