| Message ID | 20230103164359.24347-1-ysionneau@kalray.eu (mailing list archive) |
|---|---|
| Headers | show |
| Series | Upstream kvx Linux port | expand |
On Tue, Jan 03, 2023 at 05:43:34PM +0100, Yann Sionneau wrote: > This patch series adds support for the kv3-1 CPU architecture of the kvx family > found in the Coolidge (aka MPPA3-80) SoC of Kalray. > > This is an RFC, since kvx support is not yet upstreamed into gcc/binutils, > therefore this patch series cannot be merged into Linux for now. > > The goal is to have preliminary reviews and to fix problems early. > > The Kalray VLIW processor family (kvx) has the following features: > * 32/64 bits execution mode > * 6-issue VLIW architecture > * 64 x 64bits general purpose registers > * SIMD instructions > * little-endian > * deep learning co-processor > > Kalray kv3-1 core which is the third of the kvx family is embedded in Kalray > Coolidge SoC currently used on K200 and K200-LP boards. > > The Coolidge SoC contains 5 clusters each of which is made of: > * 4MiB of on-chip memory (SMEM) > * 1 dedicated safety/security core (kv3-1 core). > * 16 PEs (Processing Elements) (kv3-1 cores). > * 16 Co-processors (one per PE) > * 2 Crypto accelerators > > The Coolidge SoC contains the following features: > * 5 Clusters > * 2 100G Ethernet controllers > * 8 PCIe GEN4 controllers (Root Complex and Endpoint capable) > * 2 USB 2.0 controllers > * 1 Octal SPI-NOR flash controller > * 1 eMMC controller > * 3 Quad SPI controllers > * 6 UART > * 5 I2C controllers (3 of which are SMBus capable) > * 4 CAN controllers > * 1 OTP memory > > A kvx toolchain can be built using: > # install dependencies: texinfo bison flex libgmp-dev libmpc-dev libmpfr-dev > $ git clone https://github.com/kalray/build-scripts > $ cd build-scripts > $ source last.refs > $ ./build-kvx-xgcc.sh output > > The kvx toolchain will be installed in the "output" directory. > > A buildroot image (kernel+rootfs) and toolchain can be built using: > $ git clone -b coolidge-for-upstream https://github.com/kalray/buildroot > $ cd buildroot > $ make O=build_kvx kvx_defconfig > $ make O=build_kvx > > The vmlinux image can be found in buildroot/build_kvx/images/vmlinux. > > If you are just interested in building the Linux kernel with no rootfs you can > just do this with the kvx-elf- toolchain: > $ make ARCH=kvx O=build_kvx CROSS_COMPILE=kvx-elf- default_defconfig > $ make ARCH=kvx O=build_kvx CROSS_COMPILE=kvx-elf- -j$(($(nproc) + 1)) > > The vmlinux ELF can be run with qemu by doing: > # install dependencies: ninja pkg-config libglib-2.0-dev cmake libfdt-dev libpixman-1-dev zlib1g-dev > $ git clone https://github.com/kalray/qemu-builder > $ cd qemu-builder > $ git submodule update --init > $ make -j$(($(nproc) + 1)) > $ ./qemu-system-kvx -m 1024 -nographic -kernel <path/to/vmlinux> > > Yann Sionneau (25): > Documentation: kvx: Add basic documentation > kvx: Add ELF-related definitions > kvx: Add build infrastructure > kvx: Add CPU definition headers > kvx: Add atomic/locking headers > kvx: Add other common headers > kvx: Add boot and setup routines > kvx: Add exception/interrupt handling > kvx: irqchip: Add support for irq controllers > kvx: Add process management > kvx: Add memory management > kvx: Add system call support > kvx: Add signal handling support > kvx: Add ELF relocations and module support > kvx: Add misc common routines > kvx: Add some library functions > kvx: Add multi-processor (SMP) support > kvx: Add kvx default config file > kvx: power: scall poweroff driver > kvx: gdb: add kvx related gdb helpers > kvx: Add support for ftrace > kvx: Add support for jump labels > kvx: Add debugging related support > kvx: Add support for CPU Perf Monitors > kvx: Add support for cpuinfo You should strip this series down to just what's needed to boot. You don't need the last 7 patches at least. Rob
On Tue, Jan 3, 2023, at 17:43, Yann Sionneau wrote: > This patch series adds support for the kv3-1 CPU architecture of the kvx family > found in the Coolidge (aka MPPA3-80) SoC of Kalray. > > This is an RFC, since kvx support is not yet upstreamed into gcc/binutils, > therefore this patch series cannot be merged into Linux for now. > > The goal is to have preliminary reviews and to fix problems early. > > The Kalray VLIW processor family (kvx) has the following features: > * 32/64 bits execution mode > * 6-issue VLIW architecture > * 64 x 64bits general purpose registers > * SIMD instructions > * little-endian > * deep learning co-processor Thanks for posting these, I had been wondering about the state of the port. Overall this looks really nice, I can see that you and the team have looked at other ports and generally made the right decisions. I commented on the syscall patch directly, I think it's important to stop using the deprecated syscalls as soon as possible to avoid having dependencies in too many libc binaries. Almost everything else can be changed easily as you get closer to upstream inclusion. I did not receive most of the other patches as I'm not subscribed to all the mainline lists. For future submissions, can you add the linux-arch list to Cc for all patches? Reading the rest of the series through lore.kernel.org, most of the comments I have are for improvements that you may find valuable rather than serious mistakes: - the {copy_to,copy_from,clear}_user functions are well worth optimizing better than the byte-at-a-time version you have, even just a C version built around your __get_user/__put_user inline asm should help, and could be added to lib/usercopy.c. - The __raw_{read,write}{b,w,l,q} helpers should normally be defined as inline asm instead of volatile pointer dereferences, I've seen cases where the compiler ends up splitting the access or does other things you may not want on MMIO areas. - I would recomment implementing HAVE_ARCH_VMAP_STACK as well as IRQ stacks, both of these help to avoid data corruption from stack overflow that you will eventually run into. - You use qspinlock as the only available spinlock implementation, but only support running on a single cluster of 16 cores. It may help to use the generic ticket spinlock instead, or leave it as a Kconfig option, in particular since you only have the emulated xchg16() atomic for qspinlock. - Your defconfig file enables CONFIG_EMBEDDED, which in turn enables CONFIG_EXPERT. This is probably not what you want, so better turn off both of these. - The GENERIC_CALIBRATE_DELAY should not be necessary since you have a get_cycles() based delay loop. Just set loops_per_jiffy to the correct value based on the frequency of the cycle counter, to save a little time during boot and get a more accurate delay loop. Arnd
Hi, On Wed, Jan 04, 2023 at 04:58:25PM +0100, Arnd Bergmann wrote: > On Tue, Jan 3, 2023, at 17:43, Yann Sionneau wrote: > > This patch series adds support for the kv3-1 CPU architecture of the kvx family > > found in the Coolidge (aka MPPA3-80) SoC of Kalray. > > > > This is an RFC, since kvx support is not yet upstreamed into gcc/binutils, > > therefore this patch series cannot be merged into Linux for now. > > > > The goal is to have preliminary reviews and to fix problems early. > > > > The Kalray VLIW processor family (kvx) has the following features: > > * 32/64 bits execution mode > > * 6-issue VLIW architecture > > * 64 x 64bits general purpose registers > > * SIMD instructions > > * little-endian > > * deep learning co-processor > > Thanks for posting these, I had been wondering about the > state of the port. Overall this looks really nice, I can > see that you and the team have looked at other ports > and generally made the right decisions. Thank you and all for the reviews. We are currently going through every remarks and we are trying to do our best to send a new patch series with everything addressed. > I commented on the syscall patch directly, I think it's > important to stop using the deprecated syscalls as soon > as possible to avoid having dependencies in too many > libc binaries. Almost everything else can be changed > easily as you get closer to upstream inclusion. > > I did not receive most of the other patches as I'm > not subscribed to all the mainline lists. For future > submissions, can you add the linux-arch list to Cc for > all patches? We misused get_maintainers.pl, running it on each patch instead of using it on the whole series. next time every one will be in copy of every patch in the series and including linux-arch. > Reading the rest of the series through lore.kernel.org, > most of the comments I have are for improvements that > you may find valuable rather than serious mistakes: > > - the {copy_to,copy_from,clear}_user functions are > well worth optimizing better than the byte-at-a-time > version you have, even just a C version built around > your __get_user/__put_user inline asm should help, and > could be added to lib/usercopy.c. right, we are using memcpy for {copy_to,copy_from}_user_page which has a simple optimized version introduced in (kvx: Add some library functions). I wonder if it is possible to do the same for copy_*_user functions. > - The __raw_{read,write}{b,w,l,q} helpers should > normally be defined as inline asm instead of > volatile pointer dereferences, I've seen cases where > the compiler ends up splitting the access or does > other things you may not want on MMIO areas. > > - I would recomment implementing HAVE_ARCH_VMAP_STACK > as well as IRQ stacks, both of these help to > avoid data corruption from stack overflow that you > will eventually run into. > > - You use qspinlock as the only available spinlock > implementation, but only support running on a > single cluster of 16 cores. It may help to use > the generic ticket spinlock instead, or leave it > as a Kconfig option, in particular since you only > have the emulated xchg16() atomic for qspinlock. > > - Your defconfig file enables CONFIG_EMBEDDED, which > in turn enables CONFIG_EXPERT. This is probably > not what you want, so better turn off both of these. > > - The GENERIC_CALIBRATE_DELAY should not be necessary > since you have a get_cycles() based delay loop. > Just set loops_per_jiffy to the correct value based > on the frequency of the cycle counter, to save > a little time during boot and get a more accurate > delay loop. > Ack ! Jules
On Thu, Jan 5, 2023, at 11:40, Jules Maselbas wrote: > On Wed, Jan 04, 2023 at 04:58:25PM +0100, Arnd Bergmann wrote: >> On Tue, Jan 3, 2023, at 17:43, Yann Sionneau wrote: >> I commented on the syscall patch directly, I think it's >> important to stop using the deprecated syscalls as soon >> as possible to avoid having dependencies in too many >> libc binaries. Almost everything else can be changed >> easily as you get closer to upstream inclusion. >> >> I did not receive most of the other patches as I'm >> not subscribed to all the mainline lists. For future >> submissions, can you add the linux-arch list to Cc for >> all patches? > > We misused get_maintainers.pl, running it on each patch instead > of using it on the whole series. next time every one will be in > copy of every patch in the series and including linux-arch. Be careful not to make the list too long though, there is usually a limit of 1024 characters for the entire Cc list, above this your mails may get dropped by the mailing lists. >> Reading the rest of the series through lore.kernel.org, >> most of the comments I have are for improvements that >> you may find valuable rather than serious mistakes: >> >> - the {copy_to,copy_from,clear}_user functions are >> well worth optimizing better than the byte-at-a-time >> version you have, even just a C version built around >> your __get_user/__put_user inline asm should help, and >> could be added to lib/usercopy.c. > > right, we are using memcpy for {copy_to,copy_from}_user_page > which has a simple optimized version introduced in > (kvx: Add some library functions). > I wonder if it is possible to do the same for copy_*_user functions. copy_from_user_page() is only about managing cache aliases, not user access, and it's not used anywhere in the fast path, so it's a bit different. arch/arm/lib/copy_template.S has an example for how you can share the same assembler implementation between memcpy() and copy_from_user(), but it's not very intuitive. The tricky bit with copy_from_user() is the partial copy that relies on copying the exact amount of data that can be accessed including the last byte before the end of the mapping, and returning the correct count of non-copied bytes. If you want a C version, you can probably use the copy_from_kernel_nofault implementation mm/maccess.c as a template, but have to add code for the correct return value. Arnd
On Thu, 05 Jan 2023 13:05:32 +0100 "Arnd Bergmann" <arnd@arndb.de> wrote: > >> I did not receive most of the other patches as I'm > >> not subscribed to all the mainline lists. For future > >> submissions, can you add the linux-arch list to Cc for > >> all patches? > > > > We misused get_maintainers.pl, running it on each patch instead > > of using it on the whole series. next time every one will be in > > copy of every patch in the series and including linux-arch. > > Be careful not to make the list too long though, there is > usually a limit of 1024 characters for the entire Cc list, > above this your mails may get dropped by the mailing lists. It's best to include mailing lists for the entire series, and perhaps individuals for each patch. As I don't want the entire series just to see the tracing portion. -- Steve
Hi, On Wed, Jan 4, 2023 at 1:01 AM Yann Sionneau <ysionneau@kalray.eu> wrote: > > This patch series adds support for the kv3-1 CPU architecture of the kvx family > found in the Coolidge (aka MPPA3-80) SoC of Kalray. > > This is an RFC, since kvx support is not yet upstreamed into gcc/binutils, > therefore this patch series cannot be merged into Linux for now. > > The goal is to have preliminary reviews and to fix problems early. > > The Kalray VLIW processor family (kvx) has the following features: > * 32/64 bits execution mode > * 6-issue VLIW architecture > * 64 x 64bits general purpose registers > * SIMD instructions > * little-endian > * deep learning co-processor > > Kalray kv3-1 core which is the third of the kvx family is embedded in Kalray > Coolidge SoC currently used on K200 and K200-LP boards. > > The Coolidge SoC contains 5 clusters each of which is made of: > * 4MiB of on-chip memory (SMEM) > * 1 dedicated safety/security core (kv3-1 core). > * 16 PEs (Processing Elements) (kv3-1 cores). > * 16 Co-processors (one per PE) > * 2 Crypto accelerators > > The Coolidge SoC contains the following features: > * 5 Clusters > * 2 100G Ethernet controllers > * 8 PCIe GEN4 controllers (Root Complex and Endpoint capable) > * 2 USB 2.0 controllers > * 1 Octal SPI-NOR flash controller > * 1 eMMC controller > * 3 Quad SPI controllers > * 6 UART > * 5 I2C controllers (3 of which are SMBus capable) > * 4 CAN controllers > * 1 OTP memory > > A kvx toolchain can be built using: > # install dependencies: texinfo bison flex libgmp-dev libmpc-dev libmpfr-dev > $ git clone https://github.com/kalray/build-scripts > $ cd build-scripts > $ source last.refs > $ ./build-kvx-xgcc.sh output I would like to build the kvx-xgcc to compile and test the linux kernel, but it reported a compile error. I wonder what version of gcc you are using. My build environment: VERSION="20.04.2 LTS (Focal Fossa)" gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04) Compile error: $ ./build-kvx-xgcc.sh output ../../binutils/libiberty/fibheap.c: In function ‘fibheap_replace_key_data’: ../../binutils/libiberty/fibheap.c:38:24: error: ‘LONG_MIN’ undeclared (first use in this function) 38 | #define FIBHEAPKEY_MIN LONG_MIN | ^~~~~~~~ ../../binutils/libiberty/fibheap.c:220:30: note: in expansion of macro ‘FIBHEAPKEY_MIN’ 220 | if (okey == key && okey != FIBHEAPKEY_MIN) | ^~~~~~~~~~~~~~ ../../binutils/libiberty/fibheap.c:36:1: note: ‘LONG_MIN’ is defined in header ‘<limits.h>’; did you forget to ‘#include <limits.h>’? 35 | #include "fibheap.h" +++ |+#include <limits.h> 36 | ../../binutils/libiberty/fibheap.c:38:24: note: each undeclared identifier is reported only once for each function it appears in 38 | #define FIBHEAPKEY_MIN LONG_MIN | ^~~~~~~~ ../../binutils/libiberty/fibheap.c:220:30: note: in expansion of macro ‘FIBHEAPKEY_MIN’ 220 | if (okey == key && okey != FIBHEAPKEY_MIN) | ^~~~~~~~~~~~~~ ../../binutils/libiberty/fibheap.c: In function ‘fibheap_delete_node’: ../../binutils/libiberty/fibheap.c:38:24: error: ‘LONG_MIN’ undeclared (first use in this function) 38 | #define FIBHEAPKEY_MIN LONG_MIN | ^~~~~~~~ ../../binutils/libiberty/fibheap.c:261:36: note: in expansion of macro ‘FIBHEAPKEY_MIN’ 261 | fibheap_replace_key (heap, node, FIBHEAPKEY_MIN); | ^~~~~~~~~~~~~~ ../../binutils/libiberty/fibheap.c:38:24: note: ‘LONG_MIN’ is defined in header ‘<limits.h>’; did you forget to ‘#include <limits.h>’? 38 | #define FIBHEAPKEY_MIN LONG_MIN | ^~~~~~~~ ../../binutils/libiberty/fibheap.c:261:36: note: in expansion of macro ‘FIBHEAPKEY_MIN’ 261 | fibheap_replace_key (heap, node, FIBHEAPKEY_MIN); | ^~~~~~~~~~~~~~ > The kvx toolchain will be installed in the "output" directory. > > A buildroot image (kernel+rootfs) and toolchain can be built using: > $ git clone -b coolidge-for-upstream https://github.com/kalray/buildroot > $ cd buildroot > $ make O=build_kvx kvx_defconfig > $ make O=build_kvx > > The vmlinux image can be found in buildroot/build_kvx/images/vmlinux. > > If you are just interested in building the Linux kernel with no rootfs you can > just do this with the kvx-elf- toolchain: > $ make ARCH=kvx O=build_kvx CROSS_COMPILE=kvx-elf- default_defconfig > $ make ARCH=kvx O=build_kvx CROSS_COMPILE=kvx-elf- -j$(($(nproc) + 1)) > > The vmlinux ELF can be run with qemu by doing: > # install dependencies: ninja pkg-config libglib-2.0-dev cmake libfdt-dev libpixman-1-dev zlib1g-dev > $ git clone https://github.com/kalray/qemu-builder > $ cd qemu-builder > $ git submodule update --init > $ make -j$(($(nproc) + 1)) > $ ./qemu-system-kvx -m 1024 -nographic -kernel <path/to/vmlinux> > > Yann Sionneau (25): > Documentation: kvx: Add basic documentation > kvx: Add ELF-related definitions > kvx: Add build infrastructure > kvx: Add CPU definition headers > kvx: Add atomic/locking headers > kvx: Add other common headers > kvx: Add boot and setup routines > kvx: Add exception/interrupt handling > kvx: irqchip: Add support for irq controllers > kvx: Add process management > kvx: Add memory management > kvx: Add system call support > kvx: Add signal handling support > kvx: Add ELF relocations and module support > kvx: Add misc common routines > kvx: Add some library functions > kvx: Add multi-processor (SMP) support > kvx: Add kvx default config file > kvx: power: scall poweroff driver > kvx: gdb: add kvx related gdb helpers > kvx: Add support for ftrace > kvx: Add support for jump labels > kvx: Add debugging related support > kvx: Add support for CPU Perf Monitors > kvx: Add support for cpuinfo > > .../kalray,kvx-core-intc.txt | 22 + > .../devicetree/bindings/perf/kalray-pm.txt | 21 + > Documentation/kvx/kvx-exceptions.txt | 246 + > Documentation/kvx/kvx-iommu.txt | 183 + > Documentation/kvx/kvx-mmu.txt | 272 + > Documentation/kvx/kvx-smp.txt | 36 + > Documentation/kvx/kvx.txt | 268 + > arch/kvx/Kconfig | 249 + > arch/kvx/Kconfig.debug | 70 + > arch/kvx/Makefile | 52 + > arch/kvx/configs/default_defconfig | 130 + > arch/kvx/include/asm/Kbuild | 20 + > arch/kvx/include/asm/asm-prototypes.h | 14 + > arch/kvx/include/asm/atomic.h | 104 + > arch/kvx/include/asm/barrier.h | 15 + > arch/kvx/include/asm/bitops.h | 207 + > arch/kvx/include/asm/bitrev.h | 32 + > arch/kvx/include/asm/break_hook.h | 69 + > arch/kvx/include/asm/bug.h | 67 + > arch/kvx/include/asm/cache.h | 46 + > arch/kvx/include/asm/cacheflush.h | 181 + > arch/kvx/include/asm/clocksource.h | 17 + > arch/kvx/include/asm/cmpxchg.h | 185 + > arch/kvx/include/asm/current.h | 22 + > arch/kvx/include/asm/dame.h | 31 + > arch/kvx/include/asm/debug.h | 35 + > arch/kvx/include/asm/elf.h | 155 + > arch/kvx/include/asm/fixmap.h | 47 + > arch/kvx/include/asm/ftrace.h | 41 + > arch/kvx/include/asm/futex.h | 141 + > arch/kvx/include/asm/hardirq.h | 14 + > arch/kvx/include/asm/hugetlb.h | 36 + > arch/kvx/include/asm/hw_breakpoint.h | 72 + > arch/kvx/include/asm/hw_irq.h | 14 + > arch/kvx/include/asm/insns.h | 16 + > arch/kvx/include/asm/insns_defs.h | 197 + > arch/kvx/include/asm/io.h | 34 + > arch/kvx/include/asm/ipi.h | 16 + > arch/kvx/include/asm/irqflags.h | 58 + > arch/kvx/include/asm/jump_label.h | 59 + > arch/kvx/include/asm/l2_cache.h | 75 + > arch/kvx/include/asm/l2_cache_defs.h | 64 + > arch/kvx/include/asm/linkage.h | 13 + > arch/kvx/include/asm/mem_map.h | 44 + > arch/kvx/include/asm/mmu.h | 296 + > arch/kvx/include/asm/mmu_context.h | 156 + > arch/kvx/include/asm/mmu_stats.h | 38 + > arch/kvx/include/asm/page.h | 187 + > arch/kvx/include/asm/page_size.h | 29 + > arch/kvx/include/asm/pci.h | 36 + > arch/kvx/include/asm/perf_event.h | 90 + > arch/kvx/include/asm/pgalloc.h | 101 + > arch/kvx/include/asm/pgtable-bits.h | 102 + > arch/kvx/include/asm/pgtable.h | 451 ++ > arch/kvx/include/asm/privilege.h | 211 + > arch/kvx/include/asm/processor.h | 176 + > arch/kvx/include/asm/ptrace.h | 217 + > arch/kvx/include/asm/pwr_ctrl.h | 45 + > arch/kvx/include/asm/rm_fw.h | 16 + > arch/kvx/include/asm/sections.h | 18 + > arch/kvx/include/asm/setup.h | 29 + > arch/kvx/include/asm/sfr.h | 107 + > arch/kvx/include/asm/sfr_defs.h | 5028 +++++++++++++++++ > arch/kvx/include/asm/smp.h | 42 + > arch/kvx/include/asm/sparsemem.h | 15 + > arch/kvx/include/asm/spinlock.h | 16 + > arch/kvx/include/asm/spinlock_types.h | 17 + > arch/kvx/include/asm/stackprotector.h | 47 + > arch/kvx/include/asm/stacktrace.h | 44 + > arch/kvx/include/asm/string.h | 20 + > arch/kvx/include/asm/swab.h | 48 + > arch/kvx/include/asm/switch_to.h | 21 + > arch/kvx/include/asm/symbols.h | 16 + > arch/kvx/include/asm/sys_arch.h | 51 + > arch/kvx/include/asm/syscall.h | 73 + > arch/kvx/include/asm/syscalls.h | 21 + > arch/kvx/include/asm/thread_info.h | 78 + > arch/kvx/include/asm/timex.h | 20 + > arch/kvx/include/asm/tlb.h | 24 + > arch/kvx/include/asm/tlb_defs.h | 131 + > arch/kvx/include/asm/tlbflush.h | 58 + > arch/kvx/include/asm/traps.h | 76 + > arch/kvx/include/asm/types.h | 12 + > arch/kvx/include/asm/uaccess.h | 324 ++ > arch/kvx/include/asm/unistd.h | 11 + > arch/kvx/include/asm/vermagic.h | 12 + > arch/kvx/include/asm/vmalloc.h | 10 + > arch/kvx/include/uapi/asm/Kbuild | 1 + > arch/kvx/include/uapi/asm/bitsperlong.h | 14 + > arch/kvx/include/uapi/asm/byteorder.h | 12 + > arch/kvx/include/uapi/asm/cachectl.h | 25 + > arch/kvx/include/uapi/asm/ptrace.h | 114 + > arch/kvx/include/uapi/asm/sigcontext.h | 16 + > arch/kvx/include/uapi/asm/unistd.h | 16 + > arch/kvx/kernel/Makefile | 27 + > arch/kvx/kernel/asm-offsets.c | 157 + > arch/kvx/kernel/break_hook.c | 77 + > arch/kvx/kernel/common.c | 11 + > arch/kvx/kernel/cpuinfo.c | 96 + > arch/kvx/kernel/dame_handler.c | 113 + > arch/kvx/kernel/debug.c | 64 + > arch/kvx/kernel/entry.S | 1759 ++++++ > arch/kvx/kernel/ftrace.c | 339 ++ > arch/kvx/kernel/head.S | 612 ++ > arch/kvx/kernel/hw_breakpoint.c | 556 ++ > arch/kvx/kernel/insns.c | 146 + > arch/kvx/kernel/io.c | 96 + > arch/kvx/kernel/irq.c | 78 + > arch/kvx/kernel/jump_label.c | 34 + > arch/kvx/kernel/kvx_ksyms.c | 29 + > arch/kvx/kernel/l2_cache.c | 448 ++ > arch/kvx/kernel/mcount.S | 340 ++ > arch/kvx/kernel/module.c | 148 + > arch/kvx/kernel/perf_event.c | 609 ++ > arch/kvx/kernel/process.c | 212 + > arch/kvx/kernel/prom.c | 24 + > arch/kvx/kernel/ptrace.c | 461 ++ > arch/kvx/kernel/reset.c | 37 + > arch/kvx/kernel/return_address.c | 55 + > arch/kvx/kernel/setup.c | 178 + > arch/kvx/kernel/signal.c | 266 + > arch/kvx/kernel/smp.c | 110 + > arch/kvx/kernel/smpboot.c | 127 + > arch/kvx/kernel/stacktrace.c | 173 + > arch/kvx/kernel/sys_kvx.c | 58 + > arch/kvx/kernel/syscall_table.c | 19 + > arch/kvx/kernel/time.c | 242 + > arch/kvx/kernel/traps.c | 243 + > arch/kvx/kernel/vdso.c | 87 + > arch/kvx/kernel/vmlinux.lds.S | 173 + > arch/kvx/lib/Makefile | 6 + > arch/kvx/lib/clear_page.S | 40 + > arch/kvx/lib/copy_page.S | 90 + > arch/kvx/lib/delay.c | 39 + > arch/kvx/lib/memcpy.c | 70 + > arch/kvx/lib/memset.S | 351 ++ > arch/kvx/lib/strlen.S | 122 + > arch/kvx/lib/usercopy.S | 90 + > arch/kvx/mm/Makefile | 10 + > arch/kvx/mm/cacheflush.c | 154 + > arch/kvx/mm/dma-mapping.c | 95 + > arch/kvx/mm/extable.c | 24 + > arch/kvx/mm/fault.c | 264 + > arch/kvx/mm/hugetlbpage.c | 317 ++ > arch/kvx/mm/init.c | 527 ++ > arch/kvx/mm/kernel_rwx.c | 228 + > arch/kvx/mm/mmap.c | 31 + > arch/kvx/mm/mmu.c | 204 + > arch/kvx/mm/mmu_stats.c | 94 + > arch/kvx/mm/tlb.c | 433 ++ > arch/kvx/platform/Makefile | 7 + > arch/kvx/platform/ipi.c | 110 + > arch/kvx/platform/pwr_ctrl.c | 93 + > drivers/irqchip/Kconfig | 27 + > drivers/irqchip/Makefile | 4 + > drivers/irqchip/irq-kvx-apic-gic.c | 349 ++ > drivers/irqchip/irq-kvx-apic-mailbox.c | 465 ++ > drivers/irqchip/irq-kvx-core-intc.c | 82 + > drivers/irqchip/irq-kvx-itgen.c | 224 + > drivers/power/reset/kvx-scall-poweroff.c | 53 + > include/linux/cpuhotplug.h | 2 + > include/linux/irqchip/irq-kvx-apic-gic.h | 21 + > include/linux/irqchip/irq-kvx-apic-mailbox.h | 29 + > include/linux/irqchip/irq-kvx-itgen.h | 24 + > include/uapi/linux/audit.h | 1 + > include/uapi/linux/elf-em.h | 1 + > include/uapi/linux/elf.h | 1 + > scripts/gdb/arch/Makefile | 11 + > scripts/gdb/arch/__init__.py | 1 + > scripts/gdb/arch/kvx/Makefile | 25 + > scripts/gdb/arch/kvx/__init__.py | 1 + > scripts/gdb/arch/kvx/constants.py.in | 74 + > scripts/gdb/arch/kvx/mmu.py | 199 + > scripts/gdb/arch/kvx/page_table_walk.py | 207 + > tools/include/uapi/asm/bitsperlong.h | 2 + > 175 files changed, 25814 insertions(+) > create mode 100644 Documentation/devicetree/bindings/interrupt-controller/kalray,kvx-core-intc.txt > create mode 100644 Documentation/devicetree/bindings/perf/kalray-pm.txt > create mode 100644 Documentation/kvx/kvx-exceptions.txt > create mode 100644 Documentation/kvx/kvx-iommu.txt > create mode 100644 Documentation/kvx/kvx-mmu.txt > create mode 100644 Documentation/kvx/kvx-smp.txt > create mode 100644 Documentation/kvx/kvx.txt > create mode 100644 arch/kvx/Kconfig > create mode 100644 arch/kvx/Kconfig.debug > create mode 100644 arch/kvx/Makefile > create mode 100644 arch/kvx/configs/default_defconfig > create mode 100644 arch/kvx/include/asm/Kbuild > create mode 100644 arch/kvx/include/asm/asm-prototypes.h > create mode 100644 arch/kvx/include/asm/atomic.h > create mode 100644 arch/kvx/include/asm/barrier.h > create mode 100644 arch/kvx/include/asm/bitops.h > create mode 100644 arch/kvx/include/asm/bitrev.h > create mode 100644 arch/kvx/include/asm/break_hook.h > create mode 100644 arch/kvx/include/asm/bug.h > create mode 100644 arch/kvx/include/asm/cache.h > create mode 100644 arch/kvx/include/asm/cacheflush.h > create mode 100644 arch/kvx/include/asm/clocksource.h > create mode 100644 arch/kvx/include/asm/cmpxchg.h > create mode 100644 arch/kvx/include/asm/current.h > create mode 100644 arch/kvx/include/asm/dame.h > create mode 100644 arch/kvx/include/asm/debug.h > create mode 100644 arch/kvx/include/asm/elf.h > create mode 100644 arch/kvx/include/asm/fixmap.h > create mode 100644 arch/kvx/include/asm/ftrace.h > create mode 100644 arch/kvx/include/asm/futex.h > create mode 100644 arch/kvx/include/asm/hardirq.h > create mode 100644 arch/kvx/include/asm/hugetlb.h > create mode 100644 arch/kvx/include/asm/hw_breakpoint.h > create mode 100644 arch/kvx/include/asm/hw_irq.h > create mode 100644 arch/kvx/include/asm/insns.h > create mode 100644 arch/kvx/include/asm/insns_defs.h > create mode 100644 arch/kvx/include/asm/io.h > create mode 100644 arch/kvx/include/asm/ipi.h > create mode 100644 arch/kvx/include/asm/irqflags.h > create mode 100644 arch/kvx/include/asm/jump_label.h > create mode 100644 arch/kvx/include/asm/l2_cache.h > create mode 100644 arch/kvx/include/asm/l2_cache_defs.h > create mode 100644 arch/kvx/include/asm/linkage.h > create mode 100644 arch/kvx/include/asm/mem_map.h > create mode 100644 arch/kvx/include/asm/mmu.h > create mode 100644 arch/kvx/include/asm/mmu_context.h > create mode 100644 arch/kvx/include/asm/mmu_stats.h > create mode 100644 arch/kvx/include/asm/page.h > create mode 100644 arch/kvx/include/asm/page_size.h > create mode 100644 arch/kvx/include/asm/pci.h > create mode 100644 arch/kvx/include/asm/perf_event.h > create mode 100644 arch/kvx/include/asm/pgalloc.h > create mode 100644 arch/kvx/include/asm/pgtable-bits.h > create mode 100644 arch/kvx/include/asm/pgtable.h > create mode 100644 arch/kvx/include/asm/privilege.h > create mode 100644 arch/kvx/include/asm/processor.h > create mode 100644 arch/kvx/include/asm/ptrace.h > create mode 100644 arch/kvx/include/asm/pwr_ctrl.h > create mode 100644 arch/kvx/include/asm/rm_fw.h > create mode 100644 arch/kvx/include/asm/sections.h > create mode 100644 arch/kvx/include/asm/setup.h > create mode 100644 arch/kvx/include/asm/sfr.h > create mode 100644 arch/kvx/include/asm/sfr_defs.h > create mode 100644 arch/kvx/include/asm/smp.h > create mode 100644 arch/kvx/include/asm/sparsemem.h > create mode 100644 arch/kvx/include/asm/spinlock.h > create mode 100644 arch/kvx/include/asm/spinlock_types.h > create mode 100644 arch/kvx/include/asm/stackprotector.h > create mode 100644 arch/kvx/include/asm/stacktrace.h > create mode 100644 arch/kvx/include/asm/string.h > create mode 100644 arch/kvx/include/asm/swab.h > create mode 100644 arch/kvx/include/asm/switch_to.h > create mode 100644 arch/kvx/include/asm/symbols.h > create mode 100644 arch/kvx/include/asm/sys_arch.h > create mode 100644 arch/kvx/include/asm/syscall.h > create mode 100644 arch/kvx/include/asm/syscalls.h > create mode 100644 arch/kvx/include/asm/thread_info.h > create mode 100644 arch/kvx/include/asm/timex.h > create mode 100644 arch/kvx/include/asm/tlb.h > create mode 100644 arch/kvx/include/asm/tlb_defs.h > create mode 100644 arch/kvx/include/asm/tlbflush.h > create mode 100644 arch/kvx/include/asm/traps.h > create mode 100644 arch/kvx/include/asm/types.h > create mode 100644 arch/kvx/include/asm/uaccess.h > create mode 100644 arch/kvx/include/asm/unistd.h > create mode 100644 arch/kvx/include/asm/vermagic.h > create mode 100644 arch/kvx/include/asm/vmalloc.h > create mode 100644 arch/kvx/include/uapi/asm/Kbuild > create mode 100644 arch/kvx/include/uapi/asm/bitsperlong.h > create mode 100644 arch/kvx/include/uapi/asm/byteorder.h > create mode 100644 arch/kvx/include/uapi/asm/cachectl.h > create mode 100644 arch/kvx/include/uapi/asm/ptrace.h > create mode 100644 arch/kvx/include/uapi/asm/sigcontext.h > create mode 100644 arch/kvx/include/uapi/asm/unistd.h > create mode 100644 arch/kvx/kernel/Makefile > create mode 100644 arch/kvx/kernel/asm-offsets.c > create mode 100644 arch/kvx/kernel/break_hook.c > create mode 100644 arch/kvx/kernel/common.c > create mode 100644 arch/kvx/kernel/cpuinfo.c > create mode 100644 arch/kvx/kernel/dame_handler.c > create mode 100644 arch/kvx/kernel/debug.c > create mode 100644 arch/kvx/kernel/entry.S > create mode 100644 arch/kvx/kernel/ftrace.c > create mode 100644 arch/kvx/kernel/head.S > create mode 100644 arch/kvx/kernel/hw_breakpoint.c > create mode 100644 arch/kvx/kernel/insns.c > create mode 100644 arch/kvx/kernel/io.c > create mode 100644 arch/kvx/kernel/irq.c > create mode 100644 arch/kvx/kernel/jump_label.c > create mode 100644 arch/kvx/kernel/kvx_ksyms.c > create mode 100644 arch/kvx/kernel/l2_cache.c > create mode 100644 arch/kvx/kernel/mcount.S > create mode 100644 arch/kvx/kernel/module.c > create mode 100644 arch/kvx/kernel/perf_event.c > create mode 100644 arch/kvx/kernel/process.c > create mode 100644 arch/kvx/kernel/prom.c > create mode 100644 arch/kvx/kernel/ptrace.c > create mode 100644 arch/kvx/kernel/reset.c > create mode 100644 arch/kvx/kernel/return_address.c > create mode 100644 arch/kvx/kernel/setup.c > create mode 100644 arch/kvx/kernel/signal.c > create mode 100644 arch/kvx/kernel/smp.c > create mode 100644 arch/kvx/kernel/smpboot.c > create mode 100644 arch/kvx/kernel/stacktrace.c > create mode 100644 arch/kvx/kernel/sys_kvx.c > create mode 100644 arch/kvx/kernel/syscall_table.c > create mode 100644 arch/kvx/kernel/time.c > create mode 100644 arch/kvx/kernel/traps.c > create mode 100644 arch/kvx/kernel/vdso.c > create mode 100644 arch/kvx/kernel/vmlinux.lds.S > create mode 100644 arch/kvx/lib/Makefile > create mode 100644 arch/kvx/lib/clear_page.S > create mode 100644 arch/kvx/lib/copy_page.S > create mode 100644 arch/kvx/lib/delay.c > create mode 100644 arch/kvx/lib/memcpy.c > create mode 100644 arch/kvx/lib/memset.S > create mode 100644 arch/kvx/lib/strlen.S > create mode 100644 arch/kvx/lib/usercopy.S > create mode 100644 arch/kvx/mm/Makefile > create mode 100644 arch/kvx/mm/cacheflush.c > create mode 100644 arch/kvx/mm/dma-mapping.c > create mode 100644 arch/kvx/mm/extable.c > create mode 100644 arch/kvx/mm/fault.c > create mode 100644 arch/kvx/mm/hugetlbpage.c > create mode 100644 arch/kvx/mm/init.c > create mode 100644 arch/kvx/mm/kernel_rwx.c > create mode 100644 arch/kvx/mm/mmap.c > create mode 100644 arch/kvx/mm/mmu.c > create mode 100644 arch/kvx/mm/mmu_stats.c > create mode 100644 arch/kvx/mm/tlb.c > create mode 100644 arch/kvx/platform/Makefile > create mode 100644 arch/kvx/platform/ipi.c > create mode 100644 arch/kvx/platform/pwr_ctrl.c > create mode 100644 drivers/irqchip/irq-kvx-apic-gic.c > create mode 100644 drivers/irqchip/irq-kvx-apic-mailbox.c > create mode 100644 drivers/irqchip/irq-kvx-core-intc.c > create mode 100644 drivers/irqchip/irq-kvx-itgen.c > create mode 100644 drivers/power/reset/kvx-scall-poweroff.c > create mode 100644 include/linux/irqchip/irq-kvx-apic-gic.h > create mode 100644 include/linux/irqchip/irq-kvx-apic-mailbox.h > create mode 100644 include/linux/irqchip/irq-kvx-itgen.h > create mode 100644 scripts/gdb/arch/Makefile > create mode 100644 scripts/gdb/arch/__init__.py > create mode 100644 scripts/gdb/arch/kvx/Makefile > create mode 100644 scripts/gdb/arch/kvx/__init__.py > create mode 100644 scripts/gdb/arch/kvx/constants.py.in > create mode 100644 scripts/gdb/arch/kvx/mmu.py > create mode 100644 scripts/gdb/arch/kvx/page_table_walk.py > > -- > 2.37.2 > > > > >
Hi Jeff, On 1/7/23 07:25, Jeff Xie wrote: > Hi, > > On Wed, Jan 4, 2023 at 1:01 AM Yann Sionneau <ysionneau@kalray.eu> wrote: >> [snip] >> >> A kvx toolchain can be built using: >> # install dependencies: texinfo bison flex libgmp-dev libmpc-dev libmpfr-dev >> $ git clone https://github.com/kalray/build-scripts >> $ cd build-scripts >> $ source last.refs >> $ ./build-kvx-xgcc.sh output > I would like to build the kvx-xgcc to compile and test the linux > kernel, but it reported a compile error. > I wonder what version of gcc you are using. > > My build environment: > VERSION="20.04.2 LTS (Focal Fossa)" > gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04) > > > Compile error: > $ ./build-kvx-xgcc.sh output > > ../../binutils/libiberty/fibheap.c: In function ‘fibheap_replace_key_data’: > ../../binutils/libiberty/fibheap.c:38:24: error: ‘LONG_MIN’ undeclared > (first use in this function) > 38 | #define FIBHEAPKEY_MIN LONG_MIN > | ^~~~~~~~ > [snip] What SHA1 of https://github.com/kalray/build-scripts are you using? We are building our toolchain on Ubuntu 18.04 / 20.04 and 22.04 without issues, I don't understand why it does not work for you, although indeed the error log you are having pops out on my search engine and seems to be some well known issue. If the build-script does not work for you, you can still use the pre-built toolchains generated by the GitHub automated actions: https://github.com/kalray/build-scripts/releases/tag/v4.11.1 ("latest" means 22.04) I hope it will work for you. Regards,
On Mon, Jan 9, 2023 at 9:21 PM Yann Sionneau <ysionneau@kalray.eu> wrote: > > Hi Jeff, > > On 1/7/23 07:25, Jeff Xie wrote: > > Hi, > > > > On Wed, Jan 4, 2023 at 1:01 AM Yann Sionneau <ysionneau@kalray.eu> wrote: > >> [snip] > >> > >> A kvx toolchain can be built using: > >> # install dependencies: texinfo bison flex libgmp-dev libmpc-dev libmpfr-dev > >> $ git clone https://github.com/kalray/build-scripts > >> $ cd build-scripts > >> $ source last.refs > >> $ ./build-kvx-xgcc.sh output > > I would like to build the kvx-xgcc to compile and test the linux > > kernel, but it reported a compile error. > > I wonder what version of gcc you are using. > > > > My build environment: > > VERSION="20.04.2 LTS (Focal Fossa)" > > gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04) > > > > > > Compile error: > > $ ./build-kvx-xgcc.sh output > > > > ../../binutils/libiberty/fibheap.c: In function ‘fibheap_replace_key_data’: > > ../../binutils/libiberty/fibheap.c:38:24: error: ‘LONG_MIN’ undeclared > > (first use in this function) > > 38 | #define FIBHEAPKEY_MIN LONG_MIN > > | ^~~~~~~~ > > [snip] > > What SHA1 of https://github.com/kalray/build-scripts are you using? I have executed the "source last.refs" > We are building our toolchain on Ubuntu 18.04 / 20.04 and 22.04 without > issues, I don't understand why it does not work for you, although indeed > the error log you are having pops out on my search engine and seems to > be some well known issue. Yes, there are many answers on the web, but none of them solve this problem. > If the build-script does not work for you, you can still use the > pre-built toolchains generated by the GitHub automated actions: > https://github.com/kalray/build-scripts/releases/tag/v4.11.1 ("latest" > means 22.04) Thanks, this is the final solution ;-) > > I hope it will work for you. > > Regards, > > -- > > Yann > > > > >
Hi Jeff, On 1/9/23 16:11, Jeff Xie wrote: > On Mon, Jan 9, 2023 at 9:21 PM Yann Sionneau <ysionneau@kalray.eu> wrote: >> Hi Jeff, >> >> On 1/7/23 07:25, Jeff Xie wrote: >>> Hi, >>> >>> On Wed, Jan 4, 2023 at 1:01 AM Yann Sionneau <ysionneau@kalray.eu> wrote: >>>> [snip] >>>> >>>> A kvx toolchain can be built using: >>>> # install dependencies: texinfo bison flex libgmp-dev libmpc-dev libmpfr-dev >>>> $ git clone https://github.com/kalray/build-scripts >>>> $ cd build-scripts >>>> $ source last.refs >>>> $ ./build-kvx-xgcc.sh output >>> I would like to build the kvx-xgcc to compile and test the linux >>> kernel, but it reported a compile error. >>> I wonder what version of gcc you are using. >>> >>> My build environment: >>> VERSION="20.04.2 LTS (Focal Fossa)" >>> gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04) >>> >>> >>> Compile error: >>> $ ./build-kvx-xgcc.sh output >>> >>> ../../binutils/libiberty/fibheap.c: In function ‘fibheap_replace_key_data’: >>> ../../binutils/libiberty/fibheap.c:38:24: error: ‘LONG_MIN’ undeclared >>> (first use in this function) >>> 38 | #define FIBHEAPKEY_MIN LONG_MIN >>> | ^~~~~~~~ >>> [snip] >> What SHA1 of https://github.com/kalray/build-scripts are you using? > I have executed the "source last.refs" I was referring to the SHA1 of the repo itself (build-scripts). `last.refs` is a symbolic link which can point to several releases, depending on "when" you did the clone. I am asking this because we recently published new toolchains. I want to make sure which one you are trying to build. >> We are building our toolchain on Ubuntu 18.04 / 20.04 and 22.04 without >> issues, I don't understand why it does not work for you, although indeed >> the error log you are having pops out on my search engine and seems to >> be some well known issue. > Yes, there are many answers on the web, but none of them solve this problem. > >> If the build-script does not work for you, you can still use the >> pre-built toolchains generated by the GitHub automated actions: >> https://github.com/kalray/build-scripts/releases/tag/v4.11.1 ("latest" >> means 22.04) > Thanks, this is the final solution ;-) Good to see it helped :) Regards,
On Mon, Jan 9, 2023 at 11:30 PM Yann Sionneau <ysionneau@kalray.eu> wrote: > > Hi Jeff, > > On 1/9/23 16:11, Jeff Xie wrote: > > On Mon, Jan 9, 2023 at 9:21 PM Yann Sionneau <ysionneau@kalray.eu> wrote: > >> Hi Jeff, > >> > >> On 1/7/23 07:25, Jeff Xie wrote: > >>> Hi, > >>> > >>> On Wed, Jan 4, 2023 at 1:01 AM Yann Sionneau <ysionneau@kalray.eu> wrote: > >>>> [snip] > >>>> > >>>> A kvx toolchain can be built using: > >>>> # install dependencies: texinfo bison flex libgmp-dev libmpc-dev libmpfr-dev > >>>> $ git clone https://github.com/kalray/build-scripts > >>>> $ cd build-scripts > >>>> $ source last.refs > >>>> $ ./build-kvx-xgcc.sh output > >>> I would like to build the kvx-xgcc to compile and test the linux > >>> kernel, but it reported a compile error. > >>> I wonder what version of gcc you are using. > >>> > >>> My build environment: > >>> VERSION="20.04.2 LTS (Focal Fossa)" > >>> gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04) > >>> > >>> > >>> Compile error: > >>> $ ./build-kvx-xgcc.sh output > >>> > >>> ../../binutils/libiberty/fibheap.c: In function ‘fibheap_replace_key_data’: > >>> ../../binutils/libiberty/fibheap.c:38:24: error: ‘LONG_MIN’ undeclared > >>> (first use in this function) > >>> 38 | #define FIBHEAPKEY_MIN LONG_MIN > >>> | ^~~~~~~~ > >>> [snip] > >> What SHA1 of https://github.com/kalray/build-scripts are you using? > > I have executed the "source last.refs" > > I was referring to the SHA1 of the repo itself (build-scripts). > > `last.refs` is a symbolic link which can point to several releases, > depending on "when" you did the clone. > > I am asking this because we recently published new toolchains. > > I want to make sure which one you are trying to build. Unfortunately I deleted this repo a few minutes before you asked me ;-( But I remember that I cloned this repo two days ago. it should be: last.refs -> refs/4.11.0.refs > >> We are building our toolchain on Ubuntu 18.04 / 20.04 and 22.04 without > >> issues, I don't understand why it does not work for you, although indeed > >> the error log you are having pops out on my search engine and seems to > >> be some well known issue. > > Yes, there are many answers on the web, but none of them solve this problem. > > > >> If the build-script does not work for you, you can still use the > >> pre-built toolchains generated by the GitHub automated actions: > >> https://github.com/kalray/build-scripts/releases/tag/v4.11.1 ("latest" > >> means 22.04) > > Thanks, this is the final solution ;-) > Good to see it helped :) > > Regards, > > -- > > Yann > > > > >
On Mon, Jan 9, 2023 at 11:53 PM Jeff Xie <xiehuan09@gmail.com> wrote: > > On Mon, Jan 9, 2023 at 11:30 PM Yann Sionneau <ysionneau@kalray.eu> wrote: > > > > Hi Jeff, > > > > On 1/9/23 16:11, Jeff Xie wrote: > > > On Mon, Jan 9, 2023 at 9:21 PM Yann Sionneau <ysionneau@kalray.eu> wrote: > > >> Hi Jeff, > > >> > > >> On 1/7/23 07:25, Jeff Xie wrote: > > >>> Hi, > > >>> > > >>> On Wed, Jan 4, 2023 at 1:01 AM Yann Sionneau <ysionneau@kalray.eu> wrote: > > >>>> [snip] > > >>>> > > >>>> A kvx toolchain can be built using: > > >>>> # install dependencies: texinfo bison flex libgmp-dev libmpc-dev libmpfr-dev > > >>>> $ git clone https://github.com/kalray/build-scripts > > >>>> $ cd build-scripts > > >>>> $ source last.refs > > >>>> $ ./build-kvx-xgcc.sh output > > >>> I would like to build the kvx-xgcc to compile and test the linux > > >>> kernel, but it reported a compile error. > > >>> I wonder what version of gcc you are using. > > >>> > > >>> My build environment: > > >>> VERSION="20.04.2 LTS (Focal Fossa)" > > >>> gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04) > > >>> > > >>> > > >>> Compile error: > > >>> $ ./build-kvx-xgcc.sh output > > >>> > > >>> ../../binutils/libiberty/fibheap.c: In function ‘fibheap_replace_key_data’: > > >>> ../../binutils/libiberty/fibheap.c:38:24: error: ‘LONG_MIN’ undeclared > > >>> (first use in this function) > > >>> 38 | #define FIBHEAPKEY_MIN LONG_MIN > > >>> | ^~~~~~~~ > > >>> [snip] > > >> What SHA1 of https://github.com/kalray/build-scripts are you using? > > > I have executed the "source last.refs" > > > > I was referring to the SHA1 of the repo itself (build-scripts). > > > > `last.refs` is a symbolic link which can point to several releases, > > depending on "when" you did the clone. > > > > I am asking this because we recently published new toolchains. > > > > I want to make sure which one you are trying to build. > > Unfortunately I deleted this repo a few minutes before you asked me ;-( > But I remember that I cloned this repo two days ago. > it should be: last.refs -> refs/4.11.0.refs It should be my own environmental problem. I reinstalled the system once and it has been able to compile normally ;-) In the past few days, I have reviewed almost all the codes, which is very meaningful for me to learn, thank you team. > > > >> We are building our toolchain on Ubuntu 18.04 / 20.04 and 22.04 without > > >> issues, I don't understand why it does not work for you, although indeed > > >> the error log you are having pops out on my search engine and seems to > > >> be some well known issue. > > > Yes, there are many answers on the web, but none of them solve this problem. > > > > > >> If the build-script does not work for you, you can still use the > > >> pre-built toolchains generated by the GitHub automated actions: > > >> https://github.com/kalray/build-scripts/releases/tag/v4.11.1 ("latest" > > >> means 22.04) > > > Thanks, this is the final solution ;-) > > Good to see it helped :) > > > > Regards, > > > > -- > > > > Yann > > > > > > > > > > > > > -- > Thanks, > JeffXie -- Thanks, JeffXie