enable uboot btrfs for N2

[leggewie]

This supersedes #9007 after #9010 landed with its reusable uboot-btrfs extension. It keeps work from @iav and enables the uboot-btrfs extension.

Summary by CodeRabbit

Release Notes

• New Features

  • Added btrfs filesystem support for Odroid N2 boards.

• Bug Fixes

  • Improved MMC stability by adjusting frequency settings on Odroid N2.

• Chores

  • Updated bootloader to latest version for Odroid N2.
  • Adjusted boot device priority to prioritize USB, NVME, and SCSI storage.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Updates ODroid N2 board configuration to u-boot v2026.01-rc2, adds btrfs support enablement, removes ext4 boot filesystem specification, limits MMC frequency to 24 MHz for stability, and reorders boot device targets to prioritize USB, NVME, and SCSI over MMC.

Changes

Cohort / File(s)	Change Summary
ODroid N2 Board Configuration config/boards/odroidn2.conf	Updated u-boot branch from v2022.10 to v2026.01-rc2 and matching patch directory; added btrfs extension support; removed ext4 boot filesystem specification.
ODroid N2 U-Boot Patches patch/u-boot/v2026.01/board_odroidn2/0001-mmc-meson_gx_mmc-limit-f_max-to-24-MHz.patch, patch/u-boot/v2026.01/board_odroidn2/meson64-boot-usb-nvme-scsi-first.patch	Added MMC frequency limiter (100 MHz → 24 MHz) for stability; reordered boot device targeting to prioritize USB/NVME/SCSI before MMC/PXE/DHCP.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• Review u-boot version bump coordination across configuration and patches to ensure consistency
• Verify MMC frequency limitation rationale and impact on device stability with referenced mailing-list constraints
• Confirm boot device reordering implications for existing deployment workflows and fallback behavior

Possibly related PRs

• uboot btrfs support #9010 — Adds uboot-btrfs extension implementation and enables it for multiple boards including the related Helios4 board
• orangepi5pro: Update U-Boot to v2025.07 for eMMC support #8417 — Updates board-specific u-boot version references (BOOTBRANCH/BOOTPATCHDIR) to newer releases across other boards
• odroidhc4: u-boot: bump to v2025.10; enable BTRFS support #8880 — Performs equivalent u-boot version bump and btrfs enablement changes for the ODroid HC4 board

Suggested labels

Framework

Suggested reviewers

• igorpecovnik
• NicoD-SBC
• SuperKali
• Tonymac32

Poem

🐰 A rabbit hops through configs new,
u-boot bumps to '26, it's true!
Boot dance changes—USB leads the way,
While 24 MHz keeps drives at bay.
Btrfs blooms in ODroid's heart today! 🌿

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'enable uboot btrfs for N2' directly reflects the main change: adding the uboot-btrfs extension to the ODROID-N2 board configuration.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Jira integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between ae82ca9 and f3b1e18.

📒 Files selected for processing (3)

• config/boards/odroidn2.conf (1 hunks)
• patch/u-boot/v2026.01/board_odroidn2/0001-mmc-meson_gx_mmc-limit-f_max-to-24-MHz.patch (1 hunks)
• patch/u-boot/v2026.01/board_odroidn2/meson64-boot-usb-nvme-scsi-first.patch (1 hunks)

🧰 Additional context used

🧠 Learnings (17)

📓 Common learnings

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: amazingfate
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:222-230
Timestamp: 2025-09-14T06:32:29.806Z
Learning: In the Armbian build system, the write_uboot_platform() function implementations follow different patterns across Rockchip family files. The newer standard (used in rockchip64_common.inc and rk3506) includes 'status=none' parameter in dd commands, while older implementations (rk3288, rk322x) use an older pattern without this parameter. The rk3506 implementation correctly follows the current Rockchip family standard.

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.

📚 Learning: 2025-09-18T03:36:17.862Z

Learnt from: EvilOlaf
Repo: armbian/build PR: 8537
File: config/boards/qcom-robotics-rb5.conf:1-1
Timestamp: 2025-09-18T03:36:17.862Z
Learning: In Armbian board configuration files (regardless of file extension), the standard pattern is to have only one line as a comment describing the board hardware specifications. This single-line description typically includes the SoC model, core count, RAM options, and key features like connectivity options, storage interfaces, and special features. The file extensions indicate board support status: .conf (standard support), .csc (community supported), .eos (end of support), .tvb (tvbox), .wip (work in progress).

Applied to files:

• config/boards/odroidn2.conf

📚 Learning: 2025-11-02T20:49:56.719Z

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.

Applied to files:

• config/boards/odroidn2.conf

📚 Learning: 2025-10-14T05:08:11.785Z

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.

Applied to files:

• config/boards/odroidn2.conf

📚 Learning: 2025-07-23T07:30:52.265Z

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.

Applied to files:

• config/boards/odroidn2.conf
• patch/u-boot/v2026.01/board_odroidn2/meson64-boot-usb-nvme-scsi-first.patch

📚 Learning: 2025-03-31T22:20:48.475Z

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.

Applied to files:

• config/boards/odroidn2.conf
• patch/u-boot/v2026.01/board_odroidn2/0001-mmc-meson_gx_mmc-limit-f_max-to-24-MHz.patch
• patch/u-boot/v2026.01/board_odroidn2/meson64-boot-usb-nvme-scsi-first.patch

📚 Learning: 2025-09-14T06:32:29.806Z

Learnt from: amazingfate
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:222-230
Timestamp: 2025-09-14T06:32:29.806Z
Learning: In the Armbian build system, the write_uboot_platform() function implementations follow different patterns across Rockchip family files. The newer standard (used in rockchip64_common.inc and rk3506) includes 'status=none' parameter in dd commands, while older implementations (rk3288, rk322x) use an older pattern without this parameter. The rk3506 implementation correctly follows the current Rockchip family standard.

Applied to files:

• config/boards/odroidn2.conf
• patch/u-boot/v2026.01/board_odroidn2/meson64-boot-usb-nvme-scsi-first.patch

📚 Learning: 2025-03-31T22:20:41.849Z

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.

Applied to files:

• config/boards/odroidn2.conf
• patch/u-boot/v2026.01/board_odroidn2/0001-mmc-meson_gx_mmc-limit-f_max-to-24-MHz.patch
• patch/u-boot/v2026.01/board_odroidn2/meson64-boot-usb-nvme-scsi-first.patch

📚 Learning: 2025-07-25T03:51:50.830Z

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.

Applied to files:

• config/boards/odroidn2.conf

📚 Learning: 2025-09-18T03:36:17.862Z

Learnt from: EvilOlaf
Repo: armbian/build PR: 8537
File: config/boards/qcom-robotics-rb5.conf:1-1
Timestamp: 2025-09-18T03:36:17.862Z
Learning: In Armbian board configuration files, .wip and .conf extensions require BOARD_MAINTAINER to be present and contain at least one maintainer. If no maintainer is present, the board support rules state it does not qualify for standard support and must be moved to community support (.csc extension). This is documented at https://docs.armbian.com/User-Guide_Board-Support-Rules/

Applied to files:

• config/boards/odroidn2.conf

📚 Learning: 2025-07-17T04:12:33.125Z

Learnt from: pyavitz
Repo: armbian/build PR: 8388
File: config/boards/kickpik2b.conf:1-14
Timestamp: 2025-07-17T04:12:33.125Z
Learning: In the Armbian build system, board configuration files (*.conf) follow a project standard of not including shebang lines, even though they contain bash code and are sourced by the build system. This is an established Armbian convention that individual contributors are expected to follow, and changes to this standard would require broader project maintainer approval.

Applied to files:

• config/boards/odroidn2.conf

📚 Learning: 2025-11-13T14:50:44.662Z

Learnt from: tabrisnet
Repo: armbian/build PR: 8925
File: lib/functions/host/docker.sh:141-141
Timestamp: 2025-11-13T14:50:44.662Z
Learning: In the Armbian build system, certain boards have U-Boot that doesn't build correctly on ubuntu:noble but works on ubuntu:jammy. For these boards, DOCKER_ARMBIAN_BASE_IMAGE can be set to "ubuntu:jammy" via an extension file loaded before docker_cli_prepare() runs, allowing legacy toolchains to work while the community works on proper fixes with limited resources.

Applied to files:

• config/boards/odroidn2.conf

📚 Learning: 2025-08-02T05:46:10.664Z

Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-08-02T05:46:10.664Z
Learning: In the Armbian build system, the modern recommended approach for kernel configuration is to use the kernel-config command via "./compile.sh BOARD=boardname BRANCH=branchname kernel-config" instead of the deprecated KERNEL_CONFIGURE=yes flag. This provides a two-step workflow: configure using menuconfig, then build, with better transparency and control over configuration changes.

Applied to files:

• config/boards/odroidn2.conf

📚 Learning: 2025-06-04T23:45:38.860Z

Learnt from: djurny
Repo: armbian/build PR: 8272
File: config/bootscripts/boot-mvebu.cmd:182-186
Timestamp: 2025-06-04T23:45:38.860Z
Learning: In config/bootscripts/boot-mvebu.cmd, the `fdtfile` variable is mandatory for booting and is pre-set by U-Boot, but can be overridden via armbianEnv.txt. If `fdtfile` is empty, the subsequent device tree file search logic will eventually fail and trigger the critical error "Cannot find DT!" with proper error handling.

Applied to files:

• config/boards/odroidn2.conf

📚 Learning: 2025-09-12T19:28:38.491Z

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.

Applied to files:

• config/boards/odroidn2.conf

📚 Learning: 2025-10-26T10:41:35.118Z

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.

Applied to files:

• config/boards/odroidn2.conf

📚 Learning: 2025-11-20T18:20:11.985Z

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.

Applied to files:

• patch/u-boot/v2026.01/board_odroidn2/0001-mmc-meson_gx_mmc-limit-f_max-to-24-MHz.patch
• patch/u-boot/v2026.01/board_odroidn2/meson64-boot-usb-nvme-scsi-first.patch

🔇 Additional comments (3)

patch/u-boot/v2026.01/board_odroidn2/0001-mmc-meson_gx_mmc-limit-f_max-to-24-MHz.patch (1)

24-37: MMC f_max reduction to 24 MHz is consistent and self‑contained

Limiting cfg->f_max to 24000000 with the added rationale comment is coherent with the existing f_min calculation and provides a clear, board-specific stability workaround while keeping the patch minimal, which aligns well with the existing U‑Boot patching style.

config/boards/odroidn2.conf (1)

13-18: Btrfs extension enablement and U‑Boot version bump look consistent

Enabling uboot-btrfs here and pairing BOOTBRANCH_BOARD="tag:v2026.01-rc2" with BOOTPATCHDIR="v2026.01" matches the usual Armbian pattern for board-specific U‑Boot branches and patch dirs and integrates cleanly with the existing config.

Please confirm you’ve done at least one full build and boot test (including eMMC + btrfs root) with this new U‑Boot/tag + patch set combination on N2/N2+ to validate there are no regressions. Based on learnings, BOOTBRANCH_BOARD/BOOTPATCHDIR are the right knobs here.

patch/u-boot/v2026.01/board_odroidn2/meson64-boot-usb-nvme-scsi-first.patch (1)

16-25: Boot target reordering is minimal and correct

Moving BOOT_TARGET_MMC(func) after the USB/NVME/SCSI targets cleanly implements the intended boot priority change without altering any other logic or macros, keeping the patch very small and easy to carry across U‑Boot versions.

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[leggewie]

d5bceb9 says it should be possible to do enable this for the rock-5b
626cd5b cm3588-nas
d9a0bb9 khadas-vim3l
431a598 nanopi-r6c
171f69f odroidhc4
de1f49f odroidm1s
61edafa nanopct6
1d8b386 odroidm1
3b90c35 armsom-forge1

There are

• patch/u-boot/v2025.10/board_rk3318-box/rk3318-box-add-defconfig.patch
• patch/u-boot/v2025.01/board_rk3318-box/rk3318-box-add-defconfig.patch
• patch/u-boot/u-boot-meson-s4t7/Update-kvim4_defconfig.patch b/patch/u-boot/u-boot-meson-s4t7/Update-kvim4_defconfig.patch
• patch/u-boot/v2024.10/board_gateway-gz80x/001-Add-board-Amper-Gateway-AM-GZ80x.patch

It probably makes sense to find out since what version u-boot has the CONFIG_CMD_BTRFS switch. The the extension can be augmented to test for whether or not the currently compiled version is more recent and simply do no thing on earlier u-boot versions.

I am OK to merge this PR now and deal with all the above boards and the changes to the extension in a separate PR so as not to delay @iav work on the N2 any further.

[iav]

Good

[github-actions]

✅ This PR has been reviewed and approved — all set for merge!