-
Notifications
You must be signed in to change notification settings - Fork 7k
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
intel_adsp: move west sign from west flash to earlier west build #54700
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the update. The overall design makes sense to me. I would ask that you think about a separate rimage-extra-args
instead of tool-extra-args
, so that we could add imgtool-extra-args
in the future. This in turn would enable quick switching between west sign --tool imgtool
and west sign --tool rimage
in situations where users have to do both.
Zero functional change. Next commit will build rimage _before_ building the firmware which will be required when `west build` starts signing by default (zephyrproject-rtos/zephyr#54700) Signed-off-by: Marc Herbert <[email protected]>
This will be required when signing is transferred to `west build`, see zephyrproject-rtos/zephyr#54700 Signed-off-by: Marc Herbert <[email protected]>
a16e097
to
10ad19b
Compare
I'm guessing the failures are because CI does not have rimage. Maybe I'll make signing at build time optional, downgrade a missing rimage to a warning (and make sure there's a good error message at later flash time) |
Zero functional change. Next commit will build rimage _before_ building the firmware which will be required when `west build` starts signing by default (zephyrproject-rtos/zephyr#54700) Signed-off-by: Marc Herbert <[email protected]>
This will be required when signing is transferred to `west build`, see zephyrproject-rtos/zephyr#54700 Signed-off-by: Marc Herbert <[email protected]>
I just discovered the pretty hard way[*] that
Workaround:
The example above increases the build directory size from 15M to 16M. [*] out of desperation I ended up comparing |
|
10ad19b
to
49bf97f
Compare
testing zephyrproject-rtos/zephyr#54700 Signed-off-by: Marc Herbert <[email protected]>
49bf97f
to
21ecaed
Compare
ec424fb
to
bd4a5ae
Compare
Yes, from the beginning the idea was to stop In v4 bd4a5aecd63031 I think I found a simple way to preserve backwards compatibility and keep these options while achieving the other goals, especially signing in parallel => @nashif could you try this latest version? Thanks! |
you need to rebase. |
Don't force 99% of the users to pass the same value. Signed-off-by: Marc Herbert <[email protected]>
No functional change yet, will be used in the next commits. Signed-off-by: Marc Herbert <[email protected]>
The --tool parameter is not required anymore thanks a [sign] entry in west config like this one: ``` [sign] tool = imgtool ``` Signed-off-by: Marc Herbert <[email protected]>
Reduce duplication, no functional change except for a shorter log statement with slightly less information. This is required by the next commits. Signed-off-by: Marc Herbert <[email protected]>
Add a 3rd option besides --tool-path and $PATH Signed-off-by: Marc Herbert <[email protected]>
Make RIMAGE_SIGN_KEY a CMake CACHE variable so `west sign` can find it and use it as a default value. Fixes thesofproject/sof#6917 Signed-off-by: Marc Herbert <[email protected]>
Zero functional change, pure preparation for the next commit. Signed-off-by: Marc Herbert <[email protected]>
We never want to leave stale outputs behind after failing. Signed-off-by: Marc Herbert <[email protected]>
Moving `west sign` from `west flash` to `west build` for rimage has multiple advantages (including a bit more consistency with imgtool). However it makes `west build` fail when rimage is missing. To avoid forcing every CI and developer who never used it before to install rimage, make signing optional when passing new `west sign` option --if-tool-available. A clear warning is printed. Signed-off-by: Marc Herbert <[email protected]>
Invoking `west sign` in `west build` accelerates twister because `west build` is run in parallel, see rationale in superseded and very different (CMake-based) PR zephyrproject-rtos#52942. To maximize backwards compatibility: - `west sign` is optional in `west build` - `west flash` will sign (again) if any rimage --option is passed Signed-off-by: Marc Herbert <[email protected]>
bd4a5ae
to
b3b327d
Compare
Thanks @nashif for spotting this, looks like it's not possible to be notified of new conflicts without... Slack! ploomber/contributing#16 So v5 b3b327d is a pure rebase, no code change besides resolving the minor The force-push lost all code reviews, would the previous reviewers be kind enough to re-approve? Sorry for the inconvenience. |
The deleted "install" target copied only the rimage executable and left the config files behind. This gave the wrong impression that the executable is useful without config files. "Installing" also gave the wrong impression that rimage versions are somewhat stable and relatively independent of SOF versions: they're not. In fact there is no such thing as an rimage "version": everyone should always use the exact rimage _git commit_ from the west manifest or git submodule. There are no rimage "releases" and no semantic versioning or anything like it, rimage is effectively part of the SOF source and build and run directly from its build directory by practically every SOF developer and SOF CI thanks to sof/src/arch/xtensa/CMakeLists.txt#ExternalProject_Add(rimage_ep ... sof/scripts/xtensa-build-zephyr.py#def build_rimage() sof/zephyr/CMakeLists.txt#set(RIMAGE_CONFIG_PATH ... etc. Providing an "install" target greatly increases the chances of different people and CIs using different rimage versions which is the last thing we want considering the many significant rimage changes happening right now, examples: - zephyrproject-rtos/zephyr#56099 - zephyrproject-rtos/zephyr#54700 - thesofproject/sof#7270 - thesofproject/sof#7304 - thesofproject/sof#7320 - thesofproject#155 While it's useful for multiple files (e.g.: config files), a CMake target was always overkill to copy a single file. Someone or some script who really wants to copy the rimage binary to some other place that the build directory for some (discouraged) reason _can still do so_ with a much more basic, simpler and more transparent file copy command. Finally, the default "bin" DESTINATION required root access which is otherwise totally unncessary to build SOF. Signed-off-by: Marc Herbert <[email protected]>
The deleted "install" target copied only the rimage executable and left the config files behind. This gave the wrong impression that the executable is useful without config files. "Installing" also gave the wrong impression that rimage versions are somewhat stable and relatively independent of SOF versions: they're not. In fact there is no such thing as an rimage "version": everyone should always use the exact rimage _git commit_ from the west manifest or git submodule. There are no rimage "releases" and no semantic versioning or anything like it, rimage is effectively part of the SOF source and build and run directly from its build directory by practically every SOF developer and SOF CI thanks to sof/src/arch/xtensa/CMakeLists.txt#ExternalProject_Add(rimage_ep ... sof/scripts/xtensa-build-zephyr.py#def build_rimage() sof/zephyr/CMakeLists.txt#set(RIMAGE_CONFIG_PATH ... etc. Providing an "install" target greatly increases the chances of different people and CIs using different rimage versions which is the last thing we want considering the many significant rimage changes happening right now, examples: - zephyrproject-rtos/zephyr#56099 - zephyrproject-rtos/zephyr#54700 - thesofproject/sof#7270 - thesofproject/sof#7304 - thesofproject/sof#7320 - thesofproject#155 While it's useful for multiple files (e.g.: config files), a CMake target was always overkill to copy a single file. Someone or some script who really wants to copy the rimage binary to some other place that the build directory for some (discouraged) reason _can still do so_ with a much more basic, simpler and more transparent file copy command. Finally, the default "bin" DESTINATION required root access which is otherwise totally unncessary to build SOF. Signed-off-by: Marc Herbert <[email protected]>
The deleted "install" target copied only the rimage executable and left the config files behind. This gave the wrong impression that the executable is useful without config files. "Installing" also gave the wrong impression that rimage versions are somewhat stable and relatively independent of SOF versions: they're not. In fact there is no such thing as an rimage "version": everyone should always use the exact rimage _git commit_ from the west manifest or git submodule. There are no rimage "releases" and no semantic versioning or anything like it, rimage is effectively part of the SOF source and build and run directly from its build directory by practically every SOF developer and SOF CI thanks to sof/src/arch/xtensa/CMakeLists.txt#ExternalProject_Add(rimage_ep ... sof/scripts/xtensa-build-zephyr.py#def build_rimage() sof/zephyr/CMakeLists.txt#set(RIMAGE_CONFIG_PATH ... etc. Providing an "install" target greatly increases the chances of different people and CIs using different rimage versions which is the last thing we want considering the many significant rimage changes happening right now, examples: - zephyrproject-rtos/zephyr#56099 - zephyrproject-rtos/zephyr#54700 - thesofproject/sof#7270 - thesofproject/sof#7304 - thesofproject/sof#7320 - #155 While it's useful for multiple files (e.g.: config files), a CMake target was always overkill to copy a single file. Someone or some script who really wants to copy the rimage binary to some other place that the build directory for some (discouraged) reason _can still do so_ with a much more basic, simpler and more transparent file copy command. Finally, the default "bin" DESTINATION required root access which is otherwise totally unncessary to build SOF. Signed-off-by: Marc Herbert <[email protected]>
Invoking
west sign
inwest build
accelerates twister becausewest build
is run in parallel, see rationale in superseded and very different (CMake-based) PR #52942To maximize backwards compatibility:
west sign
is optional inwest build
west flash
will sign (again) if any rimage --option is passedThis PR started with "v3", v1 and v2 happened in #54189. v3 is significantly smaller and simpler than v2
Should fix thesofproject/sof#6917
Unlike #52942, this moves the rimage configuration logic not to CMake but to
west sign
configuration instead.You should read and understand #52942 before looking at this.
Also take a look at thesofproject/sof#6917
Signed-off-by: Marc Herbert [email protected]