-
Notifications
You must be signed in to change notification settings - Fork 6.8k
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
atomic xtensa build fail #33857
Comments
Does your platform really not have S32C1? That is the Xtensa atomic operations primitive, without it you have no hardware support and need to fall back to a much slower irq_lock() implementation in ATOMIC_OPERATIONS_C. ATOMIC_OPERATIONS_BUILTIN just falls back to the gcc implementations, which are essentially identical to our own and also based on S32C1I -- they won't work for you (the only reason we have our own is that older xcc toolchains don't have the gcc builtins). As far as selecting this automatically based on core-isa.h constants, that would be nice but difficult, as kconfig sits upstream of the C compiler. You need the kconfig output header defined before you can build a C file against core-isa.h. The Zephyr model is that the platform layer decides on software configuration. |
@andyross
as long as CONFIG_XTENSA is configured, select ATOMIC_OPERATIONS_ARCH will be selected. So my suggestion is not to choose here, but to give others the right to choose. |
Usually, GCC builtin or arch-specific atomic functions are being used. The corresponding kconfigs are "selected" by architecture or SoC kconfigs. CONFIG_ATOMIC_OPERATIONS_C is usually used to override the GCC built-in or arch-specific atomic functions when these two are not supported. So change the priority of #include so that C version is included first if selected, and skips the inline versions of the other two variants. Or else there will be two compiled versions of atomic functions: inline version and the compiled C version. Note that the arch-specific version and builtin are swapped, so the builtin one is now the default. Fixes zephyrproject-rtos#33857 Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Usually, GCC builtin or arch-specific atomic functions are being used. The corresponding kconfigs are "selected" by architecture or SoC kconfigs. CONFIG_ATOMIC_OPERATIONS_C is usually used to override the GCC built-in or arch-specific atomic functions when these two are not supported. So change the priority of #include so that C version is included first if selected, and skips the inline versions of the other two variants. Or else there will be two compiled versions of atomic functions: inline version and the compiled C version. Note that the arch-specific version and builtin are swapped, so the builtin one is now the default. Fixes #33857 Signed-off-by: Daniel Leung <daniel.leung@intel.com>
@andyross to be more precise that is one of the possible xtensa atomic operations primitive. There's also exclusive access option with l32ex/s32ex/getex/clrex opcodes and XCHAL_HAVE_EXCLUSIVE core-isa.h macro. |
Describe the bug
Not all xtensa architectures support the s32c1i and SCOMPARE1 registers
code:
log:
At least the code needs to be judged as follows,or distinguish the architecture used
The kconfig I saw opens the ATOMIC_OPERATIONS_ARCH configuration by default.
zephyr\arch\Kconfig:
SECOND:
I found another problem when I enabled ATOMIC_OPERATIONS_BUILTIN
log:
Under the build directory I only found "ZCAN-sdk\build\zephyr\include\generated\syscalls\atomic_c.h" but no "atomic.h"
CONFIG_ATOMIC_OPERATIONS_C and CONFIG_ATOMIC_OPERATIONS_BUILTIN and CONFIG_ATOMIC_OPERATIONS_ARCH are enabled by me at the same time. but there is no warning that they cannot be enabled at the same time
code:
My current change plan can build the code: del "select ATOMIC_OPERATIONS_ARCH" & CONFIG_XTENSA_NO_IPC=y & CONFIG_ATOMIC_OPERATIONS_C=y
zephyr\arch\Kconfig:
The text was updated successfully, but these errors were encountered: