* [RFC PATCH 03/25] kvx: Add build infrastructure
2023-01-03 16:43 [RFC PATCH 00/25] Upstream kvx Linux port Yann Sionneau
@ 2023-01-03 16:43 ` Yann Sionneau
2023-01-03 17:29 ` Randy Dunlap
2023-01-03 20:52 ` [RFC PATCH 00/25] Upstream kvx Linux port Rob Herring
` (2 subsequent siblings)
3 siblings, 1 reply; 15+ messages in thread
From: Yann Sionneau @ 2023-01-03 16:43 UTC (permalink / raw)
Cc: Yann Sionneau, linux-kernel, bpf, Clement Leger,
Guillaume Thouvenin, Jonathan Borne, Jules Maselbas,
Julian Vetter, Marc Poulhiès, Marius Gligor, Samuel Jones,
Vincent Chardon
Add Kbuild, Makefile, Kconfig and link script for kvx build infrastructure.
CC: linux-kernel@vger.kernel.org
CC: bpf@vger.kernel.org
Co-developed-by: Clement Leger <clement.leger@bootlin.com>
Signed-off-by: Clement Leger <clement.leger@bootlin.com>
Co-developed-by: Guillaume Thouvenin <gthouvenin@kalray.eu>
Signed-off-by: Guillaume Thouvenin <gthouvenin@kalray.eu>
Co-developed-by: Jonathan Borne <jborne@kalray.eu>
Signed-off-by: Jonathan Borne <jborne@kalray.eu>
Co-developed-by: Jules Maselbas <jmaselbas@kalray.eu>
Signed-off-by: Jules Maselbas <jmaselbas@kalray.eu>
Co-developed-by: Julian Vetter <jvetter@kalray.eu>
Signed-off-by: Julian Vetter <jvetter@kalray.eu>
Co-developed-by: Marc Poulhiès <dkm@kataplop.net>
Signed-off-by: Marc Poulhiès <dkm@kataplop.net>
Co-developed-by: Marius Gligor <mgligor@kalray.eu>
Signed-off-by: Marius Gligor <mgligor@kalray.eu>
Co-developed-by: Samuel Jones <sjones@kalray.eu>
Signed-off-by: Samuel Jones <sjones@kalray.eu>
Co-developed-by: Vincent Chardon <vincent.chardon@elsys-design.com>
Signed-off-by: Vincent Chardon <vincent.chardon@elsys-design.com>
Co-developed-by: Yann Sionneau <ysionneau@kalray.eu>
Signed-off-by: Yann Sionneau <ysionneau@kalray.eu>
---
arch/kvx/Kconfig | 249 +++++++++++++++++++++++++++++++
arch/kvx/Kconfig.debug | 70 +++++++++
arch/kvx/Makefile | 52 +++++++
arch/kvx/include/asm/Kbuild | 20 +++
arch/kvx/include/uapi/asm/Kbuild | 1 +
arch/kvx/kernel/Makefile | 27 ++++
arch/kvx/kernel/kvx_ksyms.c | 24 +++
arch/kvx/kernel/vmlinux.lds.S | 173 +++++++++++++++++++++
arch/kvx/lib/Makefile | 6 +
arch/kvx/mm/Makefile | 10 ++
arch/kvx/platform/Makefile | 7 +
11 files changed, 639 insertions(+)
create mode 100644 arch/kvx/Kconfig
create mode 100644 arch/kvx/Kconfig.debug
create mode 100644 arch/kvx/Makefile
create mode 100644 arch/kvx/include/asm/Kbuild
create mode 100644 arch/kvx/include/uapi/asm/Kbuild
create mode 100644 arch/kvx/kernel/Makefile
create mode 100644 arch/kvx/kernel/kvx_ksyms.c
create mode 100644 arch/kvx/kernel/vmlinux.lds.S
create mode 100644 arch/kvx/lib/Makefile
create mode 100644 arch/kvx/mm/Makefile
create mode 100644 arch/kvx/platform/Makefile
diff --git a/arch/kvx/Kconfig b/arch/kvx/Kconfig
new file mode 100644
index 000000000000..8e8820c5c860
--- /dev/null
+++ b/arch/kvx/Kconfig
@@ -0,0 +1,249 @@
+#
+# For a description of the syntax of this configuration file,
+# see Documentation/kbuild/kconfig-language.txt.
+#
+
+config 64BIT
+ def_bool y
+
+config GENERIC_CALIBRATE_DELAY
+ def_bool y
+
+config FIX_EARLYCON_MEM
+ def_bool y
+
+config MMU
+ def_bool y
+
+config KALLSYMS_BASE_RELATIVE
+ def_bool n
+
+config GENERIC_CSUM
+ def_bool y
+
+config RWSEM_GENERIC_SPINLOCK
+ def_bool y
+
+config GENERIC_HWEIGHT
+ def_bool y
+
+config ARCH_MMAP_RND_BITS_MAX
+ default 24
+
+config ARCH_MMAP_RND_BITS_MIN
+ default 18
+
+config STACKTRACE_SUPPORT
+ def_bool y
+
+config LOCKDEP_SUPPORT
+ def_bool y
+
+config GENERIC_BUG
+ def_bool y
+ depends on BUG
+
+config KVX_4K_PAGES
+ def_bool y
+
+config KVX
+ def_bool y
+ select ARCH_CLOCKSOURCE_DATA
+ select ARCH_DMA_ADDR_T_64BIT
+ select ARCH_HAS_DEVMEM_IS_ALLOWED
+ select ARCH_HAS_DMA_PREP_COHERENT
+ select ARCH_HAS_ELF_RANDOMIZE
+ select ARCH_HAS_PTE_SPECIAL
+ select ARCH_HAS_SETUP_DMA_OPS if IOMMU_SUPPORT
+ select ARCH_HAS_STRICT_KERNEL_RWX
+ select ARCH_HAS_STRICT_MODULE_RWX
+ select ARCH_HAS_SYNC_DMA_FOR_DEVICE
+ select ARCH_HAS_SYNC_DMA_FOR_CPU
+ select ARCH_HAS_TEARDOWN_DMA_OPS if IOMMU_SUPPORT
+ select ARCH_OPTIONAL_KERNEL_RWX_DEFAULT
+ select ARCH_SUPPORTS_HUGETLBFS
+ select ARCH_USE_QUEUED_SPINLOCKS
+ select ARCH_USE_QUEUED_RWLOCKS
+ select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
+ select ARCH_WANT_FRAME_POINTERS
+ select CLKSRC_OF
+ select COMMON_CLK
+ select DMA_DIRECT_REMAP
+ select GENERIC_ALLOCATOR
+ select GENERIC_CLOCKEVENTS
+ select GENERIC_CLOCKEVENTS
+ select GENERIC_CPU_DEVICES
+ select GENERIC_IOMAP
+ select GENERIC_IOREMAP
+ select GENERIC_IRQ_CHIP
+ select GENERIC_IRQ_PROBE
+ select GENERIC_IRQ_SHOW
+ select GENERIC_SCHED_CLOCK
+ select HAVE_ARCH_AUDITSYSCALL
+ select HAVE_ARCH_BITREVERSE
+ select HAVE_ARCH_JUMP_LABEL
+ select HAVE_ARCH_MMAP_RND_BITS
+ select HAVE_ARCH_TRACEHOOK
+ select HAVE_ARCH_TRANSPARENT_HUGEPAGE
+ select HAVE_ASM_MODVERSIONS
+ select HAVE_DEBUG_KMEMLEAK
+ select HAVE_DYNAMIC_FTRACE
+ select HAVE_EFFICIENT_UNALIGNED_ACCESS
+ select HAVE_FTRACE_MCOUNT_RECORD
+ select HAVE_FUTEX_CMPXCHG if FUTEX
+ select HAVE_FUNCTION_TRACER
+ select HAVE_FUNCTION_GRAPH_TRACER
+ select HAVE_HW_BREAKPOINT
+ select HAVE_IOREMAP_PROT
+ select HAVE_MEMBLOCK_NODE_MAP
+ select HAVE_PCI
+ select HAVE_PERF_EVENTS
+ select HAVE_STACKPROTECTOR
+ select HAVE_SYSCALL_TRACEPOINTS
+ select IOMMU_DMA if IOMMU_SUPPORT
+ select KVX_APIC_GIC
+ select KVX_APIC_MAILBOX
+ select KVX_CORE_INTC
+ select KVX_ITGEN
+ select KVX_WATCHDOG
+ select MODULES_USE_ELF_RELA
+ select OF
+ select OF_EARLY_FLATTREE
+ select OF_RESERVED_MEM
+ select PERF_EVENTS
+ select PCI_DOMAINS_GENERIC if PCI
+ select SPARSE_IRQ
+ select SYSCTL_EXCEPTION_TRACE
+ select THREAD_INFO_IN_TASK
+ select TIMER_OF
+ select TRACE_IRQFLAGS_SUPPORT
+ select WATCHDOG
+ select ZONE_DMA32
+
+config PGTABLE_LEVELS
+ int
+ default 3
+
+config HAVE_KPROBES
+ def_bool n
+
+menu "System setup"
+
+config POISON_INITMEM
+ bool "Enable to poison freed initmem"
+ default y
+ help
+ In order to debug initmem, using poison allows to verify if
+ some data/code is stille using them. Enable this for debug
+ purposes
+
+config KVX_PHYS_OFFSET
+ hex "RAM address of memory base"
+ default 0x100000000
+
+config KVX_PAGE_OFFSET
+ hex "kernel virtual address of memory base"
+ default 0xFFFFFF8000000000
+
+config ARCH_FLATMEM_ENABLE
+ def_bool y
+
+config ARCH_SPARSEMEM_ENABLE
+ def_bool y
+
+config ARCH_SPARSEMEM_DEFAULT
+ def_bool ARCH_SPARSEMEM_ENABLE
+
+config ARCH_SELECT_MEMORY_MODEL
+ def_bool ARCH_SPARSEMEM_ENABLE
+
+config STACK_MAX_DEPTH_TO_PRINT
+ int "Maximum depth of stack to print"
+ range 1 128
+ default "24"
+
+config L2_CACHE
+ bool "Enable l2 cache driver"
+ default y
+ help
+ Enable L2 cache driver in order to handle it. This driver can be
+ disabled to eliminate any overhead related to L2 cache
+ inval/writeback. Note that L2 cache is mandatory for SMP in order
+ to maintain coherency on DDR between all PEs.
+
+config SECURE_DAME_HANDLING
+ bool "Secure DAME handling"
+ default y
+ help
+ In order to securely handle Data Asynchronous Memory Errors, we need
+ to do a barrier upon kernel entry when coming from userspace. This
+ barrier guarantee us that any pending DAME will be serviced right
+ away. We also need to do a barrier when returning from kernel to user.
+ This way, if the kernel or the user triggered a DAME, it will be
+ serviced by knowing we are coming from kernel or user and avoid
+ pulling the wrong lever (panic for kernel or sigfault for user).
+ This can be costly but ensure that user cannot interfere with kernel.
+ /!\ Do not disable unless you want to open a giant breach between
+ user and kernel /!\
+
+config CACHECTL_UNSAFE_PHYS_OPERATIONS
+ bool "Enable cachectl syscall unsafe physical operations"
+ default n
+ help
+ Enable cachectl syscall to allow writebacking/invalidating ranges
+ based on physical addresses. These operations requires the
+ CAP_SYS_ADMIN capability
+
+config ENABLE_TCA
+ bool "Enable TCA coprocessor support"
+ default y
+ help
+ This option enables TCA coprocessor support. It will allow the user to
+ use the coprocessor and save registers on context switch if used.
+ Registers content will also be cleared when switching.
+
+config SMP
+ bool "Symmetric multi-processing support"
+ default n
+ select GENERIC_SMP_IDLE_THREAD
+ select GENERIC_IRQ_IPI
+ select IRQ_DOMAIN_HIERARCHY
+ select IRQ_DOMAIN
+ select L2_CACHE
+ help
+ This enables support for systems with more than one CPU. If you have
+ a system with only one CPU, say N. If you have a system with more
+ than one CPU, say Y.
+
+ If you say N here, the kernel will run on uni- and multiprocessor
+ machines, but will use only one CPU of a multiprocessor machine. If
+ you say Y here, the kernel will run on many, but not all,
+ uniprocessor machines. On a uniprocessor machine, the kernel
+ will run faster if you say N here.
+
+config NR_CPUS
+ int "Maximum number of CPUs"
+ range 1 16
+ default "16"
+ depends on SMP
+ help
+ Kalray support can handle a maximum of 16 CPUs.
+
+config KVX_PAGE_SHIFT
+ int
+ default 12
+
+config CMDLINE
+ string "Default kernel command string"
+ default ""
+ help
+ On some architectures there is currently no way for the boot loader
+ to pass arguments to the kernel. For these architectures, you should
+ supply some command-line options at build time by entering them
+ here.
+
+endmenu
+
+menu "Kernel Features"
+source "kernel/Kconfig.hz"
+endmenu
diff --git a/arch/kvx/Kconfig.debug b/arch/kvx/Kconfig.debug
new file mode 100644
index 000000000000..027e919a1e14
--- /dev/null
+++ b/arch/kvx/Kconfig.debug
@@ -0,0 +1,70 @@
+menu "KVX debugging"
+
+config KVX_DEBUG_ASN
+ bool "Check ASN before writing TLB entry"
+ default n
+ help
+ This option allows to check if the ASN of the current
+ process is matching the ASN found in MMC. If it is not the
+ case an error will be printed.
+
+config KVX_DEBUG_TLB_WRITE
+ bool "Enable TLBs write checks"
+ default n
+ help
+ Enabling this option will enable TLB access checks. This is
+ particularly helpful when modifying the assembly code responsible
+ of TLB refill. If set, mmc.e will be checked each time the tlb are
+ written and a panic will be thrown on error.
+
+config KVX_DEBUG_TLB_ACCESS
+ bool "Enable TLBs accesses logging"
+ default n
+ help
+ Enabling this option will enable TLB entry manipulation logging.
+ Each time an entry will be added to the TLBs, it will be logged in
+ an array readable via gdb scripts. This can be useful to understand
+ strange crashes related to suspicious virtual/physical addresses.
+
+config KVX_DEBUG_TLB_ACCESS_BITS
+ int "Number of bits used as index of entries in log table"
+ default 12
+ depends on KVX_DEBUG_TLB_ACCESS
+ help
+ Set the number of bits used as index of entries that will be logged
+ in a ring buffer called kvx_tlb_access. One entry in the table
+ contains registers TEL, TEH and MMC. It also logs the type of the
+ operations (0:read, 1:write, 2:probe). Buffer is per CPU. For one
+ entry 24 bytes are used. So by default it uses 96Ko of memory per
+ CPU to store 2^12 (4096) entries.
+
+config KVX_MMU_STATS
+ bool "Register mmu stats debugfs entries"
+ default n
+ select DEBUG_FS
+ help
+ Enable debugfs attribute which will allow inspecting various metric
+ regarding MMU:
+ - Number of nomapping traps handled
+ - avg/min/max time for nomapping refill (user/kernel)
+
+config DEBUG_EXCEPTION_STACK
+ bool "Enable exception stack debugging"
+ default n
+ help
+ Enable stack check debugging when entering/exiting
+ exception handlers.
+ This can be particularly helpful after modifying stack
+ handling to see if stack when exiting is the same as the one
+ when entering exception handler.
+
+config DEBUG_SFR_SET_MASK
+ bool "Enable sfr set_mask debugging"
+ default n
+ help
+ Verify that values written using kvx_sfr_set_mask are matching the
+ mask. This ensure that no extra bits of sfr will be overridden by some
+ incorrectly truncated values. This can lead to huge problems by
+ modifying important bits in system registers.
+
+endmenu
diff --git a/arch/kvx/Makefile b/arch/kvx/Makefile
new file mode 100644
index 000000000000..b9da5017cf2a
--- /dev/null
+++ b/arch/kvx/Makefile
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Copyright (C) 2018-2023 Kalray Inc.
+
+ifeq ($(CROSS_COMPILE),)
+CROSS_COMPILE := kvx-elf-
+endif
+
+KBUILD_DEFCONFIG := default_defconfig
+
+LDFLAGS_vmlinux := -X
+OBJCOPYFLAGS := -O binary -R .comment -R .note -R .bootloader -S
+
+# Link with libgcc to get __div* builtins.
+LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) --print-libgcc-file-name)
+
+DEFAULT_OPTS := -nostdlib -fno-builtin -march=kv3-1
+KBUILD_CFLAGS += $(DEFAULT_OPTS)
+KBUILD_AFLAGS += $(DEFAULT_OPTS)
+KBUILD_CFLAGS_MODULE += -mfarcall
+
+KBUILD_LDFLAGS += -m elf64kvx
+
+head-y := arch/kvx/kernel/head.o
+libs-y += $(LIBGCC)
+libs-y += arch/kvx/lib/
+core-y += arch/kvx/kernel/ \
+ arch/kvx/mm/ \
+ arch/kvx/platform/
+# Final targets
+all: vmlinux
+
+BOOT_TARGETS = bImage bImage.bin bImage.bz2 bImage.gz bImage.lzma bImage.lzo
+
+$(BOOT_TARGETS): vmlinux
+ $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
+
+install:
+ $(Q)$(MAKE) $(build)=$(boot) BOOTIMAGE=$(KBUILD_IMAGE) install
+
+define archhelp
+ echo '* bImage - Alias to selected kernel format (bImage.gz by default)'
+ echo ' bImage.bin - Uncompressed Kernel-only image for barebox (arch/$(ARCH)/boot/bImage.bin)'
+ echo ' bImage.bz2 - Kernel-only image for barebox (arch/$(ARCH)/boot/bImage.bz2)'
+ echo '* bImage.gz - Kernel-only image for barebox (arch/$(ARCH)/boot/bImage.gz)'
+ echo ' bImage.lzma - Kernel-only image for barebox (arch/$(ARCH)/boot/bImage.lzma)'
+ echo ' bImage.lzo - Kernel-only image for barebox (arch/$(ARCH)/boot/bImage.lzo)'
+ echo ' install - Install kernel using'
+ echo ' (your) ~/bin/$(INSTALLKERNEL) or'
+ echo ' (distribution) PATH: $(INSTALLKERNEL) or'
+ echo ' install to $$(INSTALL_PATH)'
+endef
diff --git a/arch/kvx/include/asm/Kbuild b/arch/kvx/include/asm/Kbuild
new file mode 100644
index 000000000000..ea73552faa10
--- /dev/null
+++ b/arch/kvx/include/asm/Kbuild
@@ -0,0 +1,20 @@
+generic-y += asm-offsets.h
+generic-y += clkdev.h
+generic-y += auxvec.h
+generic-y += bpf_perf_event.h
+generic-y += cmpxchg-local.h
+generic-y += errno.h
+generic-y += extable.h
+generic-y += export.h
+generic-y += kvm_para.h
+generic-y += mcs_spinlock.h
+generic-y += mman.h
+generic-y += param.h
+generic-y += qrwlock.h
+generic-y += qspinlock.h
+generic-y += rwsem.h
+generic-y += sockios.h
+generic-y += stat.h
+generic-y += statfs.h
+generic-y += ucontext.h
+generic-y += user.h
diff --git a/arch/kvx/include/uapi/asm/Kbuild b/arch/kvx/include/uapi/asm/Kbuild
new file mode 100644
index 000000000000..8b137891791f
--- /dev/null
+++ b/arch/kvx/include/uapi/asm/Kbuild
@@ -0,0 +1 @@
+
diff --git a/arch/kvx/kernel/Makefile b/arch/kvx/kernel/Makefile
new file mode 100644
index 000000000000..d155fef62614
--- /dev/null
+++ b/arch/kvx/kernel/Makefile
@@ -0,0 +1,27 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Copyright (C) 2019-2023 Kalray Inc.
+#
+
+ifdef CONFIG_FUNCTION_TRACER
+CFLAGS_REMOVE_ftrace.o = $(CC_FLAGS_FTRACE)
+CFLAGS_REMOVE_insns.o = $(CC_FLAGS_FTRACE)
+endif
+
+CFLAGS_REMOVE_return_address.o = $(CC_FLAGS_FTRACE)
+
+obj-y := head.o setup.o process.o traps.o common.o time.o prom.o kvx_ksyms.o \
+ irq.o cpuinfo.o ptrace.o entry.o syscall_table.o signal.o sys_kvx.o \
+ stacktrace.o dame_handler.o vdso.o perf_event.o return_address.o \
+ insns.o break_hook.o reset.o io.o debug.o
+
+obj-$(CONFIG_JUMP_LABEL) += jump_label.o
+obj-$(CONFIG_SMP) += smp.o smpboot.o
+obj-$(CONFIG_HAVE_HW_BREAKPOINT) += hw_breakpoint.o
+obj-$(CONFIG_MODULES) += module.o
+obj-$(CONFIG_KGDB) += kgdb.o
+CFLAGS_module.o += -Wstrict-overflow -fstrict-overflow
+obj-$(CONFIG_L2_CACHE) += l2_cache.o
+obj-$(CONFIG_FUNCTION_TRACER) += mcount.o ftrace.o
+
+extra-y += vmlinux.lds
diff --git a/arch/kvx/kernel/kvx_ksyms.c b/arch/kvx/kernel/kvx_ksyms.c
new file mode 100644
index 000000000000..18990aaf259f
--- /dev/null
+++ b/arch/kvx/kernel/kvx_ksyms.c
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * derived from arch/nios2/kernel/nios2_ksyms.c
+ *
+ * Copyright (C) 2017-2023 Kalray Inc.
+ * Author(s): Clement Leger
+ * Yann Sionneau
+ */
+
+#include <linux/kernel.h>
+#include <linux/export.h>
+
+/*
+ * libgcc functions - functions that are used internally by the
+ * compiler... (prototypes are not correct though, but that
+ * doesn't really matter since they're not versioned).
+ */
+#define DECLARE_EXPORT(name) extern void name(void); EXPORT_SYMBOL(name)
+
+DECLARE_EXPORT(__moddi3);
+DECLARE_EXPORT(__umoddi3);
+DECLARE_EXPORT(__divdi3);
+DECLARE_EXPORT(__udivdi3);
+DECLARE_EXPORT(__multi3);
diff --git a/arch/kvx/kernel/vmlinux.lds.S b/arch/kvx/kernel/vmlinux.lds.S
new file mode 100644
index 000000000000..74013771ff40
--- /dev/null
+++ b/arch/kvx/kernel/vmlinux.lds.S
@@ -0,0 +1,173 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2017-2023 Kalray Inc.
+ * Author(s): Clement Leger
+ * Guillaume Thouvenin
+ * Marius Gligor
+ * Marc Poulhiès
+ * Yann Sionneau
+ */
+
+#include <asm/thread_info.h>
+#include <asm/asm-offsets.h>
+#include <asm/sys_arch.h>
+#include <asm/cache.h>
+#include <asm/rm_fw.h>
+#include <asm/page.h>
+#include <asm/fixmap.h>
+
+#define BOOT_ENTRY 0x0
+#define DTB_DEFAULT_SIZE (64 * 1024)
+#define RM_FIRMWARE_SIZE (64 * 1024)
+#define RM_FIRMWARE_ADDRESS (64 * 1024)
+
+#define LOAD_OFFSET (PAGE_OFFSET - PHYS_OFFSET)
+#include <asm-generic/vmlinux.lds.h>
+
+OUTPUT_FORMAT("elf64-kvx")
+ENTRY(kvx_start)
+
+#define HANDLER_SECTION(__sec, __name) \
+ __sec ## _ ## __name ## _start = .; \
+ KEEP(*(.##__sec ##.## __name)); \
+ . = __sec ## _ ##__name ## _start + EXCEPTION_STRIDE;
+
+/**
+ * Generate correct section positioning for exception handling
+ * Since we need it twice for early exception handler and normal
+ * exception handler, factorize it here.
+ */
+#define EXCEPTION_SECTIONS(__sec) \
+ __ ## __sec ## _start = ABSOLUTE(.); \
+ HANDLER_SECTION(__sec,debug) \
+ HANDLER_SECTION(__sec,trap) \
+ HANDLER_SECTION(__sec,interrupt) \
+ HANDLER_SECTION(__sec,syscall)
+
+jiffies = jiffies_64;
+SECTIONS
+{
+ . = BOOT_ENTRY;
+ .boot :
+ {
+ __kernel_smem_code_start = .;
+ KEEP(*(.boot.startup));
+ KEEP(*(.boot.*));
+ __kernel_smem_code_end = .;
+ }
+
+ /**
+ * Special section to patch rm_firmware binary after compiling
+ * the kernel.
+ */
+ . = RM_FIRMWARE_ADDRESS;
+ .rm_firmware :
+ {
+ __rm_firmware_start = .;
+ KEEP(*(.rm_firmware.default));
+ /* Force minimum size */
+ . = __rm_firmware_start + RM_FIRMWARE_SIZE;
+ __rm_firmware_end = .;
+
+ /* Registers for RM firmware */
+ . = ALIGN(PAGE_SIZE);
+ __rm_firmware_regs_start = .;
+ /* Force minimum size */
+ . = __rm_firmware_regs_start + RM_FIRMWARE_REGS_SIZE;
+ __rm_firmware_regs_end = .;
+ }
+
+ . = PAGE_OFFSET;
+ _start = .;
+
+ _stext = .;
+ __init_begin = .;
+ __inittext_start = .;
+ .exit.text : AT(ADDR(.exit.text) - LOAD_OFFSET)
+ {
+ EXIT_TEXT
+ }
+
+ .early_exception ALIGN(EXCEPTION_ALIGNMENT) :
+ AT(ADDR(.early_exception) - LOAD_OFFSET)
+ {
+ EXCEPTION_SECTIONS(early_exception)
+ }
+
+ HEAD_TEXT_SECTION
+ INIT_TEXT_SECTION(PAGE_SIZE)
+ . = ALIGN(PAGE_SIZE);
+ __inittext_end = .;
+ __initdata_start = .;
+ INIT_DATA_SECTION(16)
+
+ /* we have to discard exit text and such at runtime, not link time */
+ .exit.data : AT(ADDR(.exit.data) - LOAD_OFFSET)
+ {
+ EXIT_DATA
+ }
+
+ PERCPU_SECTION(L1_CACHE_BYTES)
+ . = ALIGN(PAGE_SIZE);
+ __initdata_end = .;
+ __init_end = .;
+
+ /* Everything below this point will be mapped RO EXEC up to _etext */
+ .text ALIGN(PAGE_SIZE) : AT(ADDR(.text) - LOAD_OFFSET)
+ {
+ _text = .;
+ EXCEPTION_SECTIONS(exception)
+ *(.exception.text)
+ . = ALIGN(PAGE_SIZE);
+ __exception_end = .;
+ TEXT_TEXT
+ SCHED_TEXT
+ CPUIDLE_TEXT
+ LOCK_TEXT
+ KPROBES_TEXT
+ ENTRY_TEXT
+ IRQENTRY_TEXT
+ SOFTIRQENTRY_TEXT
+ *(.fixup)
+ }
+ . = ALIGN(PAGE_SIZE);
+ _etext = .;
+
+ /* Everything below this point will be mapped RO NOEXEC up to _sdata */
+ __rodata_start = .;
+ RO_DATA(PAGE_SIZE)
+ EXCEPTION_TABLE(8)
+ . = ALIGN(32);
+ .dtb : AT(ADDR(.dtb) - LOAD_OFFSET)
+ {
+ __dtb_start = .;
+ . += DTB_DEFAULT_SIZE;
+ __dtb_end = .;
+ }
+ . = ALIGN(PAGE_SIZE);
+ __rodata_end = .;
+
+ /* Everything below this point will be mapped RW NOEXEC up to _end */
+ _sdata = .;
+ RW_DATA(L1_CACHE_BYTES, PAGE_SIZE, THREAD_SIZE)
+ _edata = .;
+
+ BSS_SECTION(32, 32, 32)
+ . = ALIGN(PAGE_SIZE);
+ _end = .;
+
+ /* This page will be mapped using a FIXMAP */
+ .gdb_page ALIGN(PAGE_SIZE) : AT(ADDR(.gdb_page) - LOAD_OFFSET)
+ {
+ _debug_start = ADDR(.gdb_page) - LOAD_OFFSET;
+ . += PAGE_SIZE;
+ }
+ _debug_start_lma = ASM_FIX_TO_VIRT(FIX_GDB_MEM_BASE_IDX);
+
+ /* Debugging sections */
+ STABS_DEBUG
+ DWARF_DEBUG
+
+ /* Sections to be discarded -- must be last */
+ DISCARDS
+}
diff --git a/arch/kvx/lib/Makefile b/arch/kvx/lib/Makefile
new file mode 100644
index 000000000000..ddb666c244e1
--- /dev/null
+++ b/arch/kvx/lib/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Copyright (C) 2017-2023 Kalray Inc.
+#
+
+lib-y := usercopy.o clear_page.o copy_page.o memcpy.o memset.o strlen.o delay.o
diff --git a/arch/kvx/mm/Makefile b/arch/kvx/mm/Makefile
new file mode 100644
index 000000000000..d97ab0e94a6f
--- /dev/null
+++ b/arch/kvx/mm/Makefile
@@ -0,0 +1,10 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Copyright (C) 2017-2023 Kalray Inc.
+#
+
+obj-y := init.o mmu.o fault.o tlb.o extable.o dma-mapping.o cacheflush.o
+obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
+obj-$(CONFIG_KVX_MMU_STATS) += mmu_stats.o
+obj-$(CONFIG_STRICT_KERNEL_RWX) += kernel_rwx.o
+obj-$(CONFIG_STRICT_DEVMEM) += mmap.o
diff --git a/arch/kvx/platform/Makefile b/arch/kvx/platform/Makefile
new file mode 100644
index 000000000000..27f0914e0de5
--- /dev/null
+++ b/arch/kvx/platform/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Copyright (C) 2018-2023 Kalray Inc.
+#
+
+obj-$(CONFIG_SMP) += pwr_ctrl.o
+obj-$(CONFIG_SMP) += ipi.o
--
2.37.2
^ permalink raw reply related [flat|nested] 15+ messages in thread* Re: [RFC PATCH 03/25] kvx: Add build infrastructure
2023-01-03 16:43 ` [RFC PATCH 03/25] kvx: Add build infrastructure Yann Sionneau
@ 2023-01-03 17:29 ` Randy Dunlap
2023-01-05 13:12 ` Jules Maselbas
0 siblings, 1 reply; 15+ messages in thread
From: Randy Dunlap @ 2023-01-03 17:29 UTC (permalink / raw)
To: Yann Sionneau
Cc: linux-kernel, bpf, Clement Leger, Guillaume Thouvenin,
Jonathan Borne, Jules Maselbas, Julian Vetter,
Marc Poulhiès, Marius Gligor, Samuel Jones, Vincent Chardon
Hi,
On 1/3/23 08:43, Yann Sionneau wrote:
> Add Kbuild, Makefile, Kconfig and link script for kvx build infrastructure.
>
> CC: linux-kernel@vger.kernel.org
> CC: bpf@vger.kernel.org
> Co-developed-by: Clement Leger <clement.leger@bootlin.com>
> Signed-off-by: Clement Leger <clement.leger@bootlin.com>
> Co-developed-by: Guillaume Thouvenin <gthouvenin@kalray.eu>
> Signed-off-by: Guillaume Thouvenin <gthouvenin@kalray.eu>
> Co-developed-by: Jonathan Borne <jborne@kalray.eu>
> Signed-off-by: Jonathan Borne <jborne@kalray.eu>
> Co-developed-by: Jules Maselbas <jmaselbas@kalray.eu>
> Signed-off-by: Jules Maselbas <jmaselbas@kalray.eu>
> Co-developed-by: Julian Vetter <jvetter@kalray.eu>
> Signed-off-by: Julian Vetter <jvetter@kalray.eu>
> Co-developed-by: Marc Poulhiès <dkm@kataplop.net>
> Signed-off-by: Marc Poulhiès <dkm@kataplop.net>
> Co-developed-by: Marius Gligor <mgligor@kalray.eu>
> Signed-off-by: Marius Gligor <mgligor@kalray.eu>
> Co-developed-by: Samuel Jones <sjones@kalray.eu>
> Signed-off-by: Samuel Jones <sjones@kalray.eu>
> Co-developed-by: Vincent Chardon <vincent.chardon@elsys-design.com>
> Signed-off-by: Vincent Chardon <vincent.chardon@elsys-design.com>
> Co-developed-by: Yann Sionneau <ysionneau@kalray.eu>
> Signed-off-by: Yann Sionneau <ysionneau@kalray.eu>
> ---
> arch/kvx/Kconfig | 249 +++++++++++++++++++++++++++++++
> arch/kvx/Kconfig.debug | 70 +++++++++
> arch/kvx/Makefile | 52 +++++++
> arch/kvx/include/asm/Kbuild | 20 +++
> arch/kvx/include/uapi/asm/Kbuild | 1 +
> arch/kvx/kernel/Makefile | 27 ++++
> arch/kvx/kernel/kvx_ksyms.c | 24 +++
> arch/kvx/kernel/vmlinux.lds.S | 173 +++++++++++++++++++++
> arch/kvx/lib/Makefile | 6 +
> arch/kvx/mm/Makefile | 10 ++
> arch/kvx/platform/Makefile | 7 +
> 11 files changed, 639 insertions(+)
> create mode 100644 arch/kvx/Kconfig
> create mode 100644 arch/kvx/Kconfig.debug
> create mode 100644 arch/kvx/Makefile
> create mode 100644 arch/kvx/include/asm/Kbuild
> create mode 100644 arch/kvx/include/uapi/asm/Kbuild
> create mode 100644 arch/kvx/kernel/Makefile
> create mode 100644 arch/kvx/kernel/kvx_ksyms.c
> create mode 100644 arch/kvx/kernel/vmlinux.lds.S
> create mode 100644 arch/kvx/lib/Makefile
> create mode 100644 arch/kvx/mm/Makefile
> create mode 100644 arch/kvx/platform/Makefile
>
> diff --git a/arch/kvx/Kconfig b/arch/kvx/Kconfig
> new file mode 100644
> index 000000000000..8e8820c5c860
> --- /dev/null
> +++ b/arch/kvx/Kconfig
> @@ -0,0 +1,249 @@
> +#
> +# For a description of the syntax of this configuration file,
> +# see Documentation/kbuild/kconfig-language.txt.
> +#
> +
> +config 64BIT
> + def_bool y
> +
> +config GENERIC_CALIBRATE_DELAY
> + def_bool y
> +
> +config FIX_EARLYCON_MEM
> + def_bool y
> +
> +config MMU
> + def_bool y
> +
> +config KALLSYMS_BASE_RELATIVE
> + def_bool n
> +
> +config GENERIC_CSUM
> + def_bool y
> +
> +config RWSEM_GENERIC_SPINLOCK
> + def_bool y
> +
> +config GENERIC_HWEIGHT
> + def_bool y
> +
> +config ARCH_MMAP_RND_BITS_MAX
> + default 24
> +
Do the above and below configs need an "int" line for their type?
I notice that the patch does that below for PGTABLE_LEVELS.
> +config ARCH_MMAP_RND_BITS_MIN
> + default 18
> +
> +config STACKTRACE_SUPPORT
> + def_bool y
> +
> +config LOCKDEP_SUPPORT
> + def_bool y
> +
> +config GENERIC_BUG
> + def_bool y
> + depends on BUG
> +
> +config KVX_4K_PAGES
> + def_bool y
> +
> +config KVX
> + def_bool y
[deletes]
> +
> +config PGTABLE_LEVELS
> + int
> + default 3
^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +config HAVE_KPROBES
> + def_bool n
> +
> +menu "System setup"
> +
> +config POISON_INITMEM
> + bool "Enable to poison freed initmem"
> + default y
> + help
> + In order to debug initmem, using poison allows to verify if
> + some data/code is stille using them. Enable this for debug
still
> + purposes
purposes.
> +
> +config KVX_PHYS_OFFSET
> + hex "RAM address of memory base"
> + default 0x100000000
> +
> +config KVX_PAGE_OFFSET
> + hex "kernel virtual address of memory base"
> + default 0xFFFFFF8000000000
> +
> +config ARCH_FLATMEM_ENABLE
> + def_bool y
> +
> +config ARCH_SPARSEMEM_ENABLE
> + def_bool y
> +
> +config ARCH_SPARSEMEM_DEFAULT
> + def_bool ARCH_SPARSEMEM_ENABLE
> +
> +config ARCH_SELECT_MEMORY_MODEL
> + def_bool ARCH_SPARSEMEM_ENABLE
> +
> +config STACK_MAX_DEPTH_TO_PRINT
> + int "Maximum depth of stack to print"
> + range 1 128
> + default "24"
> +
> +config L2_CACHE
> + bool "Enable l2 cache driver"
L2
> + default y
> + help
> + Enable L2 cache driver in order to handle it. This driver can be
> + disabled to eliminate any overhead related to L2 cache
> + inval/writeback. Note that L2 cache is mandatory for SMP in order
> + to maintain coherency on DDR between all PEs.
> +
> +config SECURE_DAME_HANDLING
> + bool "Secure DAME handling"
> + default y
> + help
> + In order to securely handle Data Asynchronous Memory Errors, we need
> + to do a barrier upon kernel entry when coming from userspace. This
> + barrier guarantee us that any pending DAME will be serviced right
guarantees
> + away. We also need to do a barrier when returning from kernel to user.
> + This way, if the kernel or the user triggered a DAME, it will be
> + serviced by knowing we are coming from kernel or user and avoid
> + pulling the wrong lever (panic for kernel or sigfault for user).
> + This can be costly but ensure that user cannot interfere with kernel.
ensures
> + /!\ Do not disable unless you want to open a giant breach between
> + user and kernel /!\
> +
> +config CACHECTL_UNSAFE_PHYS_OPERATIONS
> + bool "Enable cachectl syscall unsafe physical operations"
> + default n
> + help
> + Enable cachectl syscall to allow writebacking/invalidating ranges
> + based on physical addresses. These operations requires the
> + CAP_SYS_ADMIN capability
capability.
> +
> +config ENABLE_TCA
> + bool "Enable TCA coprocessor support"
> + default y
> + help
> + This option enables TCA coprocessor support. It will allow the user to
> + use the coprocessor and save registers on context switch if used.
> + Registers content will also be cleared when switching.
> +
> +config SMP
> + bool "Symmetric multi-processing support"
> + default n
> + select GENERIC_SMP_IDLE_THREAD
> + select GENERIC_IRQ_IPI
> + select IRQ_DOMAIN_HIERARCHY
> + select IRQ_DOMAIN
> + select L2_CACHE
> + help
> + This enables support for systems with more than one CPU. If you have
> + a system with only one CPU, say N. If you have a system with more
> + than one CPU, say Y.
> +
> + If you say N here, the kernel will run on uni- and multiprocessor
> + machines, but will use only one CPU of a multiprocessor machine. If
> + you say Y here, the kernel will run on many, but not all,
> + uniprocessor machines. On a uniprocessor machine, the kernel
> + will run faster if you say N here.
> +
> +config NR_CPUS
> + int "Maximum number of CPUs"
> + range 1 16
> + default "16"
> + depends on SMP
> + help
> + Kalray support can handle a maximum of 16 CPUs.
> +
> +config KVX_PAGE_SHIFT
> + int
> + default 12
> +
> +config CMDLINE
> + string "Default kernel command string"
> + default ""
> + help
> + On some architectures there is currently no way for the boot loader
> + to pass arguments to the kernel. For these architectures, you should
> + supply some command-line options at build time by entering them
> + here.
> +
> +endmenu
> +
> +menu "Kernel Features"
> +source "kernel/Kconfig.hz"
> +endmenu
> diff --git a/arch/kvx/Kconfig.debug b/arch/kvx/Kconfig.debug
> new file mode 100644
> index 000000000000..027e919a1e14
> --- /dev/null
> +++ b/arch/kvx/Kconfig.debug
> @@ -0,0 +1,70 @@
> +menu "KVX debugging"
> +
> +config KVX_DEBUG_ASN
> + bool "Check ASN before writing TLB entry"
> + default n
> + help
> + This option allows to check if the ASN of the current
> + process is matching the ASN found in MMC. If it is not the
s/is matching/matches/
> + case an error will be printed.
> +
> +config KVX_DEBUG_TLB_WRITE
> + bool "Enable TLBs write checks"
> + default n
> + help
> + Enabling this option will enable TLB access checks. This is
> + particularly helpful when modifying the assembly code responsible
> + of TLB refill. If set, mmc.e will be checked each time the tlb are
for TLB refill. TLB
> + written and a panic will be thrown on error.
> +
> +config KVX_DEBUG_TLB_ACCESS
> + bool "Enable TLBs accesses logging"
> + default n
> + help
> + Enabling this option will enable TLB entry manipulation logging.
> + Each time an entry will be added to the TLBs, it will be logged in
s/will be/is/ s/will be/is/
> + an array readable via gdb scripts. This can be useful to understand
> + strange crashes related to suspicious virtual/physical addresses.
> +
> +config KVX_DEBUG_TLB_ACCESS_BITS
> + int "Number of bits used as index of entries in log table"
> + default 12
> + depends on KVX_DEBUG_TLB_ACCESS
> + help
> + Set the number of bits used as index of entries that will be logged
> + in a ring buffer called kvx_tlb_access. One entry in the table
> + contains registers TEL, TEH and MMC. It also logs the type of the
> + operations (0:read, 1:write, 2:probe). Buffer is per CPU. For one
> + entry 24 bytes are used. So by default it uses 96Ko of memory per
What does "Ko" mean?
> + CPU to store 2^12 (4096) entries.
> +
> +config KVX_MMU_STATS
> + bool "Register mmu stats debugfs entries"
Preferably MMU
> + default n
> + select DEBUG_FS
Preferably:
depends on DEBUG_FS
> + help
> + Enable debugfs attribute which will allow inspecting various metric
metrics
> + regarding MMU:
> + - Number of nomapping traps handled
> + - avg/min/max time for nomapping refill (user/kernel)
> +
> +config DEBUG_EXCEPTION_STACK
> + bool "Enable exception stack debugging"
> + default n
> + help
> + Enable stack check debugging when entering/exiting
> + exception handlers.
> + This can be particularly helpful after modifying stack
> + handling to see if stack when exiting is the same as the one
> + when entering exception handler.
> +
> +config DEBUG_SFR_SET_MASK
> + bool "Enable sfr set_mask debugging"
> + default n
> + help
> + Verify that values written using kvx_sfr_set_mask are matching the
s/are matching/match/
> + mask. This ensure that no extra bits of sfr will be overridden by some
ensures
and preferably s/sfr/SFR/ in 2 places (not in kvx_sfr_set_mask).
> + incorrectly truncated values. This can lead to huge problems by
> + modifying important bits in system registers.
> +
> +endmenu
Thanks.
--
~Randy
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC PATCH 03/25] kvx: Add build infrastructure
2023-01-03 17:29 ` Randy Dunlap
@ 2023-01-05 13:12 ` Jules Maselbas
0 siblings, 0 replies; 15+ messages in thread
From: Jules Maselbas @ 2023-01-05 13:12 UTC (permalink / raw)
To: Randy Dunlap
Cc: Yann Sionneau, linux-kernel, bpf, Clement Leger,
Guillaume Thouvenin, Jonathan Borne, Julian Vetter,
Marc Poulhiès, Marius Gligor, Samuel Jones, Vincent Chardon
Hi,
On Tue, Jan 03, 2023 at 09:29:21AM -0800, Randy Dunlap wrote:
> Hi,
>
-- snip snip
> > +config ARCH_MMAP_RND_BITS_MAX
> > + default 24
> > +
>
> Do the above and below configs need an "int" line for their type?
> I notice that the patch does that below for PGTABLE_LEVELS.
>
I don't think it needs an "int" line, it is added in arch/Kconfig
(which includes arch/kvx/Kconfig)
> > +config ARCH_MMAP_RND_BITS_MIN
> > + default 18
> > +
> > +config STACKTRACE_SUPPORT
> > + def_bool y
> > +
> > +config LOCKDEP_SUPPORT
> > + def_bool y
> > +
> > +config GENERIC_BUG
> > + def_bool y
> > + depends on BUG
> > +
> > +config KVX_4K_PAGES
> > + def_bool y
> > +
> > +config KVX
> > + def_bool y
> [deletes]
> > +
> > +config PGTABLE_LEVELS
> > + int
> > + default 3
> ^^^^^^^^^^^^^^^^^^^^^^^^
I think the "int" here can be removed, as done for
ARCH_MMAP_RND_BITS_MAX and ARCH_MMAP_RND_BITS_MIN
> > +
> > +config HAVE_KPROBES
> > + def_bool n
> > +
> > +menu "System setup"
> > +
> > +config POISON_INITMEM
> > + bool "Enable to poison freed initmem"
> > + default y
> > + help
> > + In order to debug initmem, using poison allows to verify if
> > + some data/code is stille using them. Enable this for debug
>
> still
>
> > + purposes
>
> purposes.
>
> > +
> > +config KVX_PHYS_OFFSET
> > + hex "RAM address of memory base"
> > + default 0x100000000
> > +
> > +config KVX_PAGE_OFFSET
> > + hex "kernel virtual address of memory base"
> > + default 0xFFFFFF8000000000
> > +
> > +config ARCH_FLATMEM_ENABLE
> > + def_bool y
> > +
> > +config ARCH_SPARSEMEM_ENABLE
> > + def_bool y
> > +
> > +config ARCH_SPARSEMEM_DEFAULT
> > + def_bool ARCH_SPARSEMEM_ENABLE
> > +
> > +config ARCH_SELECT_MEMORY_MODEL
> > + def_bool ARCH_SPARSEMEM_ENABLE
> > +
> > +config STACK_MAX_DEPTH_TO_PRINT
> > + int "Maximum depth of stack to print"
> > + range 1 128
> > + default "24"
> > +
> > +config L2_CACHE
> > + bool "Enable l2 cache driver"
>
> L2
>
> > + default y
> > + help
> > + Enable L2 cache driver in order to handle it. This driver can be
> > + disabled to eliminate any overhead related to L2 cache
> > + inval/writeback. Note that L2 cache is mandatory for SMP in order
> > + to maintain coherency on DDR between all PEs.
> > +
> > +config SECURE_DAME_HANDLING
> > + bool "Secure DAME handling"
> > + default y
> > + help
> > + In order to securely handle Data Asynchronous Memory Errors, we need
> > + to do a barrier upon kernel entry when coming from userspace. This
> > + barrier guarantee us that any pending DAME will be serviced right
>
> guarantees
>
> > + away. We also need to do a barrier when returning from kernel to user.
> > + This way, if the kernel or the user triggered a DAME, it will be
> > + serviced by knowing we are coming from kernel or user and avoid
> > + pulling the wrong lever (panic for kernel or sigfault for user).
> > + This can be costly but ensure that user cannot interfere with kernel.
>
> ensures
>
> > + /!\ Do not disable unless you want to open a giant breach between
> > + user and kernel /!\
> > +
> > +config CACHECTL_UNSAFE_PHYS_OPERATIONS
> > + bool "Enable cachectl syscall unsafe physical operations"
> > + default n
> > + help
> > + Enable cachectl syscall to allow writebacking/invalidating ranges
> > + based on physical addresses. These operations requires the
> > + CAP_SYS_ADMIN capability
>
> capability.
>
> > +
> > +config ENABLE_TCA
> > + bool "Enable TCA coprocessor support"
> > + default y
> > + help
> > + This option enables TCA coprocessor support. It will allow the user to
> > + use the coprocessor and save registers on context switch if used.
> > + Registers content will also be cleared when switching.
> > +
> > +config SMP
> > + bool "Symmetric multi-processing support"
> > + default n
> > + select GENERIC_SMP_IDLE_THREAD
> > + select GENERIC_IRQ_IPI
> > + select IRQ_DOMAIN_HIERARCHY
> > + select IRQ_DOMAIN
> > + select L2_CACHE
> > + help
> > + This enables support for systems with more than one CPU. If you have
> > + a system with only one CPU, say N. If you have a system with more
> > + than one CPU, say Y.
> > +
> > + If you say N here, the kernel will run on uni- and multiprocessor
> > + machines, but will use only one CPU of a multiprocessor machine. If
> > + you say Y here, the kernel will run on many, but not all,
> > + uniprocessor machines. On a uniprocessor machine, the kernel
> > + will run faster if you say N here.
> > +
> > +config NR_CPUS
> > + int "Maximum number of CPUs"
> > + range 1 16
> > + default "16"
> > + depends on SMP
> > + help
> > + Kalray support can handle a maximum of 16 CPUs.
> > +
> > +config KVX_PAGE_SHIFT
> > + int
> > + default 12
> > +
> > +config CMDLINE
> > + string "Default kernel command string"
> > + default ""
> > + help
> > + On some architectures there is currently no way for the boot loader
> > + to pass arguments to the kernel. For these architectures, you should
> > + supply some command-line options at build time by entering them
> > + here.
> > +
> > +endmenu
> > +
> > +menu "Kernel Features"
> > +source "kernel/Kconfig.hz"
> > +endmenu
> > diff --git a/arch/kvx/Kconfig.debug b/arch/kvx/Kconfig.debug
> > new file mode 100644
> > index 000000000000..027e919a1e14
> > --- /dev/null
> > +++ b/arch/kvx/Kconfig.debug
> > @@ -0,0 +1,70 @@
> > +menu "KVX debugging"
> > +
> > +config KVX_DEBUG_ASN
> > + bool "Check ASN before writing TLB entry"
> > + default n
> > + help
> > + This option allows to check if the ASN of the current
> > + process is matching the ASN found in MMC. If it is not the
>
> s/is matching/matches/
>
> > + case an error will be printed.
> > +
> > +config KVX_DEBUG_TLB_WRITE
> > + bool "Enable TLBs write checks"
> > + default n
> > + help
> > + Enabling this option will enable TLB access checks. This is
> > + particularly helpful when modifying the assembly code responsible
> > + of TLB refill. If set, mmc.e will be checked each time the tlb are
>
> for TLB refill. TLB
>
> > + written and a panic will be thrown on error.
> > +
> > +config KVX_DEBUG_TLB_ACCESS
> > + bool "Enable TLBs accesses logging"
> > + default n
> > + help
> > + Enabling this option will enable TLB entry manipulation logging.
> > + Each time an entry will be added to the TLBs, it will be logged in
>
> s/will be/is/ s/will be/is/
>
> > + an array readable via gdb scripts. This can be useful to understand
> > + strange crashes related to suspicious virtual/physical addresses.
> > +
> > +config KVX_DEBUG_TLB_ACCESS_BITS
> > + int "Number of bits used as index of entries in log table"
> > + default 12
> > + depends on KVX_DEBUG_TLB_ACCESS
> > + help
> > + Set the number of bits used as index of entries that will be logged
> > + in a ring buffer called kvx_tlb_access. One entry in the table
> > + contains registers TEL, TEH and MMC. It also logs the type of the
> > + operations (0:read, 1:write, 2:probe). Buffer is per CPU. For one
> > + entry 24 bytes are used. So by default it uses 96Ko of memory per
>
> What does "Ko" mean?
Ko stands for kilo-octet which is the french equivalent for kilo byte.
I've found more typos like this in the documentation and they will be
corrected as well.
> > + CPU to store 2^12 (4096) entries.
> > +
> > +config KVX_MMU_STATS
> > + bool "Register mmu stats debugfs entries"
>
> Preferably MMU
>
> > + default n
> > + select DEBUG_FS
>
> Preferably:
> depends on DEBUG_FS
ack
> > + help
> > + Enable debugfs attribute which will allow inspecting various metric
>
> metrics
>
> > + regarding MMU:
> > + - Number of nomapping traps handled
> > + - avg/min/max time for nomapping refill (user/kernel)
> > +
> > +config DEBUG_EXCEPTION_STACK
> > + bool "Enable exception stack debugging"
> > + default n
> > + help
> > + Enable stack check debugging when entering/exiting
> > + exception handlers.
> > + This can be particularly helpful after modifying stack
> > + handling to see if stack when exiting is the same as the one
> > + when entering exception handler.
> > +
> > +config DEBUG_SFR_SET_MASK
> > + bool "Enable sfr set_mask debugging"
> > + default n
> > + help
> > + Verify that values written using kvx_sfr_set_mask are matching the
>
> s/are matching/match/
>
> > + mask. This ensure that no extra bits of sfr will be overridden by some
>
> ensures
>
> and preferably s/sfr/SFR/ in 2 places (not in kvx_sfr_set_mask).
>
> > + incorrectly truncated values. This can lead to huge problems by
> > + modifying important bits in system registers.
> > +
> > +endmenu
Thanks, all the typos will be corrected :)
Jules
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC PATCH 00/25] Upstream kvx Linux port
2023-01-03 16:43 [RFC PATCH 00/25] Upstream kvx Linux port Yann Sionneau
2023-01-03 16:43 ` [RFC PATCH 03/25] kvx: Add build infrastructure Yann Sionneau
@ 2023-01-03 20:52 ` Rob Herring
2023-01-04 15:58 ` Arnd Bergmann
2023-01-07 6:25 ` Jeff Xie
3 siblings, 0 replies; 15+ messages in thread
From: Rob Herring @ 2023-01-03 20:52 UTC (permalink / raw)
To: Yann Sionneau
Cc: Arnd Bergmann, Albert Ou, Alexander Shishkin, Andrew Morton,
Aneesh Kumar K.V, Ard Biesheuvel, Arnaldo Carvalho de Melo,
Boqun Feng, bpf, Christian Brauner, devicetree, Eric Biederman,
Eric Paris, Ingo Molnar, Jan Kiszka, Jason Baron, Jiri Olsa,
Jonathan Corbet, Josh Poimboeuf, Kees Cook, Kieran Bingham,
Krzysztof Kozlowski, linux-arch, linux-arm-kernel, linux-audit,
linux-doc, linux-kernel, linux-mm, linux-perf-users, linux-pm,
linux-riscv, Marc Zyngier, Mark Rutland, Masami Hiramatsu,
Namhyung Kim, Nick Piggin, Oleg Nesterov, Palmer Dabbelt,
Paul Moore, Paul Walmsley, Peter Zijlstra, Sebastian Reichel,
Steven Rostedt, Thomas Gleixner, Waiman Long, Will Deacon,
Alex Michon, Ashley Lesdalons, Benjamin Mugnier, Clement Leger,
Guillaume Missonnier, Guillaume Thouvenin, Jean-Christophe Pince,
Jonathan Borne, Jules Maselbas, Julian Vetter, Julien Hascoet,
Julien Villette, Louis Morhet, Luc Michel, Marc Poulhiès,
Marius Gligor, Samuel Jones, Thomas Costis, Vincent Chardon
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC PATCH 00/25] Upstream kvx Linux port
2023-01-03 16:43 [RFC PATCH 00/25] Upstream kvx Linux port Yann Sionneau
2023-01-03 16:43 ` [RFC PATCH 03/25] kvx: Add build infrastructure Yann Sionneau
2023-01-03 20:52 ` [RFC PATCH 00/25] Upstream kvx Linux port Rob Herring
@ 2023-01-04 15:58 ` Arnd Bergmann
2023-01-05 10:40 ` Jules Maselbas
2023-01-07 6:25 ` Jeff Xie
3 siblings, 1 reply; 15+ messages in thread
From: Arnd Bergmann @ 2023-01-04 15:58 UTC (permalink / raw)
To: Yann Sionneau
Cc: Albert Ou, Alexander Shishkin, Andrew Morton, Aneesh Kumar,
Ard Biesheuvel, Arnaldo Carvalho de Melo, Boqun Feng, bpf,
Christian Brauner, devicetree, Eric W. Biederman, Eric Paris,
Ingo Molnar, Jan Kiszka, Jason Baron, Jiri Olsa, Jonathan Corbet,
Josh Poimboeuf, Kees Cook, Kieran Bingham, Krzysztof Kozlowski,
Linux-Arch, linux-arm-kernel, linux-audit, linux-doc,
linux-kernel, linux-mm, linux-perf-users, linux-pm, linux-riscv,
Marc Zyngier, Mark Rutland, Masami Hiramatsu, Namhyung Kim,
Nicholas Piggin, Oleg Nesterov, Palmer Dabbelt, Paul Moore,
Paul Walmsley, Peter Zijlstra, Rob Herring, Sebastian Reichel,
Steven Rostedt, Thomas Gleixner, Waiman Long, Will Deacon,
Alex Michon, Ashley Lesdalons, Benjamin Mugnier, Clement Leger,
Guillaume Missonnier, Guillaume Thouvenin, Jean-Christophe Pince,
Jonathan Borne, Jules Maselbas, Julian Vetter, Julien Hascoet,
Julien Villette, Louis Morhet, Luc Michel, Marc Poulhiès,
Marius Gligor, Samuel Jones, Thomas Costis, Vincent Chardon
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
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [RFC PATCH 00/25] Upstream kvx Linux port
2023-01-04 15:58 ` Arnd Bergmann
@ 2023-01-05 10:40 ` Jules Maselbas
2023-01-05 12:05 ` Arnd Bergmann
0 siblings, 1 reply; 15+ messages in thread
From: Jules Maselbas @ 2023-01-05 10:40 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Yann Sionneau, Albert Ou, Alexander Shishkin, Andrew Morton,
Aneesh Kumar, Ard Biesheuvel, Arnaldo Carvalho de Melo,
Boqun Feng, bpf, Christian Brauner, devicetree,
Eric W. Biederman, Eric Paris, Ingo Molnar, Jan Kiszka,
Jason Baron, Jiri Olsa, Jonathan Corbet, Josh Poimboeuf,
Kees Cook, Kieran Bingham, Krzysztof Kozlowski, Linux-Arch,
linux-arm-kernel, linux-audit, linux-doc, linux-kernel, linux-mm,
linux-perf-users, linux-pm, linux-riscv, Marc Zyngier,
Mark Rutland, Masami Hiramatsu, Namhyung Kim, Nicholas Piggin,
Oleg Nesterov, Palmer Dabbelt, Paul Moore, Paul Walmsley,
Peter Zijlstra, Rob Herring, Sebastian Reichel, Steven Rostedt,
Thomas Gleixner, Waiman Long, Will Deacon, Alex Michon,
Ashley Lesdalons, Benjamin Mugnier, Clement Leger,
Guillaume Missonnier, Guillaume Thouvenin, Jean-Christophe Pince,
Jonathan Borne, Julian Vetter, Julien Hascoet, Julien Villette,
Louis Morhet, Luc Michel, Marc Poulhiès, Marius Gligor,
Samuel Jones, Thomas Costis, Vincent Chardon
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
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [RFC PATCH 00/25] Upstream kvx Linux port
2023-01-05 10:40 ` Jules Maselbas
@ 2023-01-05 12:05 ` Arnd Bergmann
2023-01-05 14:12 ` Steven Rostedt
0 siblings, 1 reply; 15+ messages in thread
From: Arnd Bergmann @ 2023-01-05 12:05 UTC (permalink / raw)
To: Jules Maselbas
Cc: Yann Sionneau, Albert Ou, Alexander Shishkin, Andrew Morton,
Aneesh Kumar, Ard Biesheuvel, Arnaldo Carvalho de Melo,
Boqun Feng, bpf, Christian Brauner, devicetree,
Eric W. Biederman, Eric Paris, Ingo Molnar, Jan Kiszka,
Jason Baron, Jiri Olsa, Jonathan Corbet, Josh Poimboeuf,
Kees Cook, Kieran Bingham, Krzysztof Kozlowski, Linux-Arch,
linux-arm-kernel, linux-audit, linux-doc, linux-kernel, linux-mm,
linux-perf-users, linux-pm, linux-riscv, Marc Zyngier,
Mark Rutland, Masami Hiramatsu, Namhyung Kim, Nicholas Piggin,
Oleg Nesterov, Palmer Dabbelt, Paul Moore, Paul Walmsley,
Peter Zijlstra, Rob Herring, Sebastian Reichel, Steven Rostedt,
Thomas Gleixner, Waiman Long, Will Deacon, Alex Michon,
Ashley Lesdalons, Benjamin Mugnier, Clement Leger,
Guillaume Missonnier, Guillaume Thouvenin, Jean-Christophe Pince,
Jonathan Borne, Julian Vetter, Julien Hascoet, Julien Villette,
Louis Morhet, Luc Michel, Marc Poulhiès, Marius Gligor,
Samuel Jones, Thomas Costis, Vincent Chardon
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
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [RFC PATCH 00/25] Upstream kvx Linux port
2023-01-05 12:05 ` Arnd Bergmann
@ 2023-01-05 14:12 ` Steven Rostedt
0 siblings, 0 replies; 15+ messages in thread
From: Steven Rostedt @ 2023-01-05 14:12 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jules Maselbas, Yann Sionneau, Albert Ou, Alexander Shishkin,
Andrew Morton, Aneesh Kumar, Ard Biesheuvel,
Arnaldo Carvalho de Melo, Boqun Feng, bpf, Christian Brauner,
devicetree, Eric W. Biederman, Eric Paris, Ingo Molnar,
Jan Kiszka, Jason Baron, Jiri Olsa, Jonathan Corbet,
Josh Poimboeuf, Kees Cook, Kieran Bingham, Krzysztof Kozlowski,
Linux-Arch, linux-arm-kernel, linux-audit, linux-doc,
linux-kernel, linux-mm, linux-perf-users, linux-pm, linux-riscv,
Marc Zyngier, Mark Rutland, Masami Hiramatsu, Namhyung Kim,
Nicholas Piggin, Oleg Nesterov, Palmer Dabbelt, Paul Moore,
Paul Walmsley, Peter Zijlstra, Rob Herring, Sebastian Reichel,
Thomas Gleixner, Waiman Long, Will Deacon, Alex Michon,
Ashley Lesdalons, Benjamin Mugnier, Clement Leger,
Guillaume Missonnier, Guillaume Thouvenin, Jean-Christophe Pince,
Jonathan Borne, Julian Vetter, Julien Hascoet, Julien Villette,
Louis Morhet, Luc Michel, Marc Poulhiès, Marius Gligor,
Samuel Jones, Thomas Costis, Vincent Chardon
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC PATCH 00/25] Upstream kvx Linux port
2023-01-03 16:43 [RFC PATCH 00/25] Upstream kvx Linux port Yann Sionneau
` (2 preceding siblings ...)
2023-01-04 15:58 ` Arnd Bergmann
@ 2023-01-07 6:25 ` Jeff Xie
2023-01-09 13:21 ` Yann Sionneau
3 siblings, 1 reply; 15+ messages in thread
From: Jeff Xie @ 2023-01-07 6:25 UTC (permalink / raw)
To: Yann Sionneau
Cc: Arnd Bergmann, Albert Ou, Alexander Shishkin, Andrew Morton,
Aneesh Kumar K.V, Ard Biesheuvel, Arnaldo Carvalho de Melo,
Boqun Feng, bpf, Christian Brauner, devicetree, Eric Biederman,
Eric Paris, Ingo Molnar, Jan Kiszka, Jason Baron, Jiri Olsa,
Jonathan Corbet, Josh Poimboeuf, Kees Cook, Kieran Bingham,
Krzysztof Kozlowski, linux-arch, linux-arm-kernel, linux-audit,
linux-doc, linux-kernel, linux-mm, linux-perf-users, linux-pm,
linux-riscv, Marc Zyngier, Mark Rutland, Masami Hiramatsu,
Namhyung Kim, Nick Piggin, Oleg Nesterov, Palmer Dabbelt,
Paul Moore, Paul Walmsley, Peter Zijlstra, Rob Herring,
Sebastian Reichel, Steven Rostedt, Thomas Gleixner, Waiman Long,
Will Deacon, Alex Michon, Ashley Lesdalons, Benjamin Mugnier,
Clement Leger, Guillaume Missonnier, Guillaume Thouvenin,
Jean-Christophe Pince, Jonathan Borne, Jules Maselbas,
Julian Vetter, Julien Hascoet, Julien Villette, Louis Morhet,
Luc Michel, Marc Poulhiès, Marius Gligor, Samuel Jones,
Thomas Costis, Vincent Chardon
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
>
>
>
>
>
--
Thanks,
JeffXie
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [RFC PATCH 00/25] Upstream kvx Linux port
2023-01-07 6:25 ` Jeff Xie
@ 2023-01-09 13:21 ` Yann Sionneau
2023-01-09 15:11 ` Jeff Xie
0 siblings, 1 reply; 15+ messages in thread
From: Yann Sionneau @ 2023-01-09 13:21 UTC (permalink / raw)
To: Jeff Xie
Cc: Arnd Bergmann, Albert Ou, Alexander Shishkin, Andrew Morton,
Aneesh Kumar K.V, Ard Biesheuvel, Arnaldo Carvalho de Melo,
Boqun Feng, bpf, Christian Brauner, devicetree, Eric Biederman,
Eric Paris, Ingo Molnar, Jan Kiszka, Jason Baron, Jiri Olsa,
Jonathan Corbet, Josh Poimboeuf, Kees Cook, Kieran Bingham,
Krzysztof Kozlowski, linux-arch, linux-arm-kernel, linux-audit,
linux-doc, linux-kernel, linux-mm, linux-perf-users, linux-pm,
linux-riscv, Marc Zyngier, Mark Rutland, Masami Hiramatsu,
Namhyung Kim, Nick Piggin, Oleg Nesterov, Palmer Dabbelt,
Paul Moore, Paul Walmsley, Peter Zijlstra, Rob Herring,
Sebastian Reichel, Steven Rostedt, Thomas Gleixner, Waiman Long,
Will Deacon, Alex Michon, Ashley Lesdalons, Benjamin Mugnier,
Clement Leger, Guillaume Missonnier, Guillaume Thouvenin,
Jean-Christophe Pince, Jonathan Borne, Jules Maselbas,
Julian Vetter, Julien Hascoet, Julien Villette, Louis Morhet,
Luc Michel, Marc Poulhiès, Marius Gligor, Samuel Jones,
Thomas Costis, Vincent Chardon
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,
--
Yann
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [RFC PATCH 00/25] Upstream kvx Linux port
2023-01-09 13:21 ` Yann Sionneau
@ 2023-01-09 15:11 ` Jeff Xie
2023-01-09 15:30 ` Yann Sionneau
0 siblings, 1 reply; 15+ messages in thread
From: Jeff Xie @ 2023-01-09 15:11 UTC (permalink / raw)
To: Yann Sionneau
Cc: Arnd Bergmann, Albert Ou, Alexander Shishkin, Andrew Morton,
Aneesh Kumar K.V, Ard Biesheuvel, Arnaldo Carvalho de Melo,
Boqun Feng, bpf, Christian Brauner, devicetree, Eric Biederman,
Eric Paris, Ingo Molnar, Jan Kiszka, Jason Baron, Jiri Olsa,
Jonathan Corbet, Josh Poimboeuf, Kees Cook, Kieran Bingham,
Krzysztof Kozlowski, linux-arch, linux-arm-kernel, linux-audit,
linux-doc, linux-kernel, linux-mm, linux-perf-users, linux-pm,
linux-riscv, Marc Zyngier, Mark Rutland, Masami Hiramatsu,
Namhyung Kim, Nick Piggin, Oleg Nesterov, Palmer Dabbelt,
Paul Moore, Paul Walmsley, Peter Zijlstra, Rob Herring,
Sebastian Reichel, Steven Rostedt, Thomas Gleixner, Waiman Long,
Will Deacon, Alex Michon, Ashley Lesdalons, Benjamin Mugnier,
Clement Leger, Guillaume Missonnier, Guillaume Thouvenin,
Jean-Christophe Pince, Jonathan Borne, Jules Maselbas,
Julian Vetter, Julien Hascoet, Julien Villette, Louis Morhet,
Luc Michel, Marc Poulhiès, Marius Gligor, Samuel Jones,
Thomas Costis, Vincent Chardon
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
>
>
>
>
>
--
Thanks,
JeffXie
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [RFC PATCH 00/25] Upstream kvx Linux port
2023-01-09 15:11 ` Jeff Xie
@ 2023-01-09 15:30 ` Yann Sionneau
2023-01-09 15:53 ` Jeff Xie
0 siblings, 1 reply; 15+ messages in thread
From: Yann Sionneau @ 2023-01-09 15:30 UTC (permalink / raw)
To: Jeff Xie
Cc: Arnd Bergmann, Albert Ou, Alexander Shishkin, Andrew Morton,
Aneesh Kumar K.V, Ard Biesheuvel, Arnaldo Carvalho de Melo,
Boqun Feng, bpf, Christian Brauner, devicetree, Eric Biederman,
Eric Paris, Ingo Molnar, Jan Kiszka, Jason Baron, Jiri Olsa,
Jonathan Corbet, Josh Poimboeuf, Kees Cook, Kieran Bingham,
Krzysztof Kozlowski, linux-arch, linux-arm-kernel, linux-audit,
linux-doc, linux-kernel, linux-mm, linux-perf-users, linux-pm,
linux-riscv, Marc Zyngier, Mark Rutland, Masami Hiramatsu,
Namhyung Kim, Nick Piggin, Oleg Nesterov, Palmer Dabbelt,
Paul Moore, Paul Walmsley, Peter Zijlstra, Rob Herring,
Sebastian Reichel, Steven Rostedt, Thomas Gleixner, Waiman Long,
Will Deacon, Alex Michon, Ashley Lesdalons, Benjamin Mugnier,
Clement Leger, Guillaume Missonnier, Guillaume Thouvenin,
Jean-Christophe Pince, Jonathan Borne, Jules Maselbas,
Julian Vetter, Julien Hascoet, Julien Villette, Louis Morhet,
Luc Michel, Marc Poulhiès, Marius Gligor, Samuel Jones,
Thomas Costis, Vincent Chardon
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,
--
Yann
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [RFC PATCH 00/25] Upstream kvx Linux port
2023-01-09 15:30 ` Yann Sionneau
@ 2023-01-09 15:53 ` Jeff Xie
2023-01-16 7:31 ` Jeff Xie
0 siblings, 1 reply; 15+ messages in thread
From: Jeff Xie @ 2023-01-09 15:53 UTC (permalink / raw)
To: Yann Sionneau
Cc: Arnd Bergmann, Albert Ou, Alexander Shishkin, Andrew Morton,
Aneesh Kumar K.V, Ard Biesheuvel, Arnaldo Carvalho de Melo,
Boqun Feng, bpf, Christian Brauner, devicetree, Eric Biederman,
Eric Paris, Ingo Molnar, Jan Kiszka, Jason Baron, Jiri Olsa,
Jonathan Corbet, Josh Poimboeuf, Kees Cook, Kieran Bingham,
Krzysztof Kozlowski, linux-arch, linux-arm-kernel, linux-audit,
linux-doc, linux-kernel, linux-mm, linux-perf-users, linux-pm,
linux-riscv, Marc Zyngier, Mark Rutland, Masami Hiramatsu,
Namhyung Kim, Nick Piggin, Oleg Nesterov, Palmer Dabbelt,
Paul Moore, Paul Walmsley, Peter Zijlstra, Rob Herring,
Sebastian Reichel, Steven Rostedt, Thomas Gleixner, Waiman Long,
Will Deacon, Alex Michon, Ashley Lesdalons, Benjamin Mugnier,
Clement Leger, Guillaume Missonnier, Guillaume Thouvenin,
Jean-Christophe Pince, Jonathan Borne, Jules Maselbas,
Julian Vetter, Julien Hascoet, Julien Villette, Louis Morhet,
Luc Michel, Marc Poulhiès, Marius Gligor, Samuel Jones,
Thomas Costis, Vincent Chardon
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
>
>
>
>
>
--
Thanks,
JeffXie
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [RFC PATCH 00/25] Upstream kvx Linux port
2023-01-09 15:53 ` Jeff Xie
@ 2023-01-16 7:31 ` Jeff Xie
0 siblings, 0 replies; 15+ messages in thread
From: Jeff Xie @ 2023-01-16 7:31 UTC (permalink / raw)
To: Yann Sionneau
Cc: Arnd Bergmann, Albert Ou, Alexander Shishkin, Andrew Morton,
Aneesh Kumar K.V, Ard Biesheuvel, Arnaldo Carvalho de Melo,
Boqun Feng, bpf, Christian Brauner, devicetree, Eric Biederman,
Eric Paris, Ingo Molnar, Jan Kiszka, Jason Baron, Jiri Olsa,
Jonathan Corbet, Josh Poimboeuf, Kees Cook, Kieran Bingham,
Krzysztof Kozlowski, linux-arch, linux-arm-kernel, linux-audit,
linux-doc, linux-kernel, linux-mm, linux-perf-users, linux-pm,
linux-riscv, Marc Zyngier, Mark Rutland, Masami Hiramatsu,
Namhyung Kim, Nick Piggin, Oleg Nesterov, Palmer Dabbelt,
Paul Moore, Paul Walmsley, Peter Zijlstra, Rob Herring,
Sebastian Reichel, Steven Rostedt, Thomas Gleixner, Waiman Long,
Will Deacon, Alex Michon, Ashley Lesdalons, Benjamin Mugnier,
Clement Leger, Guillaume Missonnier, Guillaume Thouvenin,
Jean-Christophe Pince, Jonathan Borne, Jules Maselbas,
Julian Vetter, Julien Hascoet, Julien Villette, Louis Morhet,
Luc Michel, Marc Poulhiès, Marius Gligor, Samuel Jones,
Thomas Costis, Vincent Chardon
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
^ permalink raw reply [flat|nested] 15+ messages in thread