staging/neocturne/include/kernel.mk, branch main

loongarch64: new target

2024-05-04T06:14:16Z

Add target for Loongson LoongArch64-based boards. LoongArch is a new RISC ISA developed by Loongson. It's a bit like MIPS or RISC-V. LoongArch includes both 32-bit and 64-bit versions (LoongArch32/LoongArch64). Loongson 3A5000 and 3A6000 are the two existing CPUs of LoongArch64 and is used for PC products. It's BIOS supports ACPI and UEFI-only boot. These CPUs supports SMP and SMT. At present only LoongArch64 is supported by linux kernel. Toolchain requirement: binutils >= 2.40 gcc >= 13.1 For details, please check the following links: https://lwn.net/Articles/861951/ https://loongson.github.io/LoongArch-Documentation/README-EN.html Signed-off-by: Weijie Gao

treewide: remove implicit SUBTARGET

2024-04-08T19:53:05Z

Historically it's possible to leave the `SUBTARGETS` undefined and automatically fallback to a "generic" subtarget. This however breaks various downstream scripts which may have expectations around filenames: While some targets with an explicit generic subtarget contain `generic` in the filenames of artifacts, implicit "subtargets" don't. Right now this breaks the CI[1], possibly also scripts using the ImageBuilders. This commit removes all code that support implicit handling of subtargets and instead requires every target to define "SUBTARGETS". [1]: https://github.com/openwrt/openwrt/actions/runs/8592821105/job/23548273630 Signed-off-by: Paul Spooren

treewide: use APK compatible version schema

2024-03-22T21:14:22Z

Different from OPKG, APK uses a deterministic version schema which chips the version into chunks and compares them individually. This enforces a certain schema which was previously entirely flexible. - Releases are added at the very and end prefixed with an `r` like `1.2.3-r3`. - Hashes are prefixed with a `~` like `1.2.3~abc123`. - Dates become semantic versions, like `2024.04.01` - Extra tags are possible like `_git`, `_alpha` and more. For full details see the APK test list: https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/test/version.data Signed-off-by: Paul Spooren

build: cache kernel module package compiling

2023-10-28T19:34:20Z

Kernel module packages compiling is not cached (e.g. mac80211) even with CONFIG_CCACHE on. CC should be set to KERNEL_CC in KERNEL_MAKE_FLAGS at kernel.mk to allow kernel module packages using ccache. Signed-off-by: Zeyu Dong

kernel: fix KernelPackage when all KCONFIG are versioned

2023-07-04T17:29:41Z

If a kernel package was defined where all KCONFIG symbols were dynamic, and versioned, no FILES would be installed, as the foreach evaluation was providing the value of the variable defined by the KCONFIG symbol name including the version test Fix this by calling the version_filter function on the list of KCONFIG variable names run through by foreach Example, kernel 6.1: KCONFIG:=CONFIG_OLD@lt6.1 CONFIG_NEW@ge6.1 filter-out any KCONFIG settings forced by package: CONFIG_OLD@lt6.1 CONFIG_NEW@ge6.1 there are dynamic settings, so for each of them, get the value of the make variable defined by symbol name: CONFIG_OLD@lt6.1 is not set CONFIG_NEW@ge6.1 is not set versus CONFIG_OLD is not set CONFIG_NEW=m test if any of these are m, or y if yes, install files, otherwise, nothing to install Signed-off-by: John Thomson

generic: groundwork for RISC-V

2023-05-28T11:19:10Z

Add build infrastructure for RISC-V. Signed-off-by: Zoltan HERPAI

kernel: Make KERNEL_MAKEOPTS recursively expanded

2022-12-17T19:12:31Z

KERNEL_MAKEOPTS will get expanded when it is used and not when it is defined in the kernel.mk file now. This fixes problems finding dependent kernel modules when it is used by a kernel module package. Without this change the build of packages which depend on other out of tree modules failed when they used KERNEL_MAKE because some symbols could not be found. This happened because KERNEL_MAKE_FLAGS which contains a "if $(__package_mk)" was evaluated where KERNEL_MAKEOPTS was defined and not when the KERNEL_MAKE was used. For packages which included kernel.mk before package.mk we saw this problem. One workaround was to use the correct include order and the other one was to not use KERNEL_MAKE_FLAGS, but copy its content. Signed-off-by: Hauke Mehrtens

kernel: disable stack validation for external module builds as needed

2022-10-20T07:53:23Z

c3e31b6a9b04 and 5f8e5872406d disable stack validation when the build host is not running Linux, as the objtool kernel build tool required for stack validation is not portable to other build host environments. This was achieved by setting CONFIG_STACK_VALIDATION= in KERNEL_MAKEOPTS, and by setting SKIP_STACK_VALIDATION=1 in the environment. KERNEL_MAKEOPTS only has effect for the kernel build, not for external module builds, but through kernel 5.14, SKIP_STACK_VALIDATION worked to disable this feature too, so stack validation was disabled for external module builds as well. Since kernel 0d989ac2c90b, the kernel build no longer considers SKIP_STACK_VALIDATION, so the feature will be disabled for the kernel build, but not for external module builds. When building OpenWrt on a non-Linux build host targeting x86 (the only target architecture for which OpenWrt enables the kernel CONFIG_STACK_VALIDATION) and using kernel 5.15 (such as via CONFIG_TESTING_KERNEL), this caused a build failure during any external module build, such as kmod-button-hotplug. This manifested as build errors such as: make[4]: *** No rule to make target '.../build_dir/target-x86_64_musl/linux-x86_64/button-hotplug/button-hotplug.o', needed by '.../build_dir/target-x86_64_musl/linux-x86_64/button-hotplug/button-hotplug.mod'. Stop. Although button-hotplug.c was present, the implicit rule to make $(obj)/%.o from $(src)/%.c in the kernel's scripts/Makefile.build could not be satisfied in this case, as it also depends on $(objtool_dep), non-empty as a result of the failure to propagate disabling of stack validation to external module builds, in a configuration where it is not possible to build objtool. KERNEL_MAKEOPTS is used for just the kernel build itself, while KERNEL_MAKE_FLAGS is used for both the kernel build and for external module builds. This restores the ability to build OpenWrt in such configurations by moving the CONFIG_STACK_VALIDATION= make argument from KERNEL_MAKEOPTS to KERNEL_MAKE_FLAGS where it is able to affect external module builds properly. Note that the kernel's objtool and related configuration have seen a major overhaul since kernel 5.15, and may need more attention again after 22922deae13f, in kernel 5.19. Signed-off-by: Mark Mentovai

kernel: filter -no-plt from KCFLAGS

2022-06-21T15:41:17Z

Compiler option -no-plt will break kernel builds on some architectures eg. (x86) Filter this option from the recently introduced handling of KCFLAGS vs EXTRA_OPTIMISATION Fixes: 1d42af720c6b ("kernel: use KCFLAGS for passing EXTRA_OPTIMIZATION flags") Suggested-by: Felix Fietkau Signed-off-by: Kevin Darbyshire-Bryant

kernel: support setting extra CFLAGS for kernel compilation

2022-06-20T20:17:38Z

They may be used e.g. to optimize kernel size or performance. Signed-off-by: Rafał Miłecki