rk3576: nanopi-r76s: add mainline u-boot and fix USB3.0 host

[SuperKali]

Description

Add mainline U-Boot support for NanoPi R76S (RK3576) and fix USB3.0 Type-A host port that was not working.

The USB fix includes:

• Correct regulator configuration (vcc5v0_usb_otg0) with GPIO power control
• USB DRD0 controller set to host mode instead of OTG

Jira reference number AR-2782

How Has This Been Tested?

• Board boots with mainline U-Boot v2026.01-rc2
• USB3.0 Type-A port detects and works with USB devices
• SD card and eMMC boot working

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• My changes generate no new warnings

[coderabbitai]

Walkthrough

Added NanoPi R76S support for Kernel Edge with mainline U-Boot integration. Changes include board configuration with kernel test target, dynamic U-Boot switching logic, boot target patching for RK3576, USB OTG mode adjustment in kernel device tree, and new U-Boot support files (device tree stub, defconfig, and full device tree source).

Changes

Cohort / File(s)	Summary
Board Configuration config/boards/nanopi-r76s.conf	Added KERNEL_TEST_TARGET="edge" for edge branch testing; introduced post_family_config__nanopi_r76s_use_mainline_uboot() to conditionally switch to mainline U-Boot with custom boot parameters (BOOTDELAY, BOOTSOURCE, BOOTBRANCH, BOOTPATCHDIR, UBOOT_TARGET_MAP); defined nested write_uboot_platform() shim for binman-based U-Boot workflow; added pre_config_uboot_target__nanopi_r76s_patch_rockchip_common_boot_order() to patch boot target ordering in RK3576 common config.
Kernel Device Tree patch/kernel/archive/rockchip64-6.18/dt/rk3576-nanopi-r76s.dts	Replaced USB Type-C power regulator with USB OTG0 host-mode power supply (vcc5v0_usb_otg0); changed OTG0 dr_mode from "otg" to "host" and removed extcon reference; updated PHY supply reference to new regulator node.
U-Boot Support patch/u-boot/v2026.01/add-nanopi-r76s-support.patch	Added three new files: arch/arm/dts/rk3576-nanopi-r76s-u-boot.dtsi (device tree stub with sys_led default-on), configs/nanopi-r76s-rk3576_defconfig (build configuration enabling RK3576, RTL8125, PMIC, boot features), and dts/upstream/src/arm64/rockchip/rk3576-nanopi-r76s.dts (comprehensive hardware definitions for network, storage, HDMI, LEDs, power regulators, I2C, PCIe, USB, and PMIC integration).

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• Board configuration functions mix conditional logic with multiple global variable assignments and file patching—verify vendor-branch guards and boot parameter correctness
• Device tree changes affect USB mode and power delivery; validate OTG0 mode switch and regulator node naming consistency across patches
• U-Boot defconfig and device tree files are comprehensive; scan for RK3576-specific quirks, PMIC rail definitions, and boot target alignment with board configuration

Possibly related PRs

• nanopi-m6: add support for mainline uboot #8793: Adds board-specific post_family_config__...use_mainline_uboot() hook to switch to mainline U-Boot with global boot variables and UBOOT_TARGET_MAP, same integration pattern.
• nanopi-m6: drop vendor uboot #8939: Modifies board config to switch away from vendor U-Boot and patches include/configs/rockchip-common.h for boot target ordering, matching the boot order patching workflow here.
• add NanoPi R76S support for edge kernel builds #8609: Enables "edge" kernel support for NanoPi R76S, directly aligned with the KERNEL_TEST_TARGET="edge" addition in this PR.

Suggested labels

BSP

Suggested reviewers

• igorpecovnik
• prahal
• rpardini
• paolosabatino
• krachlatte
• ginkage

Poem

🐰 A mainline U-Boot hop and skip,
Edge kernel runs on R76S tip,
USB modes dance from Type-C to host,
Device trees and configs—the rabbit does boast! ✨
Rockchip RK3576 now spins with cheer,
Board support blossoms this kernel year!

Pre-merge checks and finishing touches

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately captures the main changes: adding mainline U-Boot support and fixing USB3.0 host mode for NanoPi R76S, clearly summarizing the primary objectives.
Linked Issues check	✅ Passed	The PR successfully implements mainline U-Boot support for NanoPi R76S as required by AR-2782, with comprehensive U-Boot configuration, device-tree bindings, and boot order adjustments fully aligned with the linked objective.
Out of Scope Changes check	✅ Passed	All changes are directly scoped to NanoPi R76S mainline U-Boot support and USB3.0 host fixes; the USB Type-C to USB3.0 Type-A regulator change and boot order adjustments are necessary supporting modifications within the stated objectives.
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

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

• Provide your own instructions using the high_level_summary_instructions setting.
• Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
• Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
4. 📊 Contributor Summary — Include a Markdown table showing contributions:
   | Contributor | Lines Added | Lines Removed | Files Changed |
5. ✔️ Additional Notes — Add any extra reviewer context.
   Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.

---

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.}

[SuperKali]

Build Log: https://paste.armbian.de/ovuwufikox

[coderabbitai]

Actionable comments posted: 0

Caution

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

⚠️ Outside diff range comments (1)

config/boards/nanopi-r76s.conf (1)

15-15: Minor: Inconsistent function naming convention.

The existing function post_family_tweaks__nanopi-r76s_naming_audios uses a hyphen in the board name, while the new functions use underscores (nanopi_r76s). While both are valid Bash function names, consistent naming improves maintainability.

Consider renaming for consistency if the build system doesn't rely on the hyphenated form:

-function post_family_tweaks__nanopi-r76s_naming_audios() {
+function post_family_tweaks__nanopi_r76s_naming_audios() {

🧹 Nitpick comments (1)

patch/u-boot/v2026.01/add-nanopi-r76s-support.patch (1)

156-181: Consider adding pinctrl-names property to LED nodes.

The LED nodes have pinctrl-0 defined but lack the corresponding pinctrl-names = "default"; property. While the kernel typically defaults to "default" when there's a single pinctrl state, explicitly declaring it improves clarity and follows device tree conventions.

 		sys_led: led-0 {
 			color = <LED_COLOR_ID_RED>;
 			function = LED_FUNCTION_HEARTBEAT;
 			gpios = <&gpio2 RK_PB3 GPIO_ACTIVE_HIGH>;
 			linux,default-trigger = "heartbeat";
+			pinctrl-names = "default";
 			pinctrl-0 = <&sys_led_pin>;
 		};

 		lan_led: led-1 {
 			color = <LED_COLOR_ID_GREEN>;
 			function = LED_FUNCTION_STATUS;
 			gpios = <&gpio2 RK_PB0 GPIO_ACTIVE_HIGH>;
+			pinctrl-names = "default";
 			pinctrl-0 = <&lan_led_pin>;
 		};

 		wan_led: led-2 {
 			color = <LED_COLOR_ID_GREEN>;
 			function = LED_FUNCTION_STATUS;
 			gpios = <&gpio4 RK_PC5 GPIO_ACTIVE_HIGH>;
+			pinctrl-names = "default";
 			pinctrl-0 = <&wan_led_pin>;
 		};

📜 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 e4db83a and d40335a.

📒 Files selected for processing (3)

• config/boards/nanopi-r76s.conf (2 hunks)
• patch/kernel/archive/rockchip64-6.18/dt/rk3576-nanopi-r76s.dts (3 hunks)
• patch/u-boot/v2026.01/add-nanopi-r76s-support.patch (1 hunks)

🧰 Additional context used

🧠 Learnings (22)

📓 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: 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: 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: 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: 8619
File: config/sources/families/rockchip.conf:64-70
Timestamp: 2025-09-14T06:10:25.610Z
Learning: In the Armbian build system, rk32xx and rk33xx Rockchip SoCs no longer have BSP-based (vendor) kernel branches. The rk3506 is the first 32-bit Rockchip SoC to use the vendor branch in the current codebase.

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: 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: SuperKali
Repo: armbian/build PR: 8936
File: patch/kernel/archive/rockchip64-6.18/dt/rk3576-nanopi-r76s.dts:800-802
Timestamp: 2025-11-15T14:33:30.654Z
Learning: In RK3576 device tree files (like rk3576-nanopi-r76s.dts), the serial0 alias is already defined in the upstream kernel's rk3576.dtsi base file, so board-specific DTS files do not need to redeclare it when enabling &uart0 for serial console.

Learnt from: tabrisnet
Repo: armbian/build PR: 8746
File: config/kernel/linux-filogic-edge.config:344-470
Timestamp: 2025-10-11T19:52:54.648Z
Learning: The chainsx/linux-filogic kernel (legacy branch) for BPI-R4 uses out-of-tree proprietary drivers (CONFIG_NET_DSA_AN8855, CONFIG_AIROHA_EN8801SC_PHY, CONFIG_AIR_AN8855_PHY, CONFIG_MDIO_AN8855, CONFIG_MFD_AIROHA_AN8855). The frank-w/BPI-Router-Linux kernel (current and edge branches) uses mainline kernel drivers instead: CONFIG_NET_DSA_MT7530 for the DSA switch and CONFIG_MEDIATEK_2P5GE_PHY for PHY support. These provide equivalent functionality for BPI-R4 networking.

Learnt from: EvilOlaf
Repo: armbian/build PR: 8886
File: patch/kernel/rk35xx-vendor-6.1/dt/rk3528-nanopi-rev01.dts:9-9
Timestamp: 2025-11-08T06:39:24.527Z
Learning: In Armbian's Rockchip vendor kernel branches (rk35xx-vendor), device tree files may not require the same headers as mainline Linux. For example, input key definitions like KEY_BACK and KEY_VOLUMEUP may be handled differently in BSP kernels and don't necessarily need explicit includes like <dt-bindings/input/input.h> that would be required in mainline kernel device trees.

Learnt from: igorpecovnik
Repo: armbian/build PR: 8789
File: config/kernel/linux-sunxi64-edge.config:839-839
Timestamp: 2025-10-22T07:51:53.015Z
Learning: In Armbian's wireless driver configuration, CONFIG_RK_WIFI_DEVICE_* options are Rockchip-specific device registration settings, while CONFIG_WLAN_UWE* are the actual cross-platform driver modules for UWE5622 wireless chips. The UWE5622 chip (manufactured by Unisoc/Spreadtrum) is used on multiple Allwinner boards including Orange Pi Zero 2/2W/3 and Orange Pi 3 LTS, so CONFIG_WLAN_UWE5621/5622 along with Unisoc infrastructure options (CONFIG_SPARD_WLAN_SUPPORT, CONFIG_SC23XX, CONFIG_UNISOC_WIFI_PS, CONFIG_WCN_BSP_DRIVER_BUILDIN) are correct in sunxi64 kernel configs.

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

📚 Learning: 2025-11-15T14:33:30.654Z

Learnt from: SuperKali
Repo: armbian/build PR: 8936
File: patch/kernel/archive/rockchip64-6.18/dt/rk3576-nanopi-r76s.dts:800-802
Timestamp: 2025-11-15T14:33:30.654Z
Learning: In RK3576 device tree files (like rk3576-nanopi-r76s.dts), the serial0 alias is already defined in the upstream kernel's rk3576.dtsi base file, so board-specific DTS files do not need to redeclare it when enabling &uart0 for serial console.

Applied to files:

• patch/kernel/archive/rockchip64-6.18/dt/rk3576-nanopi-r76s.dts
• patch/u-boot/v2026.01/add-nanopi-r76s-support.patch

📚 Learning: 2025-11-08T06:39:24.527Z

Learnt from: EvilOlaf
Repo: armbian/build PR: 8886
File: patch/kernel/rk35xx-vendor-6.1/dt/rk3528-nanopi-rev01.dts:9-9
Timestamp: 2025-11-08T06:39:24.527Z
Learning: In Armbian's Rockchip vendor kernel branches (rk35xx-vendor), device tree files may not require the same headers as mainline Linux. For example, input key definitions like KEY_BACK and KEY_VOLUMEUP may be handled differently in BSP kernels and don't necessarily need explicit includes like <dt-bindings/input/input.h> that would be required in mainline kernel device trees.

Applied to files:

• patch/kernel/archive/rockchip64-6.18/dt/rk3576-nanopi-r76s.dts

📚 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:

• patch/u-boot/v2026.01/add-nanopi-r76s-support.patch
• config/boards/nanopi-r76s.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/add-nanopi-r76s-support.patch
• config/boards/nanopi-r76s.conf

📚 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:

• patch/u-boot/v2026.01/add-nanopi-r76s-support.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:

• patch/u-boot/v2026.01/add-nanopi-r76s-support.patch
• config/boards/nanopi-r76s.conf

📚 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:

• patch/u-boot/v2026.01/add-nanopi-r76s-support.patch
• config/boards/nanopi-r76s.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:

• patch/u-boot/v2026.01/add-nanopi-r76s-support.patch
• config/boards/nanopi-r76s.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/nanopi-r76s.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/nanopi-r76s.conf

📚 Learning: 2025-11-10T22:05:40.490Z

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.

Applied to files:

• config/boards/nanopi-r76s.conf

📚 Learning: 2025-09-14T06:29:18.958Z

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.

Applied to files:

• config/boards/nanopi-r76s.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/nanopi-r76s.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/nanopi-r76s.conf

📚 Learning: 2025-08-21T08:10:59.502Z

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

Applied to files:

• config/boards/nanopi-r76s.conf

📚 Learning: 2025-08-21T08:10:25.459Z

Learnt from: leggewie
Repo: armbian/build PR: 8524
File: config/boards/nanopiduo2.csc:12-12
Timestamp: 2025-08-21T08:10:25.459Z
Learning: KERNEL_TARGET and KERNEL_TEST_TARGET in Armbian build system do not have enforced validation relationships. KERNEL_TARGET is used for interactive menu ordering and branch validation, while KERNEL_TEST_TARGET is used for build list generation and recorded in /etc/armbian-release. No existing codebase validation enforces that KERNEL_TEST_TARGET values must be present in KERNEL_TARGET.

Applied to files:

• config/boards/nanopi-r76s.conf

📚 Learning: 2025-10-13T02:26:18.249Z

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.

Applied to files:

• config/boards/nanopi-r76s.conf

📚 Learning: 2025-06-25T03:42:09.086Z

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.

Applied to files:

• config/boards/nanopi-r76s.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/nanopi-r76s.conf

📚 Learning: 2025-11-10T23:44:53.363Z

Learnt from: tabrisnet
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-11-10T23:44:53.363Z
Learning: For the RV1106 family in Armbian (config/sources/families/rockchip-rv1106.conf), udev.children-max=1 is set in the kernel boot parameters to prevent early-boot OOM errors. The RV1106 has a single-core CPU, so parallelism in udev child processes provides no practical benefit. Testing higher values is impractical due to the difficulty of monitoring at this early boot stage.

Applied to files:

• config/boards/nanopi-r76s.conf

📚 Learning: 2025-09-07T17:39:32.272Z

Learnt from: EvilOlaf
Repo: armbian/build PR: 8586
File: config/boards/nanopi-r76s.conf:15-21
Timestamp: 2025-09-07T17:39:32.272Z
Learning: In the Armbian build system, the variables $BOARD and $SDCARD are always set by the build framework, so guard checks for these variables are unnecessary in board configuration files and hook functions.

Applied to files:

• config/boards/nanopi-r76s.conf

🔇 Additional comments (10)

patch/u-boot/v2026.01/add-nanopi-r76s-support.patch (5)

31-37: LGTM! U-Boot DTSI properly extends base and configures LED state.

The inclusion of rk3576-u-boot.dtsi and setting sys_led default-state to "on" for boot indication is appropriate.

---

44-104: LGTM! Defconfig properly enables required features for NanoPi R76S.

The configuration correctly enables:

• RK3576-specific options
• PCIe for RTL8125 2.5GbE NICs
• USB3 with DWC3 and associated PHYs
• RK806 PMIC support
• GPIO LEDs

The 1500000 baud rate matches the DTS stdout-path.

---

934-951: LGTM! USB3.0 Type-A host port configuration correctly implemented.

The configuration properly addresses the USB3.0 fix mentioned in the PR:

• dr_mode = "host" correctly sets the DRD controller to host-only mode
• phy-supply = <&vcc5v0_usb_otg0> references the GPIO-controlled regulator (lines 268-279)

This aligns with the PR objective of fixing the USB3.0 Type-A host port.

---

765-802: LGTM! PCIe configuration for dual RTL8125 2.5GbE NICs.

The configuration correctly sets up both PCIe controllers with proper reset GPIOs and PHY references. The placeholder MAC addresses (00 00 00 00 00 00) are standard and will be overwritten at runtime from U-Boot or EEPROM.

---

374-730: LGTM! RK806 PMIC configuration with comprehensive regulator definitions.

The PMIC setup is thorough with:

• Proper power supply chains from vcc_5v0_sys
• Complete regulator definitions for all power domains (CPU, GPU, DDR, logic, I/O)
• Correct suspend state configurations
• DVS pin function definitions for power management

config/boards/nanopi-r76s.conf (3)

6-6: LGTM! KERNEL_TEST_TARGET appropriately set for edge branch testing.

This enables CI testing for the edge kernel branch which is the target for mainline U-Boot support.

---

47-58: LGTM! Boot order patching prioritizes SD card for development/recovery.

The SD-first boot order (mmc0 mmc1 nvme...) is appropriate for the NanoPi R76S where mmc0 is the SD card slot. This enables easier development and recovery workflows.

The use of regular_git diff with || true ensures the build doesn't fail if there are no changes to display.

---

23-45: LGTM! Verification confirms proper blob variable configuration.

The verification shows that BL31_BLOB and DDR_BLOB are correctly defined for RK3576 at lines 148-149 in config/sources/families/include/rockchip64_common.inc:

• DDR_BLOB="rk35/rk3576_ddr_lp4_2112MHz_lp5_2736MHz_v1.08.bin" (pinned to v1.08)
• BL31_BLOB="rk35/rk3576_bl31_v1.20.elf"

The nanopi-r76s board correctly inherits these definitions through the rk35xx family configuration.

patch/kernel/archive/rockchip64-6.18/dt/rk3576-nanopi-r76s.dts (2)

156-167: USB OTG0 VBUS regulator wiring matches RK3576 patterns

vcc5v0_usb_otg0 is hooked up as expected for an OTG0 Type‑A VBUS switch: 5 V fixed regulator, GPIO0_PD1 drive via usb_otg0_pwren pinctrl, and vin-supply from the main 5 V rail. This aligns with how upstream RK3576 boards model OTG0/Type‑C VBUS regulators and should work fine for a GPIO‑controlled host port. (lists.infradead.org)

---

821-838: DRD0 forced host mode plus PHY VBUS supply is appropriate for Type‑A host

Switching &usb_drd0_dwc3 to dr_mode = "host" (and dropping extcon) matches a dedicated USB3.0 Type‑A host port, and tying &u2phy0_otg’s phy-supply to vcc5v0_usb_otg0 follows Rockchip’s recommended pattern for GPIO‑controlled VBUS on RK3576. This will intentionally disable OTG/device use on this port, which is fine if the hardware is host‑only as described. (lists.infradead.org)

[github-actions]

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