xtensa-build-xephyr: fix xt-objcopy failure when default-params missing #7277
Conversation
Fixes recent commit 8aab183 ("xtensa-build-zephyr: fix DEFAULT_TOOLCHAIN_VARIANT spill on next platf") Some XtensaTools installation are missing this `default-params` symbolic link: ``` XtensaTools/config/ |-- X4H3I16w2D48w3a_2017_8-params |-- X6H3CNL_2017_8-params |-- cavs2x_LX6HiFi3_2017_8-params `-- default-params -> cavs2x_LX6HiFi3_2017_8-params ``` Maybe it's missing when installing with the graphical interface? This symbolic link is surprisingly enough to make `xt-objcopy` work _without_ the XTENSA_ variables. But when the variables _and_ the link are both missing, then `xt-objcopy` fails with the usual error: ``` in current dir: work/current/sof; running command: XtDevTools/install/tools/RG-2017.8-linux/XtensaTools/bin/xt-objcopy --remove-section .comment sof/build-tgl/zephyr/zephyr.strip build-sof-staging/sof-info/tgl/stripped-zephyr.elf Error: there is no Xtensa core registered as the default. You need to either specify the name of a registered Xtensa core (with the --xtensa-core option or the XTENSA_CORE environment variable) or specify a different registry of Xtensa cores (with the --xtensa-system option or the XTENSA_SYSTEM environment variable). The following Xtensa cores are available: hifiep_bd5 cavs2x_LX6HiFi3_2017_8 sample_config sample_flix ... ``` Fix this failure by simply passing the XTENSA_ variables to xt-objcopy. Kudos to Seppo Ingalsuo for the interactive debugging session that allowed root-causing this problem extremely quickly. Signed-off-by: Marc Herbert <[email protected]>
marc-hb
requested review from
singalsu,
dbaluta,
fredoh9,
greg-intel,
keqiaozhang,
kv2019i,
lgirdwood and
lyakh
|
alsabat failures in cavs2.5 https://sof-ci.01.org/sofpr/PR7277/build4610/devicetest/index.html as usual these days, everything else green. The other device-test is stuck however. The sparse failure is a recent and unrelated regression from #7089 |
There was a problem hiding this comment.
Ouch. I've bumped into similar nonsense playing with "hand-installed" toolchains. The toolchain install process in xtensa is really fragile. It's almost enough to just tar up and copy the directory around, but some things break. IIRC, in some versions of the toolchain that path is a local symlink, and sometimes it contains the full path of the original install tree.
| execute_command( | ||
| [str(x) for x in [objcopy, "--remove-section", ".comment", src, dst]], | ||
| # Some xtensa installs don't have a | ||
| # XtensaTools/config/default-params symbolic link |
There was a problem hiding this comment.
Not sure the comment is really needed, the vendor toolchain passes junk in the environment. No reason to expect the binutils equivalents to work any differently from the compiler.
There was a problem hiding this comment.
Thanks for the review!
The toolchain install process in xtensa is really fragile. It's almost enough to just tar up and copy the directory around, but some things break.
While investigating #7114 I had the... "opportunity" to compare installation across different machines. All the binaries are (fortunately!) identical and the only differences are absolute paths in a number of text config files (set by the installer script). It's much simpler than what I feared initially.
Not sure the comment is really needed, the vendor toolchain passes junk in the environment. No reason to expect the binutils equivalents to work any differently from the compiler.
I've successfully invoked xt-objdump many times without any XTENSA_ variable thanks to this default-params symlink - without realizing it until today! I think that symlink is worth knowing. Here for a lack of a better place.
Fixes recent commit 8aab183 ("xtensa-build-zephyr: fix DEFAULT_TOOLCHAIN_VARIANT spill on next platf")
Some XtensaTools installation are missing this
default-paramssymbolic link:Maybe it's missing when installing with the graphical interface?
This symbolic link is surprisingly enough to make
xt-objcopywork without the XTENSA_ variables. But when the variables and the link are both missing, thenxt-objcopyfails with the usual error:Fix this failure by simply passing the XTENSA_ variables to xt-objcopy.
Kudos to Seppo Ingalsuo for the interactive debugging session that allowed root-causing this problem extremely quickly.