ti: configs: family: k3: Update baseline to 12.00.00.07#9643
Draft
jonaswood01 wants to merge 2 commits intoarmbian:mainfrom
Draft
ti: configs: family: k3: Update baseline to 12.00.00.07#9643jonaswood01 wants to merge 2 commits intoarmbian:mainfrom
jonaswood01 wants to merge 2 commits intoarmbian:mainfrom
Conversation
Signed-off-by: Jonas Wood <jw@ti.com>
Signed-off-by: Jonas Wood <jw@ti.com>
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
📝 WalkthroughWalkthroughUpdates board-specific boot and ATF configurations for multiple TI K3 SoC variants, transitions boot targets from am6254xxl to am6254atl, switches ATF platform from am62l to am62lx, updates OP-TEE platform reference, and bumps TI Processor SDK, kernel, and boot versions across multiple branch variants with new commit references. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
github-actions
bot
added
05
Collaborator
|
@coderabbitai review |
Contributor
✅ Actions performedReview triggered.
|
1 similar comment
Contributor
✅ Actions performedReview triggered.
|
tabrisnet
reviewed
Apr 9, 2026
| ATF_BOARD="am62l" | ||
| EXTRA_ATF_TARGETS="build/k3/am62l/release/bl1.bin:bl1.bin" | ||
| ATF_BOARD="am62lx" | ||
| EXTRA_ATF_TARGETS="build/k3low/am62lx/release/bl1.bin:bl1.bin" |
Collaborator
There was a problem hiding this comment.
I am curious, will these patterns persist?
e.g.
Suggested change
| EXTRA_ATF_TARGETS="build/k3low/am62lx/release/bl1.bin:bl1.bin" | |
| EXTRA_ATF_TARGETS="build/k3low/${ATF_BOARD}/release/bl1.bin:bl1.bin" |
otoh, if k3 vs k3low keeps changing it doesn't help much.
also given ATF_PLAT="k3low" in config/sources/families/include/k3_common.inc
it could become
Suggested change
| EXTRA_ATF_TARGETS="build/k3low/am62lx/release/bl1.bin:bl1.bin" | |
| EXTRA_ATF_TARGETS="build/${ATF_PLAT}/${ATF_BOARD}/release/bl1.bin:bl1.bin" |
with the additional caveat that k3_common.inc would need to be included up near the top.
@coderabbitai - these might be good, these might be bad/unnecessary/unhelpful.
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check how ATF_PLAT is set in k3_common.inc
echo "=== k3_common.inc ATF_PLAT and EXTRA_ATF_TARGETS ==="
grep -n "ATF_PLAT\|EXTRA_ATF_TARGETS\|ATF_BOARD\|ATF_TARGET_MAP\|k3low\|k3_common" config/sources/families/include/k3_common.inc
echo ""
echo "=== k3.conf: inclusion of k3_common.inc and ATF_PLAT ==="
grep -n "ATF_PLAT\|k3_common\|source\|EXTRA_ATF\|ATF_BOARD" config/sources/families/k3.conf
echo ""
echo "=== All K3 boards using EXTRA_ATF_TARGETS ==="
grep -rn "EXTRA_ATF_TARGETS" config/boards/ --include="*.conf" --include="*.csc" --include="*.wip" --include="*.eos"
echo ""
echo "=== How/when k3_common.inc is sourced relative to board conf ==="
grep -rn "k3_common\|source.*include\|family_source\|board_config" lib/functions/ --include="*.sh" | head -40
echo ""
echo "=== Check if ATF_PLAT is a declare -g or local in k3_common.inc ==="
grep -n "declare\|ATF_PLAT" config/sources/families/include/k3_common.inc | head -30
Length of output: 5254
@tabrisnet Here's a breakdown of the feasibility of each suggestion:
${ATF_BOARD} substitution — ✅ Works
ATF_BOARD is set on the line immediately before EXTRA_ATF_TARGETS in tmds62levm.conf, so bash expands it at assignment time. This is a valid improvement to avoid repeating the board identifier:
ATF_BOARD="am62lx"
EXTRA_ATF_TARGETS="build/k3low/${ATF_BOARD}/release/bl1.bin:bl1.bin"${ATF_PLAT} substitution — ❌ Does not work as-is
The sourcing order is the problem:
- Board conf (
tmds62levm.conf) is sourced first (lib/functions/main/config-prepare.sh) - Family conf (
k3.conf) — which sourcesk3_common.inc— is sourced after (lib/functions/configuration/main-config.sh)
ATF_PLAT is a plain (non-declare -g) assignment at line 44/46 of k3_common.inc, set only when that file is sourced. At the time EXTRA_ATF_TARGETS is evaluated in the board conf, ATF_PLAT is undefined and would expand to an empty string, producing a broken path. So k3_common.inc would indeed need to be sourced earlier — a non-trivial architectural change, as you noted.
Alternative worth considering: Since k3_common.inc already gates on BOOT_SOC="am62l" to set ATF_PLAT="k3low", the bl1.bin append could be moved entirely into k3_common.inc — conditionally appending it to ATF_TARGET_MAP when BOOT_SOC="am62l". This would eliminate EXTRA_ATF_TARGETS from tmds62levm.conf altogether (it's the only K3 board using it), and keep the k3low + bl1.bin logic co-located with the ATF_PLAT logic that already exists there:
# In k3_common.inc, after ATF_PLAT is set:
ATF_PLAT="k3"
if [[ "${BOOT_SOC}" == "am62l" ]]; then
ATF_PLAT="k3low"
EXTRA_ATF_TARGETS="build/${ATF_PLAT}/${ATF_BOARD}/release/bl1.bin:bl1.bin"
fi
ATF_TARGET_MAP="... ${EXTRA_ATF_TARGETS}"This would be the cleanest approach if the k3low/bl1.bin pattern is expected to persist only for am62l-family boards.
🧠 Learnings used
Learnt from: Grippy98
Repo: armbian/build PR: 8624
File: config/boards/sk-am62p.conf:8-8
Timestamp: 2026-02-03T19:44:53.554Z
Learning: For TI K3 family boards in Armbian, BOOT_FDT_FILE uses .dts extension (not .dtb) as the standard convention. The build system handles this correctly by automatically compiling .dts to .dtb during kernel build and using the BOOT_FDT_FILE value directly in bootloader configurations.
Learnt from: glneo
Repo: armbian/build PR: 9349
File: config/boards/pocketbeagle2.conf:19-19
Timestamp: 2026-02-03T19:44:41.657Z
Learning: In Armbian board config files under config/boards, ensure BOOT_FDT_FILE uses the .dtb extension (not .dts). The vast majority of boards use .dtb across families; only legacy TI K3 boards historically used .dts. Apply this rule broadly to board config files and correct the anomaly where encountered.
Learnt from: igorpecovnik
Repo: armbian/build PR: 8849
File: config/boards/radxa-e54c.csc:14-28
Timestamp: 2025-11-02T20:49:56.719Z
Learning: In Armbian board configuration files (config/boards/*.conf, *.csc, etc.), do not use kernel_config_set, kernel_config_set_m, kernel_config_set_y, or custom_kernel_config__* functions to modify kernel configuration. Kernel configuration is associated with LINUXFAMILY/BOARDFAMILY, not individual BOARD. Board-specific kernel modifications cause inconsistency in kernel packages published to the apt repository because boards within a family share the same kernel packages. Kernel configuration changes must be made in the appropriate kernel config file (e.g., config/kernel/linux-*-*.config) or in family configuration files (config/sources/families/*.conf, *.inc) instead.
Learnt from: bryanbrattlof
Repo: armbian/build PR: 9081
File: config/boards/sk-am62-sip.conf:18-20
Timestamp: 2025-12-15T23:26:40.214Z
Learning: For TI K3 SoC boards with only 512MB of DDR (like SK-AM62-SIP), OP-TEE (BL32) and TFA must be placed at the bottom of DDR (e.g., BL32_BASE=0x80080000, CFG_TZDRAM_START=0x80080000) rather than the standard high-memory layout. This is necessary because U-Boot relocates itself to the highest DDR address (up to 2GB max) during bootup, which would overwrite OP-TEE/TFA if they were placed at the top of the 512MB DDR region. PRELOADED_BL33_BASE is typically set to 0x82000000 in this configuration.
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: tabrisnet
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-08-30T06:48:09.091Z
Learning: In lib/functions/compilation/armbian-kernel.sh, the user prefers flexible grep patterns over anchored ones for BTRFS configuration checks, but agrees to use quiet grep (-q) to avoid polluting build logs.
Learnt from: Grippy98
Repo: armbian/build PR: 8622
File: config/sources/families/k3.conf:66-66
Timestamp: 2025-09-12T19:28:38.491Z
Learning: In the Armbian k3 family build system (config/sources/families/k3.conf), builds do not fail when TIBOOT3_BOOTCONFIG is unset, even though tiboot3.bin is still listed in UBOOT_TARGET_MAP. The gating mechanism in pre_config_uboot_target__build_first_stage function works as intended to conditionally build/copy tiboot3.bin only when TIBOOT3_BOOTCONFIG is defined.
Learnt from: SuperKali
Repo: armbian/build PR: 9642
File: extensions/image-output-arduino.sh:4-7
Timestamp: 2026-04-08T14:07:34.831Z
Learning: In the Armbian build system (armbian/build), family-specific variables (e.g., `QCOMBIN_DIR`) declared with `declare -g` in `config/sources/families/*.conf` are always sourced before extension hooks such as `post_family_config__*` or `post_build_image__*` run. Therefore, do not flag usages of such variables in extension scripts as "undefined" — the family conf is the canonical place to declare them, and they are reliably available to all subsequent hooks.
Learnt from: EvilOlaf
Repo: armbian/build PR: 9423
File: config/boards/dg-svr-865-tiny.conf:1-1
Timestamp: 2026-02-21T06:27:17.017Z
Learning: Enforce that the first line comment in Armbian board configuration files (e.g., config/boards/*.conf, and related boards files with extensions like *.csc, *.wip) contains a dedicated hardware feature description, not a description of what the file generates. The comment must specify: SoC model, core count, RAM options, and key features (connectivity options, storage interfaces, special features). This text is used during interactive compilation, so accuracy and completeness matter. For any new board config file, flag if the first-line comment is not descriptive of the hardware (e.g., prefer '# Qualcomm QCS8250 octa core 4GB-16GB eMMC GBE USB3 WiFi BT' over '# Generate kernel and rootfs image...').
Learnt from: rpardini
Repo: armbian/build PR: 9159
File: patch/u-boot/u-boot-genio/0026-dts-configs-add-Grinn-GenioSBC-510.patch:161-161
Timestamp: 2026-01-03T20:46:29.189Z
Learning: For the Armbian genio family (config/sources/families/genio.conf and patch/u-boot/u-boot-genio/), when reviewing PRs that include vendor U-Boot patches from Collabora, avoid flagging potential issues in board configurations that are out of scope for the PR's primary focus (e.g., don't flag Genio 510/700 board issues when the PR is focused on radxa-nio-12l/Genio 1200). The maintainer prioritizes keeping vendor patches close to upstream for easier re-copying and maintenance, even if secondary board configs have potential mismatches.
<!-- </add_learning>
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-12-19T13:56:45.124Z
Learning: When reviewing kernel or u-boot version bump PRs in the Armbian build system, check if patches existed in previous kernel version directories (e.g., sunxi-6.12, sunxi-6.13) before describing them as new features. If a patch and the majority of its contents existed previously with no major functionality changes, focus the review on the actual changes: the version bump itself and patch compatibility adjustments. Don't describe existing patches being ported/maintained across versions as new features or drivers—this is misleading. The patches are existing code being re-aligned to work with the new upstream version.
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 or the PR API to get the complete picture of what files are being added or modified.
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2026-03-25T17:36:06.301Z
Learning: In the Armbian build system, when a PR title indicates a "rewrite" of kernel patches against a new kernel version (e.g., "rewrite kernel patches against 6.18.20" in patch/kernel/archive/rockchip64-6.18/), only the patch context lines change — the surrounding unchanged lines in the patch hunks are updated to match the new kernel base. The actual code changes introduced by the patches remain identical. Do NOT describe context-line adjustments as additions, removals, or fixes in summaries or reviews. The correct description is: "patches rewritten against kernel X.Y.Z; only patch context lines updated, no functional changes."
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.
Learnt from: tabrisnet
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2026-03-10T18:21:19.637Z
Learning: In `lib/functions/rootfs/rootfs-create.sh` (PR `#9512`), the `mmdebstrap_branch` is intentionally left as a floating `branch:main` reference, consistent with how the legacy `debootstrap` for Debian was handled (also a floating reference). Only the Ubuntu debootstrap variant previously had a pinned tag. Any change to fold the mmdebstrap revision into the rootfs cache key (`calculate_rootfs_cache_id()`) must also surface the fetched commit hash prominently in build logs and the OCI tag to avoid silent, unexplained rebuilds; this should be done in a separate, self-contained PR.
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-07-21T04:12:02.439Z
Learning: In the Armbian build system, for recurring maintenance tasks like kernel version bumping, TODO comments should use generic version formats (e.g., "MAJOR.MINOR-rc1") rather than specific version numbers (e.g., "6.17-rc1") to avoid the need for frequent comment updates that would create unnecessary maintenance overhead.
Learnt from: HackingGate
Repo: armbian/build PR: 9535
File: patch/kernel/archive/rockchip64-6.18/rk3576-0007-counter-rockchip-pwm-capture-driver.patch:287-305
Timestamp: 2026-03-21T07:37:45.706Z
Learning: In the Armbian build system, kernel patches under `patch/kernel/archive/` that originated from the Linux kernel mailing list (identifiable by upstream authorship, `Signed-off-by` from known upstream contributors/companies like Collabora, and a `From <hash> Mon Sep 17...` git format-patch header) should NOT be reviewed. They are upstream patches being ported/maintained in Armbian's kernel archive directories (e.g., `patch/kernel/archive/rockchip64-6.18/`) and are out of scope for code review. Only Armbian-specific integration changes around these patches are in scope.
tabrisnet
reviewed
Apr 9, 2026
| declare -g LINUXFAMILY="k3" | ||
| declare -g ATFSOURCE="https://github.com/ARM-software/arm-trusted-firmware" | ||
|
|
||
| case "${BRANCH}" in |
Collaborator
There was a problem hiding this comment.
I see edge added in config/boards/sk-am62-sip.conf
but there's no default case for the bootloader based on edge kernel, and no abort/exit_with_error if there is no match for this case.
can it even boot in such a case?
@coderabbitai - am I missing something?
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
Good question — let me check the full k3_common.inc and sk-am62-sip.conf to see if there's any fallback bootloader configuration for the edge branch.
🏁 Script executed:
#!/bin/bash
# Check full content of k3_common.inc
fd -t f "k3_common.inc" --exec cat {}
echo "---sk-am62-sip.conf---"
fd -t f "sk-am62-sip.conf" --exec cat {}
echo "---k3.conf full---"
fd -t f "k3.conf" --exec cat {}
Length of output: 7338
@tabrisnet — you're not missing something wrong, but the edge case is actually handled — just not in k3.conf. It's in k3_common.inc, which is sourced at the very top of k3.conf:
source "${BASH_SOURCE%/*}/include/k3_common.inc"k3_common.inc has its own case "${BRANCH}" in block that explicitly covers edge:
edge) # experimental (limited testing): uses latest bleeding-edge upstream mainline version
# KERNELSOURCE defined in mainline-config.sh
# KERNELBRANCH defined in mainline-kernel.conf.sh
declare -g KERNEL_MAJOR_MINOR="6.18"
declare -g KERNEL_DESCRIPTION="Latest upstream mainline kernel"
declare -g ATFBRANCH="branch:master"
declare -g OPTEE_BRANCH="branch:master"
declare -g TI_LINUX_FIRMWARE_BRANCH="branch:ti-linux-firmware"
declare -g BOOTSOURCE="https://github.com/u-boot/u-boot"
declare -g BOOTBRANCH="branch:master"
;;So for BRANCH=edge, the bootloader configuration is fully set — it uses mainline U-Boot (branch:master) and upstream ATF/OP-TEE (branch:master).
One secondary concern worth flagging to @jonaswood01: sk-am62-sip.conf sets BOOTCONFIG="am6254atl_evm_a53_defconfig" and TIBOOT3_BOOTCONFIG="am6254atl_evm_r5_defconfig" — these are TI-specific defconfigs. It's worth verifying that mainline U-Boot (https://github.com/u-boot/u-boot, branch:master) actually ships these defconfigs, otherwise the edge build would fail at the U-Boot configuration step even though all the branch variables are properly set.
🧠 Learnings used
Learnt from: tabrisnet
Repo: armbian/build PR: 8913
File: config/sources/families/k3-beagle.conf:16-16
Timestamp: 2025-11-10T22:05:40.490Z
Learning: In the Armbian build system, kernel branches using non-mainline/vendor forks (like BeagleBoard's linux repository) should be named "vendor" or "vendor-rt" rather than "current" or "edge". The "current" and "edge" naming is reserved for mainline kernel branches. This affects both the case statement in family config files (e.g., `vendor | vendor-rt)` instead of `current | current-rt)`) and the corresponding KERNEL_TARGET declarations in board config files.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8330
File: config/sources/families/sun55iw3.conf:32-36
Timestamp: 2025-06-25T03:42:09.086Z
Learning: In Armbian build system configuration files like config/sources/families/*.conf, KERNELSOURCE is explicitly declared when using unofficial or 3rd party kernel repositories (like the "dev" branch using https://github.com/apritzel/linux), but can be omitted when using the standard mainline kernel (like the "edge" branch) since it will fall back to the default mainline source.
Learnt from: tabrisnet
Repo: armbian/build PR: 9058
File: config/sources/families/spacemit.conf:39-45
Timestamp: 2025-12-12T23:09:56.813Z
Learning: In Armbian build configs for vendor kernel sources, prefer the following branch naming conventions: use 'vendor' or 'vendor-rt' for stable vendor releases, and 'vendor-edge' for bleeding-edge/pre-release vendor versions. The 'edge' naming without the 'vendor-' prefix is reserved for mainline kernel branches. Apply this pattern to family config files under config/sources/families (e.g., spacemit.conf) to ensure consistent vendor kernel sourcing naming across the repository.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8330
File: config/sources/families/sun55iw3.conf:32-36
Timestamp: 2025-06-25T03:40:52.109Z
Learning: In Armbian build system configuration files like config/sources/families/*.conf, when KERNELSOURCE is not explicitly declared in a case branch, the system falls back to a default KERNELSOURCE value, so missing KERNELSOURCE declarations are not critical issues.
Learnt from: amazingfate
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:64-70
Timestamp: 2025-09-14T06:29:18.958Z
Learning: In the Armbian build system, vendor branch configurations in family files are designed to be shared across multiple SoCs within the same family that use the same vendor kernel tree. For example, rk35xx and rockchip-rk3588 families both use identical vendor branch settings (same KERNELSOURCE, KERNELBRANCH, and KERNELPATCHDIR), demonstrating that vendor branches are intentionally generic rather than SoC-specific.
Learnt from: HackingGate
Repo: armbian/build PR: 8665
File: config/boards/photonicat2.csc:4-4
Timestamp: 2025-10-26T10:41:35.118Z
Learning: In the Armbian build system, rk3576 boards consistently use BOARDFAMILY="rk35xx" for both vendor and edge kernel targets. The rk35xx family configuration sources rockchip64_common.inc, which provides edge and current kernel branch definitions, making these branches available even though they're not defined directly in rk35xx.conf.
Learnt from: igorpecovnik
Repo: armbian/build PR: 8849
File: config/boards/radxa-e54c.csc:14-28
Timestamp: 2025-11-02T20:49:56.719Z
Learning: In Armbian board configuration files (config/boards/*.conf, *.csc, etc.), do not use kernel_config_set, kernel_config_set_m, kernel_config_set_y, or custom_kernel_config__* functions to modify kernel configuration. Kernel configuration is associated with LINUXFAMILY/BOARDFAMILY, not individual BOARD. Board-specific kernel modifications cause inconsistency in kernel packages published to the apt repository because boards within a family share the same kernel packages. Kernel configuration changes must be made in the appropriate kernel config file (e.g., config/kernel/linux-*-*.config) or in family configuration files (config/sources/families/*.conf, *.inc) instead.
Learnt from: Grippy98
Repo: armbian/build PR: 8622
File: config/sources/families/k3.conf:66-66
Timestamp: 2025-09-12T19:28:38.491Z
Learning: In the Armbian k3 family build system (config/sources/families/k3.conf), builds do not fail when TIBOOT3_BOOTCONFIG is unset, even though tiboot3.bin is still listed in UBOOT_TARGET_MAP. The gating mechanism in pre_config_uboot_target__build_first_stage function works as intended to conditionally build/copy tiboot3.bin only when TIBOOT3_BOOTCONFIG is defined.
Learnt from: Grippy98
Repo: armbian/build PR: 8152
File: lib/functions/configuration/interactive.sh:209-266
Timestamp: 2025-05-05T12:35:07.143Z
Learning: For the interactive kernel selection in Armbian, KERNEL_MAJOR_MINOR and KERNEL_DESCRIPTION are parsed from family.conf but deliberately not set as environment variables to avoid potential interference with other parts of the build system.
Learnt from: The-going
Repo: armbian/build PR: 8147
File: config/sources/families/include/sunxi64_common.inc:38-39
Timestamp: 2025-04-30T16:16:47.150Z
Learning: The Armbian build system references Linux kernel versions in the form "tag:v6.14.4" in the KERNELBRANCH variable, even when point release tags might not be directly visible in the upstream repository in the same form.
Learnt from: pyavitz
Repo: armbian/build PR: 9458
File: config/boards/orangepirv2.wip:6-6
Timestamp: 2026-03-01T15:02:47.307Z
Learning: For the Orange Pi RV2 board (config/boards/orangepirv2.wip), edge kernel support is temporarily excluded from KERNEL_TARGET until boot testing on linux-7.0.y is complete. The edge-specific case block for BCMDHD WiFi extension is retained for future enablement post-testing.
Learnt from: HeyMeco
Repo: armbian/build PR: 9421
File: config/boards/radxa-rock-4d.conf:19-53
Timestamp: 2026-02-20T20:44:07.729Z
Learning: For the Radxa Rock 4D board (config/boards/radxa-rock-4d.conf), the post_family_config__rock4d_use_mainline_uboot() function intentionally has no branch guard because mainline U-Boot is used for BOTH vendor and edge kernel branches. The companion functions (post_config_uboot_target__rock4d_enable_ufs_and_spi_env and pre_config_uboot_target__rock4d_boot_order) correctly guard against vendor branch to apply UFS support and boot order changes only to the edge branch.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8754
File: config/boards/bestv-r3300-l.csc:14-16
Timestamp: 2025-10-14T05:08:11.785Z
Learning: In the Armbian build system, BOOTBRANCH_BOARD is a valid framework variable used as a fallback when BOOTBRANCH is unset. The framework checks BOOTBRANCH_BOARD before applying the default bootloader branch value (see config/sources/common.conf). Board configuration files can use BOOTBRANCH_BOARD to specify the bootloader branch.
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: tabrisnet
Repo: armbian/build PR: 8746
File: config/sources/families/filogic.conf:61-68
Timestamp: 2025-10-13T02:26:18.249Z
Learning: In the Armbian build system, the "edge" kernel branch is intended to be bleeding-edge and experimental. It does not require hardware testing or stability verification before merging, as it's expected to contain potentially unstable or untested code for early adopters and developers.
Learnt from: leggewie
Repo: armbian/build PR: 8524
File: config/boards/orangepi2.csc:6-6
Timestamp: 2025-08-21T08:10:59.502Z
Learning: Not all Armbian boards support all kernel versions (legacy, current, edge). Some boards may only support specific kernel versions due to hardware limitations or lack of mainline support, which is why their KERNEL_TARGET contains only the supported options (e.g., just "legacy").
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: 0
File: :0-0
Timestamp: 2026-03-25T17:36:06.301Z
Learning: In the Armbian build system, when a PR title indicates a "rewrite" of kernel patches against a new kernel version (e.g., "rewrite kernel patches against 6.18.20" in patch/kernel/archive/rockchip64-6.18/), only the patch context lines change — the surrounding unchanged lines in the patch hunks are updated to match the new kernel base. The actual code changes introduced by the patches remain identical. Do NOT describe context-line adjustments as additions, removals, or fixes in summaries or reviews. The correct description is: "patches rewritten against kernel X.Y.Z; only patch context lines updated, no functional changes."
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-12-19T13:56:45.124Z
Learning: When reviewing kernel or u-boot version bump PRs in the Armbian build system, check if patches existed in previous kernel version directories (e.g., sunxi-6.12, sunxi-6.13) before describing them as new features. If a patch and the majority of its contents existed previously with no major functionality changes, focus the review on the actual changes: the version bump itself and patch compatibility adjustments. Don't describe existing patches being ported/maintained across versions as new features or drivers—this is misleading. The patches are existing code being re-aligned to work with the new upstream version.
Learnt from: rpardini
Repo: armbian/build PR: 9159
File: patch/u-boot/u-boot-genio/0026-dts-configs-add-Grinn-GenioSBC-510.patch:161-161
Timestamp: 2026-01-03T20:46:29.189Z
Learning: For the Armbian genio family (config/sources/families/genio.conf and patch/u-boot/u-boot-genio/), when reviewing PRs that include vendor U-Boot patches from Collabora, avoid flagging potential issues in board configurations that are out of scope for the PR's primary focus (e.g., don't flag Genio 510/700 board issues when the PR is focused on radxa-nio-12l/Genio 1200). The maintainer prioritizes keeping vendor patches close to upstream for easier re-copying and maintenance, even if secondary board configs have potential mismatches.
<!-- </add_learning>
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2026-03-18T16:31:36.035Z
Learning: In patch files for the Armbian build system (e.g., patch/kernel/archive/sunxi-6.18/patches.armbian/), lines visible in a diff hunk that are prefixed with a space are context lines — they are unchanged surrounding content, not modifications introduced by the PR. Never describe context lines as additions or new code in summaries or reviews. Only lines with `+` or `-` prefixes represent actual changes. Misidentifying context lines as additions leads to incorrect summaries (e.g., falsely claiming a closing brace or `#endif` was "added" when it was already present).
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 or the PR API to get the complete picture of what files are being added or modified.
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.
Learnt from: tabrisnet
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2026-03-10T18:21:19.637Z
Learning: In `lib/functions/rootfs/rootfs-create.sh` (PR `#9512`), the `mmdebstrap_branch` is intentionally left as a floating `branch:main` reference, consistent with how the legacy `debootstrap` for Debian was handled (also a floating reference). Only the Ubuntu debootstrap variant previously had a pinned tag. Any change to fold the mmdebstrap revision into the rootfs cache key (`calculate_rootfs_cache_id()`) must also surface the fetched commit hash prominently in build logs and the OCI tag to avoid silent, unexplained rebuilds; this should be done in a separate, self-contained PR.
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-07-21T04:12:02.439Z
Learning: In the Armbian build system, for recurring maintenance tasks like kernel version bumping, TODO comments should use generic version formats (e.g., "MAJOR.MINOR-rc1") rather than specific version numbers (e.g., "6.17-rc1") to avoid the need for frequent comment updates that would create unnecessary maintenance overhead.
Learnt from: HackingGate
Repo: armbian/build PR: 9535
File: patch/kernel/archive/rockchip64-6.18/rk3576-0007-counter-rockchip-pwm-capture-driver.patch:287-305
Timestamp: 2026-03-21T07:37:45.706Z
Learning: In the Armbian build system, kernel patches under `patch/kernel/archive/` that originated from the Linux kernel mailing list (identifiable by upstream authorship, `Signed-off-by` from known upstream contributors/companies like Collabora, and a `From <hash> Mon Sep 17...` git format-patch header) should NOT be reviewed. They are upstream patches being ported/maintained in Armbian's kernel archive directories (e.g., `patch/kernel/archive/rockchip64-6.18/`) and are out of scope for code review. Only Armbian-specific integration changes around these patches are in scope.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
How Has This Been Tested?
sk-am62-lp: build log, boots ?sk-am62-sip: build log, boots ?sk-am62b: build log, boots ?sk-am62p: build log, boots ?tmds62levm: build log, boots ?sk-am64b: build log, boots ?sk-am68: build log, boot not testedsk-am69: build log, boot not testedsk-tda4vm: build log, boot not testedNotes:
vendorbranch recently, prior to public release of imagesChecklist:
Summary by CodeRabbit