On Mon, Apr 4, 2022 at 12:36 PM Arnd Bergmann <arnd@xxxxxxxx> wrote:
On Mon, Apr 4, 2022 at 9:14 PM Max Filippov <jcmvbkbc@xxxxxxxxx> wrote:
On Mon, Apr 4, 2022 at 12:01 PM Arnd Bergmann <arnd@xxxxxxxx> wrote:
On Mon, Apr 4, 2022 at 7:57 PM Max Filippov <jcmvbkbc@xxxxxxxxx> wrote:
Please let me know if you observe any specific build/runtime issues.
xtensa-linux-gcc-11.1.0 -DKCONFIG_SEED=
...
/git/arm-soc/arch/xtensa/kernel/head.S: Assembler messages:
/git/arm-soc/arch/xtensa/kernel/head.S:87: Error: invalid register
'atomctl' for 'wsr' instruction
Sure, one cannot use an arbitrary xtensa compiler for the kernel
build, the compiler configuration must match the core variant selected
in the linux configuration. Specifically, for the nommu_kc705_defconfig
the following compiler can be used:
https://github.com/foss-xtensa/toolchain/releases/download/2020.07/x86_64-2020.07-xtensa-de212-elf.tar.gz
If you build the toolchain yourself using crosstool-ng or buildroot they
accept the 'configuration overlay' parameter that does the compiler
customization.
Perhaps the documentation for this part is what needs to be improved.
It sounds like a bug in the kernel Makefile. On all other architectures,
you can generally just pick any (recent) compiler and build any kernel,
as the compiler arguments set the exact target machine type based
on the kernel config. You can't normally rely on the compiler defaults
for kernel builds.
It's not just the defaults. The binary instruction encoding is configurable
on the xtensa architecture, configuration overlay replaces parts of
the toolchain that do that.
The additional CPU state is configurable and the kernel gets customized
with the code that loads and stores this state when someone builds it for
a specific xtensa core.
These customizations are done by the users of the xtensa architecture and
there are hundreds of configurations in existence. The toolchain has never
been supposed to support all of them at once.
--
Thanks.
-- Max
