staging/blocktrron/config, branch master

build: drop implicit gzip of ext4 images

2026-10-06T09:32:34Z

With CONFIG_TARGET_IMAGES_GZIP enabled, which is the default, ext4 images are gzipped when they are copied to $(BIN_DIR), unless their name ends with .gz or .dtb. This causes several problems: - The JSON info contains the uncompressed name and hash, so profiles.json lists images which don't exist on the download server: profiles.json: openwrt-at91-sam9x-atmel_at91sam9263ek-ext4-root.ubi sha256sums: openwrt-at91-sam9x-atmel_at91sam9263ek-ext4-root.ubi.gz - The image is gzipped as a whole, including the metadata and signature added by append-metadata. fwtool looks for them at the end of the file, so sysupgrade rejects these images. Explicitly gzipped images run append-metadata after gzip instead. - A rule for the gzipped name is defined for every image, which clashes with images that are built both plain and gzipped, as it was the case for malta. The previous commits removed the ext4 images which can't be used and gzip the remaining ones explicitly, so drop the implicit gzip. The file name in $(BIN_DIR) is now always the one from IMAGES. Targets wanting gzipped images define them explicitly, e.g. sdcard.img.gz, or select them via CONFIG_TARGET_IMAGES_GZIP like x86, armsr, loongarch64 and malta. Limit the option to these targets. The ext4 kernel.bin and factory.bin of ixp4xx, which only contain the kernel, and the optional ext4 VM images of x86 and armsr are now stored uncompressed, like their squashfs counterparts. Link: https://github.com/openwrt/openwrt/pull/25658 Signed-off-by: Paul Spooren

build: remove the AUDIO_SUPPORT and DISPLAY_SUPPORT symbols

2026-09-29T14:29:43Z

Nothing tests either symbol any more. AUDIO_SUPPORT was also selected by PCI_SUPPORT and USB_SUPPORT, which stood for "a sound card could be plugged in here": audio hardware sits behind MMC, SPI, a Bluetooth UART or an SoC PCM block just as often, so the inference never held. The display feature was derived from a literal CONFIG_VGA_CONSOLE or CONFIG_FB in a kernel fragment, which misses every target whose fbdev came from DRM emulation. Delete both symbols, the two selects, the feature translations and the derivation. Signed-off-by: Daniel Golle

build: gate the VM image formats on their target features

2026-09-24T21:33:28Z

The x86 and armsr targets declare the vdi, vmdk and vhdx features, but VDI_IMAGES, VMDK_IMAGES and VHDX_IMAGES depend on a hardcoded target list instead, so the features select nothing and a target opting in has to edit config/Config-images.in. Give them USES_VDI, USES_VMDK and USES_VHDX in the same shape as the other image formats and depend on those. The set of targets offering each format is unchanged. Signed-off-by: Daniel Golle

kernel: add KERNEL_TIME_NS Kconfig knob

2026-09-18T15:03:13Z

Enable time namespaces by default, following the existing pattern of enabling all container-relevant features by default with optional opt-out. The knob carries no architecture dependency of its own. TIME_NS is gated on GENERIC_VDSO_TIME_NS on 6.12 and on GENERIC_GETTIMEOFDAY on 6.18, so the set of architectures able to honour it differs per kernel version. Where the dependency is unmet the kernel drops the symbol during syncconfig, as it does for the other options offered unconditionally here. Signed-off-by: Daniel Golle

build: gate firmware image signing behind SIGN_FIRMWARE

2026-07-20T08:33:41Z

Firmware image signing in append-metadata/append-gl-metadata was conditional only by the presence of the build key. Add an explicit SIGN_FIRMWARE option (default enabled except with BUILDBOT) so appending the fwtool signature can be toggled on its own. It's disable on buildbot since we use a decentralized building with no individual keys on builders. Instead, a fake key is currently used, which adds an insecure signature. The future of signing firmware and key distribution across the build infrastructure should be discussed separately. Link: https://github.com/openwrt/openwrt/pull/24291 Signed-off-by: Paul Spooren

kernel: add Kconfig options for ARM64_BRBE and THP enhancements on 6.18

2026-07-07T06:48:42Z

Introduce new kernel configuration options for memory management and hardware-profiling features: - KERNEL_ARM64_BRBE: Enables support for the Branch Record Buffer Extension (FEAT_BRBE) on ARM64 architectures when perf events are active. - KERNEL_PERSISTENT_HUGE_ZERO_FOLIO: Allows allocating a PMD-sized folio for zeroing, optimizing Transparent Hugepage (THP) allocation performance. - KERNEL_NO_PAGE_MAPCOUNT: Adds experimental support for bypassing per-page mapcount tracking to reduce memory accounting overhead under THP. These options map directly to their respective kernel options and are applicable on 6.18 and later. Signed-off-by: Joshua Covington Link: https://github.com/openwrt/openwrt/pull/23703 Signed-off-by: Jonas Jelonek

x86: onie-installer: wire up sysupgrade via ONIE install mode

2026-05-23T15:23:54Z

This adds support for sysupgrade on ONIE-installed systems. The install is chained through ONIE (using the ONIE installer image), rather than attempting to manually upgrade the partition. The idea is to allow future OpenWRT installs flexibility to use a different partition table. By putting the installer in charge of setting up the file system partition, the upgrade process needs to have no knowledge of the internals of the image. Config preservation is accomplished by appending the sysupgrade .tar.gz to the ONIE installer image. Of course this also works for a clean install using a sysupgrade.tar.gz created via `sysupgrade -b`. Co-Authored-By: Claude Opus 4.7 Signed-off-by: Keno Fischer Link: https://github.com/openwrt/openwrt/pull/23062 Signed-off-by: Jonas Jelonek

x86: add onie-installer image type

2026-05-23T15:23:53Z

The current documentation for using OpenWRT on Mellanox Spectrum switches (https://openwrt.org/toh/mellanox/spectrum) suggests reflashing the entire harddrive from the recovery USB. This is not the most friendly way to install a new OS on these switches. From factory, they come with ONIE (Open Network Install Environment), which is a linux-based preboot environment for fetching an OS image from the network and installing it on disk. The installer is a self-executing bash script that executes inside the ONIE environment. The installer is expected to preserve the ONIE partition for use as recovery environement. To be a better citizen on these platforms, it would be preferrable to provide OpenWRT as an ONIE-compatible installer. This PR adds an ONIE_INSTALLER_IMAGES build option that produces an ONIE compatible .bin. The generated .bin follows the ONIE demo installer pattern [1]: it creates a new GPT partition labelled OPENWRT-ROOT on the ONIE install device, formats ext4, extracts the OpenWrt rootfs and kernel into it, installs GRUB into the existing UEFI ESP under bootloader-id "OpenWrt", and adds a NVRAM boot entry via efibootmgr. ONIE-BOOT is preserved so ONIE rescue remains available. Tested with the config at [2] on a Mellanox Spectrum SN3800 to produce a booting OpenWRT install. [1] https://github.com/opencomputeproject/onie/demo/installer/grub-arch/install.sh [2] https://gist.github.com/Keno/abc8c5b72645e73fadd1ff0d9616b23d Co-Authored-By: Claude Opus 4.7 Signed-off-by: Keno Fischer Link: https://github.com/openwrt/openwrt/pull/23062 Signed-off-by: Jonas Jelonek

treewide: remove unused archs leftovers

2026-05-07T08:58:47Z

These are all unused by the current targets, clean up and stop irritating the user with irrelevant grep results. Signed-off-by: Andre Heider Link: https://github.com/openwrt/openwrt/pull/23240 Signed-off-by: Robert Marko

x86: make CONFIG_NR_CPUS a tunable (2-512)

2026-03-28T10:51:11Z

Add KERNEL_NR_CPUS option in Global build settings → Kernel build options, allowing users to set maximum CPU count (2-512) for the image. Defaults: - x86_64: 512 CPUs (backward compatible) - x86: 8 CPUs (fix broken single-CPU default) Per-CPU data structures consume ~100-200KB each. On a 4-core system configured to NR_CPUS=4, this frees approx 76 MB of RAM: (512 - 4) × 150 KB = ~76 MB Note: CONFIG_NR_CPUS_RANGE_{BEGIN,END}= and CONFIG_NR_CPUS_DEFAULT= are set by the build system and will default to 2/512/64 per arch/x86/Kconfig These are harmless metadata and don't affect memory allocation. Note pending https://github.com/openwrt/openwrt/pull/21407 Signed-off-by: John Audia Link: https://github.com/openwrt/openwrt/pull/21078 Signed-off-by: Robert Marko