Skip to content

u-boot: v2026.04 (final) fixes and bumps for some boards#9654

Open
rpardini wants to merge 7 commits intoarmbian:mainfrom
rpardini:pr/u-boot-v202604-final-fixes-and-bumps-for-some-boards
Open

u-boot: v2026.04 (final) fixes and bumps for some boards#9654
rpardini wants to merge 7 commits intoarmbian:mainfrom
rpardini:pr/u-boot-v202604-final-fixes-and-bumps-for-some-boards

Conversation

@rpardini
Copy link
Copy Markdown
Member

@rpardini rpardini commented Apr 11, 2026

u-boot: v2026.04 (final) fixes and bumps for some boards

  • 🌳 mekotronics-r58x-pro: u-boot: bump to 2026.04-rc5 & add LWIP
  • 🌱 odroidn2: u-boot: bump to v2026.04 (final)
    • remove left-behind 22.10 patch from previous bump
  • 🍀 mekotronics-r58x-pro: u-boot: bump to 2026.04 (final)
  • 🐸 mekotronics-r58x-4g: u-boot: bump to 2026.04 (final)
  • 🌴 mixtile-blade3: u-boot: bump to v2026.04 (final)
    • just move defconfig/dt/dt_uboot around
  • 🍃 radxa-rock-4d: u-boot: move board-specific patches to board_ folder
    • no changes intended, but keep other board's u-boot sources clean
    • Fixes: 77f919f
  • 🌵 u-boot: 2026.04: drop #warnings in fdt_fixup_ethernet logging patch
    • those were added to ensure that code was actually being compiled
    • we're pretty sure now, so avoid spurious warnings during compilation

Summary by CodeRabbit

Release Notes

  • Chores

    • Updated U-Boot to v2026.04 official release across multiple boards (from release candidate versions)
    • Updated U-Boot version to v2026.04 for Mixtile Blade3 (from v2026.01)
  • Bug Fixes

    • Removed MMC clock limiting patch for ODROID N2
    • Enhanced diagnostic logging for ethernet configuration and device tree fixes
    • Enabled LWIP networking support for Mekotronics R58X Pro

- remove left-behind 22.10 patch from previous bump
- just move defconfig/dt/dt_uboot around
- no changes intended, but keep other board's u-boot sources clean
- Fixes: 77f919f
- 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>
@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai bot commented Apr 11, 2026

📝 Walkthrough

Walkthrough

This PR updates U-Boot configurations across multiple board configurations to use finalized v2026.04 releases instead of release candidates, removes an outdated MMC frequency patch for ODROID N2, enhances logging instrumentation in device tree fixup functions, and adjusts USB/networking configurations for specific boards.

Changes

Cohort / File(s) Summary
Board U-Boot Version Updates
config/boards/mekotronics-r58x-4g.csc, config/boards/mekotronics-r58x-pro.csc, config/boards/mixtile-blade3.csc, config/boards/odroidn2.conf
Updated BOOTBRANCH from release candidates (rc2/rc3) to final v2026.04; mekotronics-r58x-pro adds LWIP networking configs (CONFIG_CMD_MII, CONFIG_NET_LWIP) and removes CONFIG_CMD_USB_MASS_STORAGE duplication; mixtile-blade3 also updates BOOTPATCHDIR version.
Deleted MMC Frequency Patch
patch/u-boot/v2022.10/board_odroidn2/0001-mmc-meson_gx_mmc-limit-f_max-to-24-MHz.patch
Removed patch that constrained ODROID N2 MMC maximum frequency to 24 MHz.
Enhanced Logging Instrumentation
patch/u-boot/v2026.04/1001-fdt_fixup_ethernet-add-logs.patch
Replaced compile-time #warning directives with runtime log_info() calls in fdt_fixup_ethernet and image-fdt.c, adding counters for aliases, fixup attempts, skipped cases, and successful patches.
Patch Metadata Update
patch/u-boot/v2026.04/board_radxa-rock-4d/v5-1-4-spl-Make-UFS-available-for-SPL-builds.patch
Adjusted MAINTAINERS diff hunk line number context reference.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Poem

🐰 From rc branches we hop to stable v2026.04,
With boards all dressed up in their finest config,
Logging now chirps at runtime instead of compile-time,
MMC limits fade as we optimize in real time! ✨

🚥 Pre-merge checks | ✅ 3
✅ 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 accurately describes the main change: bumping u-boot to v2026.04 (final) for multiple boards with related fixes, which matches the changeset content.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

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

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

@github-actions github-actions bot added 05 Milestone: Second quarter release size/medium PR with more then 50 and less then 250 lines labels Apr 11, 2026
@rpardini rpardini marked this pull request as ready for review April 11, 2026 09:45
@github-actions github-actions bot added the Needs review Seeking for review label Apr 11, 2026
@rpardini rpardini requested a review from efectn as a code owner April 11, 2026 09:45
@github-actions github-actions bot added Hardware Hardware related like kernel, U-Boot, ... Patches Patches related to kernel, U-Boot, ... labels Apr 11, 2026
@HeyMeco
Copy link
Copy Markdown
Collaborator

HeyMeco commented Apr 11, 2026

Will check with Rock-4D and Mekotronics R58S2 and report back

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (2)
patch/u-boot/v2026.04/1001-fdt_fixup_ethernet-add-logs.patch (2)

131-131: ⚠️ Potential issue | 🟡 Minor

Remove compile-time #warning directive from image-fdt.c instrumentation.

The patch adds a build warning at line 131 that should be removed before merging:

-#warning "Building image-fdt.c: fdt fixup call chain instrumented for MAC debugging."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@patch/u-boot/v2026.04/1001-fdt_fixup_ethernet-add-logs.patch` at line 131,
Remove the temporary compile-time warning added to instrument the fdt fixup
chain by deleting the preprocessor directive `#warning` "Building image-fdt.c: fdt
fixup call chain instrumented for MAC debugging." from image-fdt.c; ensure no
other instrumentation-only diagnostics remain and run a build to confirm no
stray `#warning` directives are present (target symbol: the `#warning` directive in
image-fdt.c).

28-29: ⚠️ Potential issue | 🔴 Critical

Fix nodeoff redeclaration in fdt_fixup_ethernet.

Line 28 declares int nodeoff under #ifdef FDT_SEQ_MACADDR_FROM_ENV (ending at line 81), and line 92 redeclares int nodeoff unconditionally in the same function scope. This causes a compile error when FDT_SEQ_MACADDR_FROM_ENV is enabled.

🔧 Minimal fix
-			int nodeoff = fdt_path_offset(fdt, path);
-			if (nodeoff < 0) {
+			int nodeoff_path = fdt_path_offset(fdt, path);
+			if (nodeoff_path < 0) {
 				log_info("[fdt_fixup_ethernet] Node path '%s' not found, skipping\n", path);
 				total_skipped++;
 				continue;
 			}
-			const struct fdt_property *status_prop = fdt_get_property(fdt, nodeoff, "status", NULL);
+			const struct fdt_property *status_prop = fdt_get_property(fdt, nodeoff_path, "status", NULL);
 			if (status_prop && strcmp((const char *)status_prop->data, "okay")) {
 				log_info("[fdt_fixup_ethernet] Node '%s' status is '%s', skipping\n", path, (const char *)status_prop->data);
 				total_skipped++;
 				continue;
 			}
-			log_info("[fdt_fixup_ethernet] Patching node '%s' (offset %d) with MAC %02x:%02x:%02x:%02x:%02x:%02x\n", path, nodeoff, mac_addr[0], mac_addr[1], mac_addr[2], mac_addr[3], mac_addr[4], mac_addr[5]);
+			log_info("[fdt_fixup_ethernet] Patching node '%s' (offset %d) with MAC %02x:%02x:%02x:%02x:%02x:%02x\n", path, nodeoff_path, mac_addr[0], mac_addr[1], mac_addr[2], mac_addr[3], mac_addr[4], mac_addr[5]);
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@patch/u-boot/v2026.04/1001-fdt_fixup_ethernet-add-logs.patch` around lines 28
- 29, The function fdt_fixup_ethernet currently declares int nodeoff twice (once
under `#ifdef` FDT_SEQ_MACADDR_FROM_ENV and again unconditionally), causing a
redeclaration compile error; fix it by removing the second/duplicate declaration
and reuse the existing nodeoff variable (or move a single declaration to
function scope before the `#ifdef`) so only one int nodeoff exists in
fdt_fixup_ethernet; update any references to nodeoff accordingly and ensure the
surrounding logic that uses nodeoff and fdt_prop remains unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Outside diff comments:
In `@patch/u-boot/v2026.04/1001-fdt_fixup_ethernet-add-logs.patch`:
- Line 131: Remove the temporary compile-time warning added to instrument the
fdt fixup chain by deleting the preprocessor directive `#warning` "Building
image-fdt.c: fdt fixup call chain instrumented for MAC debugging." from
image-fdt.c; ensure no other instrumentation-only diagnostics remain and run a
build to confirm no stray `#warning` directives are present (target symbol: the
`#warning` directive in image-fdt.c).
- Around line 28-29: The function fdt_fixup_ethernet currently declares int
nodeoff twice (once under `#ifdef` FDT_SEQ_MACADDR_FROM_ENV and again
unconditionally), causing a redeclaration compile error; fix it by removing the
second/duplicate declaration and reuse the existing nodeoff variable (or move a
single declaration to function scope before the `#ifdef`) so only one int nodeoff
exists in fdt_fixup_ethernet; update any references to nodeoff accordingly and
ensure the surrounding logic that uses nodeoff and fdt_prop remains unchanged.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: e8a4d3d5-c1c6-469e-ab66-7ac13893d326

📥 Commits

Reviewing files that changed from the base of the PR and between fdef407 and de27473.

📒 Files selected for processing (13)
  • config/boards/mekotronics-r58x-4g.csc
  • config/boards/mekotronics-r58x-pro.csc
  • config/boards/mixtile-blade3.csc
  • config/boards/odroidn2.conf
  • patch/u-boot/v2022.10/board_odroidn2/0001-mmc-meson_gx_mmc-limit-f_max-to-24-MHz.patch
  • patch/u-boot/v2026.04/1001-fdt_fixup_ethernet-add-logs.patch
  • patch/u-boot/v2026.04/board_radxa-rock-4d/v5-1-4-spl-Make-UFS-available-for-SPL-builds.patch
  • patch/u-boot/v2026.04/board_radxa-rock-4d/v5-2-4-reset-rockchip-make-device-resets-available-in-SPL.patch
  • patch/u-boot/v2026.04/board_radxa-rock-4d/v5-3-4-ufs-rockchip-Add-device-reset-support.patch
  • patch/u-boot/v2026.04/board_radxa-rock-4d/v5-4-4-rockchip-spl-Add-support-for-booting-from-UFS.patch
  • patch/u-boot/v2026.04/defconfig/mixtile-blade3-rk3588_defconfig
  • patch/u-boot/v2026.04/dt_uboot/rk3588-mixtile-blade3-u-boot.dtsi
  • patch/u-boot/v2026.04/dt_upstream_rockchip/rk3588-mixtile-blade3.dts
💤 Files with no reviewable changes (1)
  • patch/u-boot/v2022.10/board_odroidn2/0001-mmc-meson_gx_mmc-limit-f_max-to-24-MHz.patch

@HeyMeco
Copy link
Copy Markdown
Collaborator

HeyMeco commented Apr 11, 2026

@coderabbitai make suggestions for the board configs of Rock-4D and Mekotronics-R58S2 to switch from the rc to final 2026.04 tag

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai bot commented Apr 11, 2026

Tip

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

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Find Rock-4D and Mekotronics R58S2 board config files
fd -i 'rock-4d' config/boards/
fd -i 'r58s2' config/boards/
fd -i 'mekotronics' config/boards/

Length of output: 335


🏁 Script executed:

#!/bin/bash
cat config/boards/radxa-rock-4d.conf
echo "---"
cat config/boards/mekotronics-r58s2.conf

Length of output: 7706


@HeyMeco Both files currently use tag:v2026.04-rc2 and just need a one-liner bump to tag:v2026.04. BOOTPATCHDIR stays at v2026.04 in both cases — no other changes needed.


config/boards/radxa-rock-4d.conf — inside post_family_config__rock4d_use_mainline_uboot():

-	declare -g BOOTBRANCH="tag:v2026.04-rc2"
+	declare -g BOOTBRANCH="tag:v2026.04"

config/boards/mekotronics-r58s2.conf — inside post_family_config__meko_r58s2_use_mainline_uboot():

-	declare -g BOOTBRANCH="tag:v2026.04-rc2"
+	declare -g BOOTBRANCH="tag:v2026.04"

🧠 Learnings used
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: 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: EvilOlaf
Repo: armbian/build PR: 9423
File: config/boards/dg-svr-865-tiny.conf:1-1
Timestamp: 2026-02-21T06:27:22.084Z
Learning: In Armbian board configuration files (config/boards/*.conf, *.csc, *.wip, etc.), always verify that the first line comment contains a proper hardware feature description rather than a description of what the file generates. The comment should include SoC model, core count, RAM options, and key features like connectivity options, storage interfaces, and special features. This is functionally important because the text is used during interactive compilation, not just for documentation. Flag any new board config files that have improper first-line comments (e.g., "# Generate kernel and rootfs image..." instead of "# Qualcomm QCS8250 octa core 4GB-16GB eMMC GBE USB3 WiFi BT").
<!-- </add_learning>

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: 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: 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: 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: 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: 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: 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: 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."

@HeyMeco
Copy link
Copy Markdown
Collaborator

HeyMeco commented Apr 11, 2026

My local builds for both were fine @rpardini you can bump those with this PR too

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

05 Milestone: Second quarter release Hardware Hardware related like kernel, U-Boot, ... Needs review Seeking for review Patches Patches related to kernel, U-Boot, ... size/medium PR with more then 50 and less then 250 lines

Development

Successfully merging this pull request may close these issues.

2 participants