Rename two .patch files to .patch.NEED_FIX so the patch driver
skips them on apply. Both are drm/xe kernel patches that stopped
applying cleanly after an upstream rebase and haven't been
refreshed yet:
- 0002-drm-xe-guc-use-GUC_SIZE-SZ_4K-for-alignment.patch
- 0005-drm-xe-query-use-PAGE_SIZE-as-the-minimum-page-align.patch
Kernels that were picking these up need them re-based against
current upstream drm/xe before re-enabling. Not a behaviour
change on its own — the patches were already failing the apply
step — but stops the noise in build logs and makes it obvious
at a glance which patches need maintainer attention.
Same fix as #9651 for v2026.01 and v2025.10, applied to the common
patch/u-boot/v2026.04/ directory so all boards on U-Boot v2026.04 pick
it up (cm3588-nas, nanopct6, orangepi5, rock-3a, nanopi-r3s-lts,
mekotronics-*, mixtile-blade3, radxa-rock-4d, helios64 via its own
self-contained board_helios64 subdir already has a copy).
Without this, booting from a BTRFS rootfs with zstd-compressed extents
fails with:
zstd_decompress: failed to decompress: 70
BTRFS: An error occurred while reading file /boot/boot.scr
See commit 5617ff3fd for the full rationale.
Code-style and defensive-programming fixes to the helios64 u-boot
overlay, applied on top of the pristine v2026.04 vendor bump. All
changes are additive safety nets — none alter the happy-path
behaviour of the previous Kobol/Armbian code.
board/helios64.c:
- setup_leds(): check led_get_by_label() return value. Without
this, led_set_state() is called on an uninitialised udevice
pointer if LED lookup fails.
- sata_power_enable(): add the matching 10s mdelay after
enabling hdd_b_power, mirroring the one already present after
hdd_a_power. Previously rail B had no spin-up time before
scsi_scan(true) in last_stage_init(), so drives on the second
rail could miss the scan. The staggered spin-up between rails
is preserved (PSU in-rush protection for two 3.5" HDDs).
board/sys_otp.c:
- replace the || chain magic-number check in is_valid_header()
with memcmp() against a const expected_magic[8] (fixes a real
pre-existing bug: the || chain was always true);
- introduce otp_serial() / otp_mfg_year() helpers that assemble
the multi-byte values byte-by-byte, eliminating unaligned
u64/u16 casts into the packed otp struct (UB per the C standard,
also over-read into adjacent fields);
- bounds-check otp.variant against BOARD_VARIANT_MAX before
indexing var_str[], adding BOARD_VARIANT_INVALID slot;
- use strnlen() when printing packed fixed-length fields;
- use snprintf() with target buffer size instead of sprintf();
- retry read_otp_data() in ensure_otp_data_ready() on the first
access after a failed board_early_init_r(), instead of silently
skipping OTP-provided values for the whole boot.
cmd-fileenv-read-string-from-file-into-env.patch:
add 'depends on CMD_FAT' to the cherry-picked CMD_FILEENV Kconfig
entry. do_fat_fsload() is called unconditionally from the
fileenv implementation, so the dependency reflects reality.
general-fix-btrfs-zstd-decompression.patch:
tighten the decompression-success check to also reject short
reads ('|| ret < dlen'). zstd_is_error() alone does not cover
truncated output.
Assisted-by: Claude:claude-opus-4-7
Self-contained board_helios64/ overlay bumped to v2026.04 from v2026.01.
The overlay is a pristine copy of v2026.01 plus the minimum set of
v2026.04-mandated changes and new cherry-picks:
- board/Kconfig: ENV_OFFSET 0x460000 → 0x3F8000
Required by the v2026.04 SPI NOR environment layout.
- 1001-fdt_fixup_ethernet-add-logs.patch.disabled
Cherry-pick of Ricardo Pardini's fdt_fixup_ethernet logging patch.
Shipped disabled; preserved for debugging MAC propagation issues.
- cmd-fileenv-read-string-from-file-into-env.patch
Cherry-pick of the Home Assistant 2018 vendor patch (rebased by
rpardini) adapting 'fileenv' u-boot command for v2026.04.
config/boards/helios64.conf: BOOTBRANCH / BOOTPATCHDIR → v2026.04.
No behaviour changes beyond what the u-boot version bump itself
requires; pre-existing code paths (sys_otp.c, helios64.c) are left
exactly as they were in v2026.01. Defensive code-style fixes on top
of this baseline are a separate follow-up commit.
Assisted-by: Claude:claude-opus-4-7
- those were added to ensure that code was actually being compiled
- we're pretty sure now, so avoid spurious warnings during compilation
Signed-off-by: Ricardo Pardini <ricardo@pardini.net>
Compute the relevant PCI_EXP_DEVCTL change mask before clearing the
RC-mode forbidden bits from the local write value. Otherwise a change in
DEVCTL.{CERE,NFERE,FERE} may be missed and the corresponding IRQ mask
update deferred until some later config-space write.
Also restrict the PCI_EXP_RTCTL-triggered IRQ mask update to PMEIE.
mvebu_pcie_handle_irq_change() only uses rootctl.PMEIE, so reacting to
SECEE/SENFEE/SEFEE changes only reruns the helper without affecting the
hardware interrupt mask.
Assisted-by: Claude:claude-opus-4-7
Patch 10-mvebu-clearfog-pcie-updates.patch (Russell King, Nov 2016) was
restored from mvebu-6.6/ to mvebu-6.18/ alongside three other lost
patches. It bundled together two distinct kinds of changes:
1. Functional AER/PME plumbing for the mvebu PCIe controller:
- mvebu_pcie_handle_irq_change() in pci-mvebu.c, which syncs the
hardware PCIE_INT_UNMASK_OFF mask (BIT 8/9/10/16/17/18) with the
emulated bridge config space whenever AER-related bits in
PCI_COMMAND.SERR, BRIDGE_CTL.SERR, DEVCTL.{CERE,NFERE,FERE,URRE}
or RTCTL.{SECEE,SENFEE,SEFEE,PMEIE} change
- Armada 370 erratum: clamp DEVCTL.{URRE,FERE,NFERE,CERE} to 0 in
Root Complex mode
- pci-bridge-emul.c: default bridge->conf.bridgectrl to
PCI_BRIDGE_CTL_SERR (precondition for AER reporting)
2. Two debug hunks: dev_info() probes added during clearfog bring-up:
- drivers/pci/pcie/aspm.c (6 lines): print upstream/downstream ASPM
LNKCAP/LNKCTL on every pcie_aspm_cap_init() call
- drivers/pci/pcie/portdrv.c (2 lines): print PCIe capabilities and
init_service_irqs() return on every port device register
Drop the debug hunks. They were ad-hoc bring-up traces from 2016, never
useful in production, and just noise in dmesg on every boot. The aspm.c
hunk also no longer applies cleanly to 6.18 (function moved from line
617 to 814) — fixing the offset just to keep dev_info() spam is not
worthwhile.
Functional hunks (pci-mvebu.c, pci-bridge-emul.c) keep the original
intent: without them mvebu's hardware AER/PME interrupt masks stay off,
so corrected/uncorrected PCIe errors and PME wake events go undetected
on clearfog boards (NAS use case with NVMe/SATA cards in mPCIe slots).
Mainline still does not have this plumbing — Marek Behún's 2021 rewrite
around pci-bridge-emul did not close this gap.
Assisted-by: Claude:claude-opus-4-7
#9694 split mvebu edge into per-board kernel versions: helios4 on 6.18 LTS,
clearfogpro/clearfogbase on 6.15. Both share LINUXCONFIG=linux-mvebu-edge
and ARMBIAN_KERNEL_DEB_NAME=mvebu-edge, so building both produced
"Duplicate LINUXCONFIG's found!" — two source trees compete for the same
package name.
Per @igorpecovnik in #9694: "kernel can't be per board". Bump the rest of
the mvebu (armhf) family to 6.18 too. mvebu64 and other families are
untouched.
The mvebu-6.18 patch directory is already in the tree from #9694, so the
remaining boards (clearfogpro, clearfogbase) get the same patch set.
Affected boards: clearfogpro, helios4, clearfogbase (csc). espressobin
and macchiatobin (eos) are mvebu64, not affected.
I do not have non-helios4 mvebu hardware; build verified, runtime not.
Assisted-by: Claude:claude-opus-4-7
* qrb2210: switch edge kernel to mainline linux v7.0
The Arduino UNO Q device tree (qrb2210-arduino-imola.dts) was
upstreamed in Linux 7.0, so edge can drop the Arduino fork.
* qrb2210: carry 48 non-mainlined patches from arduino fork
Adds features not yet upstream: audio (pm4125, LPASS Agatti),
anx7625 Type-C DP, Waveshare panels, Imola media carrier.
Commit 2f852e68e bumped mvebu edge KERNEL_MAJOR_MINOR from 6.12 to 6.15
but did not rename patch/kernel/archive/mvebu-6.12/, so KERNELPATCHDIR
pointed to a non-existent directory and all helios4-specific kernel
patches (GPIO wake, Wake-on-LAN, atheros regd, DMA, SPI-flash) were
silently skipped.
6.15 is not an LTS kernel; 6.18 is. Bump only helios4 to 6.18 (LTS, EOL
2028-12), keeping the rest of the mvebu family at 6.15 until their
maintainers verify the upgrade on their own boards.
Rename the archive directory to mvebu-6.18 so the patches apply again,
verified by a full kernel build against 6.18.23.
The Rock 5 ITX DTB defines the PWM fan as /pwm-fan without a labelled
phandle, so the existing rockchip-rk3588-fanctrl overlay (which targets
&fan) has no effect on this board.
The default cooling-levels in the Rock 5 ITX DTB start at 0, which means
the fan receives no PWM signal at idle and falls back to running at full
speed regardless of temperature.
This overlay patches /pwm-fan directly using target-path, replacing the
cooling-levels with a curve that starts at 1 (near-silent at idle) and
adds rockchip,temp-trips to ramp the fan gradually across four steps
at 45°C, 50°C, 55°C, and 65°C.
Tested on Rock 5 ITX running Armbian with linux-vendor-rk35xx 6.1.
glibc 2.42+ (Ubuntu Resolute and later) ships const-aware strstr/strchr
declarations in <string.h>. Assigning their results to non-const char*
triggers -Werror=discarded-qualifiers in tools/bpf/resolve_btfids,
which is compiled by the linux-headers .deb postinst on the build host.
Fix by declaring the receiving variables as const char* in two places
in tools/lib/bpf/libbpf.c. Matches the upstream 6.13+ fix, backported
to the NXP lf-6.12.y SDK kernel (which NXP has moved off for 6.18+).
Patches 1100 (2nd HDMI) and 1101 (HDMI sound) are now fully covered by
the upstream Linux 7.0 DTS, which was refactored to use
rk3588-orangepi-5-compact.dtsi. The patches no longer apply and were
silently skipped during builds.
Same patch as v2026.01 — fs/btrfs/compression.c is identical.
Tested on Helios4 (Marvell A388).
Placed in both board_helios4/ (board-specific BOOTPATCHDIR) and
v2025.10/ root (shared, for boards like rockpi-e, orangepi4-lts).
U-Boot's generic zstd_decompress() wrapper fails when used by BTRFS
due to two sector-alignment mismatches:
1. Compressed extents are stored padded to sector boundaries (4096),
but zstd_decompress_dctx() rejects trailing data after the frame.
2. BTRFS compresses in sector-sized blocks, so the zstd frame content
size may exceed ram_bytes. When the output buffer is sized to
ram_bytes, zstd_decompress_dctx() returns dstSize_tooSmall (error 70).
Symptoms on zstd-compressed BTRFS partition:
zstd_decompress: failed to decompress: 70
BTRFS: An error occurred while reading file /boot/boot.scr
Fix by calling zstd_decompress_dctx() directly with:
- zstd_find_frame_compressed_size() to strip sector padding from input
- ZSTD_getFrameContentSize() to allocate a larger output buffer when
the frame decompresses beyond the caller's buffer size
Tested on Helios64 (RK3399) booting from BTRFS+zstd SD card.
It was never applied, therefore never recognized to fail, because there was a file name mismatch.
Due to forward moving upstream minor changes were necessary to allow clean application
Patch mainline U-Boot to detect the NanoPC-T6 LTS Plus variant via
ADC channel 5 (value ~3076, range 2986-3166) and automatically set
the correct device tree. Remove the no-op override that disabled
auto-detection since U-Boot can now handle all three variants.
Same three patches (defconfig, device-tree, device-tree-makefile)
that existed in v2025.10 and earlier. v2026.01 skipped the board;
this brings it back for v2026.04 so boards using this u-boot
version keep building.
Original patches by Paolo Sabatino.
The sff,sfp DT binding has additionalProperties: false, so our custom
leds property on SFP nodes violates the schema. Move LED-to-SFP
association into per-port child nodes of the sfp_led_controller.
DTS: sfp_led_controller now has port@0/port@1 sub-nodes, each with
sfp phandle and leds list. SFP nodes no longer carry leds property.
Driver: sfp_led_probe() iterates child nodes instead of sfp-ports
phandle array. sfp_led_register_port() receives the port child node,
parses the sfp phandle from it, and reads LEDs from the child node
instead of from the SFP node.
The board has a power-hold circuit controlled by GPIO3_21 (DT label &gpio2,
pin 21): driving it high cuts power. Add a gpio-poweroff node and enable
the driver so 'systemctl poweroff' actually turns the device off instead
of halting the CPU in an undefined state.
- DTS: gpio-poweroff node on &gpio2 21 active-high, 1s timeout
- Kernel: CONFIG_POWER_RESET_GPIO=y (must be builtin, not module)
* rockchip64: bump some boards u-boot to v2026.04
* OrangePi4 LTS
* Radxa Rockpi-E
* Dusun DSOM 010R
* rk3318-box tv box series
* get rid of disabled u-boot patch
* rockchip64: fix minor mistakes in CSC boards defconfig/dts
- those were added to ensure that code was actually being compiled
- we're pretty sure now, so avoid spurious warnings during compilation
Signed-off-by: Ricardo Pardini <ricardo@pardini.net>
