xtensa-build-zephyr.py: Deployable build #8643
Conversation
The IPC4_CONFIG_OVERLAY is no longer used, remove it. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
The following aliases are missing: tgl: adl-n, rpl tgl-h: rpl-s mtl: arl Update the aliases list accordingly. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Print platform alias information to reduce the need for guessing when trying to figure out what platform supports what platform. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
ujfalusi
requested review from
aiChaoSONG,
dbaluta,
jsarha,
kv2019i,
lgirdwood,
lyakh,
mengdonglin,
plbossart,
ranj063 and
singalsu
ujfalusi
changed the title
|
The resulting firmware build folder will be for command |
ujfalusi
force-pushed
the
peter/pr/deployable_build_01
branch
from
3b2e3b3 to
03abba1
Compare
The default firmware file path is standardized among vendors as follows:
IPC3
/lib/firmware/VENDOR/sof/
├── community
│ └── sof-PLAT.ri
├── dbgkey
│ └── sof-PLAT.ri
└── sof-PLAT.ri
IPC4
/lib/firmware/VENDOR/sof-ipc4/
└── PLAT
├── community
│ └── sof-PLAT.ri
├── dbgkey
│ └── sof-PLAT.ri
└── sof-PLAT.ri\n
Currently the binaries created by the build can only be used for direct
deployment on IPC3 platforms but if one builds different vendor firmwares
the files have to be manually picked and sorted out.
We have two flags: --fw-naming and --use-platform-subdir which can be
played with but still not going to produce deployable build.
Introduce a new flag: --deployable-build
With the flag specified all other modificators are going to be ignored and
the build will do the 'right thing' to create a directory structure which
can be deployed as it is to the target's firmware directory.
To achieve this several changes needed:
PlatformConfig:
- drop the name member and replace it with a vendor string
- add a flag to indicate IPC4 platforms
Later a new option can be added if needed for platforms which can be
IPC3 or IPC4
Ignore fw-naming and use-platform-subdir in case of deployable build. The
options will be reset to their default in case they are changed.
symlink_or_copy extended to handle relative symlinks when the target and
link is not under the same directory.
The --deployable-build is disabled by default, it has to be enabled to
create deployable build for now.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
|
Changes since v1:
|
| if args.use_platform_subdir: | ||
| args.use_platform_subdir = False | ||
| print("The option '--use-platform-subdir' is ignored for deployable builds.") | ||
|
|
There was a problem hiding this comment.
One thing that is not obvious in either git commit or inline comments is what is the relation between deployable_build and the old options. If I've understood right, this is really a transition mechanism, we should not need the old fw-naming/platform-subdir options anymore once. I.e. deployable-build can itself become a deprecate and just be the default. I mean when/why would one need a non-deployable build? :)
There was a problem hiding this comment.
@kv2019i, @marc-hb, we sort of had deployable IPC3 output (no --fw-naming and --use-platform-subdir).
For IPC4 we never had deployable layout, not even with the variation of the two flags.
--fw-naming forces --use-platform-subdir and you will end up with build-sof-staging/sof/tgl/community/dsp_basefw.bin and bunch of .ldc files under sof directory, you still need to sort out the adl, rpl, etc things.
--use-platform-subdir alone would create build-sof-staging/sof/tgl/community/sof-tgl.ri and the alias symlinks right beside the main platform firmware, again, not deployable.
I would argue that the IPC3 was not really deployable either when you mix vendor platforms, they will be dumped at the same directory.
There was a problem hiding this comment.
I would argue that the IPC3 was not really deployable either when you mix vendor platforms, they will be dumped at the same directory.
I "deployed" the IPC3 a lot, it "worked for me". When you write "vendor" do you mean "other than Intel"? Only Intel has ever been released in sof-bin. NXP relies on Yocto AFAIK and ChromeOS has of course a totally different and unique build system. That does not make this script useless outside Intel but I guess it reduces the appeal?
There was a problem hiding this comment.
Supported platforms: ['tgl', 'tgl-h', 'mtl', 'lnl', 'imx8', 'imx8x', 'imx8m', 'imx8ulp']
As long as it claims this, it should be possible to run
./scripts/xtensa-build-zephyr.py --all
and expect the result to be deployable as it is. It is not.
Don't get me wrong, I'm "deploying" the IPC4 firmware to my DUTs just fine:
scp ../build-sof-staging/sof/tgl/community/dsp_basefw.bin root@<tgl_DUT>:/lib/firmware/intel/sof-ipc4/tgl/community/sof-tgl.ri
but I cannot just grab the build dir and move it to tgz or to DUT as it is.
marc-hb
left a comment
marc-hb
left a comment
There was a problem hiding this comment.
The purpose of this script (and of its .sh ancestor) was always to produce a "deployable" tree. Then IPC4 came and no one did the work until you right now (thanks!). Instead, we had CI deployment secrets. We also had some complex avs transition hacks?
I'm against backwards compatibility in this particular case. It makes the code complicated and difficult to follow. We should have a "flag day" instead where CI MUST cleanup most CI deployment secrets. That shouldn't be difficult: mostly getting rid of CI code. Backwards compatibility means CI secrets will be simplified later = never and it means this new option will STILL not be tested in CI and it will bitrot again.
|
Could you submit the first 3 commits in a separate PR? They're pure fixes without any backward compatibility issue that we can fast track.
To be fair there was also a very severe lack of documentation, later fixed by @kv2019i |
Yes, the IPC4 is based on AVS transition and the kernel is guilty also, which I'm trying to rectify with thesofproject/linux#4382 |
The AVS hack is the --fw-naming=AVS which would create non SOF filenames for the firmware. SOF should not have done that, but it was dictated by the kernel as well (we used the reference firmware and naming initially). cAVS2.5 did not planed to be end user IPC4 platform but we use it as a daily dev vehicle and it is better to not have colliding namespaces with the non SOF firmware. @marc-hb, it is not only going to affect Intel, but iMX also, that's why I took the path I did. If @dbaluta or/and someone from NXP can confirm that they are OK with non backwards compatible changes in this, I'm OK to do that.
Yes, I tend to agree, but I have better hope that CI would do the right thing never the less. |
4 participants
The default firmware file path is standardized among vendors as follows:
Currently the binaries created by the build can only be used for direct
deployment on IPC3 platforms but if one builds different vendor firmwares
the files have to be manually picked and sorted out.
We have two flags: --fw-naming and --use-platform-subdir which can be
played with but still not going to produce deployable build.
Introduce a new flag: --deployable-build
With the flag specified all other modificators are going to be ignored and
the build will do the 'right thing' to create a directory structure which
can be deployed as it is to the target's firmware directory.
To achieve this several changes needed:
Update the platform aliases
PlatformConfig:
Later a new option can be added if needed for platforms which can be
IPC3 or IPC4
Ignore fw-naming and use-platform-subdir in case of deployable build. The
options will be reset to their default in case they are changed.
symlink_or_copy extended to handle relative symlinks when the target and
link is not under the same directory.
The --deployable-build is disabled by default, it has to be enabled to
create deployable build for now.
Signed-off-by: Peter Ujfalusi peter.ujfalusi@linux.intel.com