Split cb1-overlay.patch into separate patches for overlays and Makefile changes

[coderabbitai]

Description

The patch file patch/kernel/archive/sunxi-6.18/patches.armbian/cb1-overlay.patch currently combines two distinct changes that should be separated into individual patches:

1. CB1 device tree overlays: Addition of sun50i-h616 overlay files (.dtso files) for various peripherals (SPI, IR, light sensor, CAN, etc.)
2. Fixup script build support: Changes to scripts/Makefile.lib to add mkimage-based fixup script creation functionality

Requested Action

Split this patch into two separate patches:

• One patch containing only the CB1-specific device tree overlay additions
• Another patch containing the scripts/Makefile.lib changes for fixup script handling

Context

• Pull Request: sunxi: bump edge to 6.18 #9049
• Comment: sunxi: bump edge to 6.18 #9049 (comment)
• Requested by: @EvilOlaf

This separation will improve patch organization and make it clearer which changes relate to CB1 hardware support versus build system enhancements.

[github-actions]

Jira ticket: AR-2800

[EvilOlaf]

@coderabbitai: As per https://github.com/armbian/build/blob/main/patch/kernel/archive/sunxi-6.18/series.conf all patches are applied in a certain order. At which position from a logical point of view would it make sense to place both patches, assuming there is no inherent breakage later on?

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Read the series.conf file to understand patch ordering
cat patch/kernel/archive/sunxi-6.18/series.conf

Length of output: 42722

---

🏁 Script executed:

#!/bin/bash
# Read the cb1-overlay.patch to understand its content
cat patch/kernel/archive/sunxi-6.18/patches.armbian/cb1-overlay.patch

Length of output: 14344

---

@EvilOlaf, based on my analysis of the series.conf structure and the content of cb1-overlay.patch, here's my recommendation for the logical placement of the two split patches:

Patch Placement Recommendation

Patch 1: scripts/Makefile.lib changes (fixup script build support)

Suggested location: After line with Makefile-CONFIG_SHELL-fix-for-builddeb-packaging.patch (approximately line 339 in the current series.conf)

This patch adds build system infrastructure for creating mkimage-based fixup scripts. It should be placed with other build system/Makefile patches in the overlay infrastructure section, specifically:

scripts-add-overlay-compilation-support.patch
Enable-creation-of-__symbols__-node.patch
Makefile-CONFIG_SHELL-fix-for-builddeb-packaging.patch
[NEW: scripts-Makefile-lib-Add-fixup-script-mkimage-support.patch]  ← Insert here
arm-dts-overlay-Add-Overlays-for-sunxi.patch

Rationale: This is build infrastructure that enables functionality used by later patches. It doesn't depend on any device-specific code and should come before patches that use it.

Patch 2: CB1 H616 overlays (device tree overlay additions)

Suggested location: After the H5 overlay patches, approximately after arm64-dts-overlay-sun50i-h5-add-gpio-regulator-overclock.patch or near other H616-specific patches

arm64-dts-overlay-sun50i-h5-add-gpio-regulator-overclock.patch
Move-sun50i-h6-pwm-settings-to-its-own-overlay.patch
Compile-the-pwm-overlay.patch
[NEW: arm64-dts-overlay-sun50i-h616-Add-CB1-overlays.patch]  ← Insert here
cb1-overlay.patch  ← Remove this one
Correct-perf-interrupt-source-number...patch

Rationale: This groups the CB1 overlay additions with other overlay-related patches for similar platforms (H5/H6/H616). The CB1 overlays depend on the fixup script infrastructure added in Patch 1, so Patch 1 must come first.

Summary

The key principle is: build infrastructure before device-specific usage. The scripts/Makefile.lib changes enable functionality that the CB1 overlays may utilize (specifically the fixup script for H616), so the Makefile patch must be applied before the overlay patch in the series.

---

🧠 Learnings used

Learnt from: rpardini
Repo: armbian/build PR: 8044
File: patch/u-boot/v2025.04/cmd-fileenv-read-string-from-file-into-env.patch:76-86
Timestamp: 2025-03-31T22:20:48.475Z
Learning: For the Armbian build project, maintaining consistency with existing patches across U-Boot versions (such as between 2025.01 and 2025.04) is prioritized over refactoring individual patches for code improvements.

---

Learnt from: amazingfate
Repo: armbian/build PR: 8453
File: lib/functions/compilation/patch/drivers_network.sh:213-216
Timestamp: 2025-08-02T14:59:28.145Z
Learning: The wireless driver patches wireless-rtl8812au-Fix-6.16.patch, wireless-rtl8811cu-Fix-6.16.patch, and wireless-rtl88x2bu-Fix-6.16.patch in the Armbian build system are backward compatible and can be applied unconditionally without version checks, even though they're named for 6.16+ fixes.

---

Learnt from: amazingfate
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:65-72
Timestamp: 2025-09-14T11:37:35.089Z
Learning: In the Armbian build system, patch directories referenced in BOOTPATCHDIR and KERNELPATCHDIR configurations can be non-existent without causing build failures. Empty patch directories are also ignored by git, so missing patch directories should not be flagged as errors during code review.

---

Learnt from: EvilOlaf
Repo: armbian/build PR: 8417
File: config/boards/orangepi5pro.csc:57-58
Timestamp: 2025-07-23T07:30:52.265Z
Learning: In the Armbian build system, BOOTPATCHDIR can contain board-specific subdirectories (e.g., board_orangepi5pro) for applying patches to specific boards only. The framework automatically checks if such board-specific subdirectories exist for the board being built and applies those patches accordingly.

---

Learnt from: rpardini
Repo: armbian/build PR: 8044
File: patch/u-boot/v2025.04/cmd-fileenv-read-string-from-file-into-env.patch:73-75
Timestamp: 2025-03-31T22:20:41.849Z
Learning: When porting patches between U-Boot versions (like from 2025.01 to 2025.04), rpardini prefers to maintain patches as-is rather than introducing refactoring changes, even when potential improvements are identified. This approach prioritizes consistency and reduces the risk of introducing new issues.

---

Learnt from: pyavitz
Repo: armbian/build PR: 9058
File: patch/u-boot/legacy/u-boot-spacemit-k1/003-SpacemiT-K1X-Fixups.patch:28-67
Timestamp: 2025-12-13T11:39:08.046Z
Learning: In the Armbian build system for SpacemiT U-Boot patches (patch/u-boot/legacy/u-boot-spacemit-k1/), alignment with mainline U-Boot behavior is prioritized. For example, in boot mode handling, leaving devnum unchanged in the default case (when devtype is cleared) follows mainline conventions rather than explicitly clearing it to handle edge cases.

---

Learnt from: EvilOlaf
Repo: armbian/build PR: 8968
File: patch/u-boot/u-boot-sunxi/arm64-dts-sun50i-h6-orangepi.dtsi-Rollback-r_rsb-to-r_i2c.patch:36-36
Timestamp: 2025-11-20T18:20:11.985Z
Learning: The rewrite-patches tool (REWRITE_PATCHES=yes) in the Armbian build system can inadvertently introduce semantic changes when the u-boot/kernel git base revision differs from expected state. The tool applies patches, commits them, and re-exports them using git format-patch, which can cause the re-exported patch to reflect the base revision's state rather than preserving the original patch intent. This is particularly problematic for device tree changes like interrupt specifications. The tool currently lacks validation mechanisms to detect such semantic drift, and affected patches must be manually corrected after rewriting.

---

Learnt from: SuperKali
Repo: armbian/build PR: 8608
File: lib/functions/compilation/patch/drivers_network.sh:361-363
Timestamp: 2025-09-11T06:06:52.328Z
Learning: For the RTW88 SDIO RF path detection fix patch (004-rtw88-sdio-rf-path-detection-fix.patch), SuperKali prefers using exact version matching (eq 6.1 || eq 6.16) rather than range checks, as the patch has only been tested on those specific kernel versions and may be mainstreamed soon.

---

Learnt from: EvilOlaf
Repo: armbian/build PR: 8298
File: extensions/https_proxy.sh:1-9
Timestamp: 2025-06-14T05:53:10.627Z
Learning: Armbian build framework extensions are NOT designed to run standalone but are called by the supervisor. The framework provides environment variables like USERPATCHES_PATH and SDCARD, and commands are executed with protection via run_host_command_logged and chroot_sdcard functions that use bash -e -o pipefail.

---

Learnt from: rpardini
Repo: armbian/build PR: 8879
File: config/sources/families/uefi-x86.conf:0-0
Timestamp: 2025-11-06T15:36:04.682Z
Learning: As of PR #8879, the uefi-x86 family in the Armbian build system now includes kernel patches for the first time. The current and edge branches for uefi-x86 are specifically configured for Apple T2-based x86 machines, including T2-specific patches from the linux-t2 project and custom kernel configuration options for Apple hardware drivers.

---

Learnt from: leggewie
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-08-29T18:44:47.732Z
Learning: When creating GitHub issues for code improvements in the Armbian build project, include the relevant patches/diffs in the issue description or open a PR directly instead of just describing the changes. This makes it more efficient for the assignee to handle the improvements.

---

Learnt from: glneo
Repo: armbian/build PR: 8913
File: config/sources/families/include/k3_common.inc:57-60
Timestamp: 2025-11-11T20:56:20.303Z
Learning: In config/sources/families/include/k3_common.inc, the OP-TEE build command at line 59 should be updated in a future PR to explicitly set CROSS_COMPILE64=aarch64-linux-gnu- and CROSS_COMPILE32=arm-linux-gnueabihf- instead of relying on OP-TEE's internal defaults, for better clarity and maintainability. User glneo agreed to address this in a separate PR.

---

Learnt from: EvilOlaf
Repo: armbian/build PR: 8428
File: config/boards/lckfb-taishanpi.csc:5-9
Timestamp: 2025-07-25T03:51:50.830Z
Learning: When reviewing PRs in the Armbian build system, U-Boot defconfig files and patches may be added as part of the PR changes but might not be visible in the current repository clone state during review. It's important to check the actual PR file changes directly via GitHub API (https://api.github.com/repos/armbian/build/pulls/{pr_number}/files) to get the complete picture of what files are being added or modified, especially for U-Boot patches that will be applied during the build process.