Ian Goodacre Posted March 4 Posted March 4 (edited) I am adding support for a new board: NanoPi R2S Plus. I have added it to the kernel and it works in testing so far. Now I am attempting to add the new board to u-boot. The u-boot configuration for NanoPi R2S does not enable the eMMC and I want to install to boot from eMMC. Using my modified kernel and u-boot for NanoPi R2S I am able to run armbian-install because in the system booted from SD card the eMMC is enabled. But after installing to eMMC, shutting down and removing the SD card, boot fails because u-boot cannot access the eMMC. Looking at the device tree for NanoPi R2S in u-boot, not surprisingly, eMMC is not enabled: NanoPi R2S does not have eMMC memory. So, I am attempting to patch u-boot to add support for the NanoPi R2S Plus board, enabling eMMC and the WAN network adapter, as I did in the kernel. I am attempting to create a patch for u-boot using command: `./compile.sh nanopi-r2s-plus uboot-patch` After a bit I see: ``` [✨] Starting [ interactive patching process for u-boot ] [🌱] Creating commit to start from clean source [🌱] Patches will be created [ with the following maintainer information ] [🌱] MAINTAINER (Real name): [ John Doe ] [🌱] MAINTAINERMAIL (Email): [ john.doe@somewhere.on.planet ] [🌿] If those are not correct, set them in your environment, command line, or config file and restart the process [🚸] Make your changes in this directory: [ /home/ian/ig3/armbian-build/cache/sources/u-boot-worktree/u-boot/v2022.07 ] [🚸] Press <ENTER> after you are done [ editing files in /home/ian/ig3/armbian-build/cache/sources/u-boot-worktree/u-boot/v2022.07 ] Press ENTER to show a preview of your patch, or type 'stop' to stop patching... ``` In a separate window I went to the indicated directory and added two files: configs/nanopi-r2s-plus-rk3328_defconfig arch/arm/dts/rk3328-nanopi-r2s-plus.dts I didn't modify any of the existing files. I returned to the window running compile.sh and pressed the ENTER key and I saw: ``` [🌱] OK, here's how your diff looks like [ showing patch diff ] ───────┬──────────────────────────────────────────────────── │ File: /home/ian/ig3/armbian-build/output/patch/ │ u-boot-rockchip64-current.patch <EMPTY> ───────┴──────────────────────────────────────────────────── [🚸] Are you happy with this patch? [ Type 'yes' to accept, 'stop' to stop patching, or anything else to keep patching ] Are you happy with the diff above? Type 'y' or 'yes' to accept, 'stop' to stop patching, anything else to keep patching: n ``` I was expecting to see a patch that creates the two new files. I presume '<EMPTY>" indicates that no changes were detected. This is the first time I have tried using the uboot-patch command. I may be overlooking something very obvious. I have checked to ensure I created the files in the correct location: ``` ian@armbianbuild:~/ig3/armbian-build/cache/sources/u-boot-worktree/u-boot/v2022.07$ ls -l configs/nanopi-r2s-plus-rk3328_defconfig -rw-r--r-- 1 root root 2617 Mar 4 20:37 configs/nanopi-r2s-plus-rk3328_defconfig ian@armbianbuild:~/ig3/armbian-build/cache/sources/u-boot-worktree/u-boot/v2022.07$ ls -l arch/arm/dts/rk3328-nanopi-r2s-plus.dts -rw-r--r-- 1 root root 943 Mar 4 21:08 arch/arm/dts/rk3328-nanopi-r2s-plus.dts ``` All the existing files are owned by root, so I assume the permissions are OK. Should it handle the creation of new files in the u-boot tree? Or does it only handle changes to existing files? Any suggestions would be appreciated. Edited March 5 by Ian Goodacre 0 Quote
Werner Posted March 5 Posted March 5 Hm indeed there is something wrong. Tested something similar but the patch file was shown empty. Though this used to work in the past. I suggest to report this here https://github.com/armbian/build/issues since this is clearly an framework issue. Edit: Alright, there seems to be a cosmetic bug. New files aren't shown for whatever reason in the patchfile preview. However if you press y to finish up patching the patchfile in the output folder looks just fine. From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001 From: John Doe <john.doe@somewhere.on.planet> Date: Wed, 5 Mar 2025 05:41:52 +0100 Subject: Patching u-boot rk35xx files arch/arm/dts/rk3328-nanopi-r2s-plus.dts configs/nanopi-r2s-plus-rk3328_defconfig Signed-off-by: John Doe <john.doe@somewhere.on.planet> --- arch/arm/dts/rk3328-nanopi-r2s-plus.dts | 1 + configs/nanopi-r2s-plus-rk3328_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/arch/arm/dts/rk3328-nanopi-r2s-plus.dts b/arch/arm/dts/rk3328-nanopi-r2s-plus.dts new file mode 100644 index 00000000000..f33568d63c5 --- /dev/null +++ b/arch/arm/dts/rk3328-nanopi-r2s-plus.dts @@ -0,0 +1 @@ +gzuweggzuerguiwigwegi diff --git a/configs/nanopi-r2s-plus-rk3328_defconfig b/configs/nanopi-r2s-plus-rk3328_defconfig new file mode 100644 index 00000000000..9561b6e6ed7 --- /dev/null +++ b/configs/nanopi-r2s-plus-rk3328_defconfig @@ -0,0 +1 @@ +iuhgiuagiauhigahihgiawugiawugiwu -- Created with Armbian build tools https://github.com/armbian/build 0 Quote
Kwiboo Posted March 5 Posted March 5 Support for NanoPi R2S Plus was added in U-Boot v2025.01. Suggest you update U-Boot from v2022.07 to v2025.01. 0 Quote
Solution Ian Goodacre Posted March 5 Author Solution Posted March 5 Reported and updated: the indication of an 'empty' patch is false. Accept it and a non-empty patch file is produced. 0 Quote
Ian Goodacre Posted March 5 Author Posted March 5 @Kwiboo Thank you very much! I wasn't aware. I'll look into how to update u-boot for my build. There's always something new to learn... 0 Quote
Ian Goodacre Posted March 5 Author Posted March 5 (edited) So I tried adding "BOOTBRANCH='tag:v2025.01'" to my compile command and I can see that it gets u-boot with that tag but it then attempts to apply all the patches for the platform rockchip64 from patch dir u-boot-rockchip64 and fails because those patches are written against v2022.07 (I assume, because that's the version of u-boot that compile was using before I added BOOTBRANCH and those builds didn't fail). Is there a way I can use the newer version of u-boot for my build without fixing the patches for all the other rockchip64 boards? For a first attempt, I would like to use u-boot v2025.01 as-is, without patches, merely selecting its configuration for nanopi-r2s-plus. I don't want to change what happens for the other boards. My board is NanoPi R2S Plus and, as far as I know, Armbian build framework didn't have configuration specific for this board. I had been using the configuration for NanoPi R2S but now I would like to get the eMMC and WAN network adapter working. These don't work with the NanoPi R2S configuration because of hardware differences: NanoPi R2S doesn't have eMMC and the boards have different chip for the WAN network adapter. I have patched the kernel so both eMMC and WAN port work. Now I would like to enable boot from eMMC which requires changing the device tree in u-boot to enable the eMMC and, while I am at it, I might as well change it to enable the WAN port too. Now that I have a workaround for the uboot-patch problem I could continue developing a patch for u-boot v2022.07 and worry about later versions later but using a more recent u-boot version where it 'just works' seems appealing. But I am not familiar with the Armbian build framework so don't immediately know how to proceed, other than to keep learning how the build framework works. Edit: I just found config/boards/README.md - a wealth of information, and also BOOTPATCHDIR in many board configurations, which I expect will allow me to resolve the failing patches with v2025.01. Edited March 5 by Ian Goodacre 0 Quote
Ian Goodacre Posted March 5 Author Posted March 5 I have build completing with u-boot v2025.01. I can't test at the moment but building without errors is close and now I can add patches easily enough. The essential parameters were `BOOTBRANCH="tag:v2025.01"` and `BOOTPATCHDIR="v2025.01"`. Not documented at [Build Switches](https://docs.armbian.com/Developer-Guide_Build-Switches/) but there are many examples in config/boards. 0 Quote
Ian Goodacre Posted March 6 Author Posted March 6 I have tested my latest build. It boots from SD card. I ran armbian-install to install the system to boot from eMMC with system on a USB drive, shut down, removed the SD card and applied power, and it booted up, proving that u-boot now has access to the eMMC. I haven't proven that the WAN network port works from u-boot. It isn't a priority for me but based on the change I made working in the kernel, I am optimistic that the device tree is correct. So, success at last: I have modified the device tree for u-boot for nanopi-r2s-plus. Actually, I didn't edit the device tree for u-boot in any way, I just changed the board to use a more recent version of u-boot that has native support for NanoPi R2S Plus and proved that eMMC access works from e-boot. Thanks to Werner and Kwiboo. 0 Quote
Werner Posted March 6 Posted March 6 11 hours ago, Ian Goodacre said: . Not documented at [Build Switches] Probably because they are not intended to be used as build switches but in board configuration file 0 Quote
Kwiboo Posted March 6 Posted March 6 @Ian Goodacre mainline kernel should already have support for the onboard gmac Ethernet port? If you had issue with Ethernet using an unmodified kernel device tree, please try again after your U-Boot update. The Ethernet port was working fine in both U-Boot and kernel when I added support for the NanoPi R2S Plus to U-Boot. 0 Quote
Ian Goodacre Posted March 21 Author Posted March 21 (edited) @Kwiboo apologies for the late response. It seems I haven't been back to the forums for a while... I still misunderstanding something about the build framework as the image I get does not boot the kernel with the device tree I am expecting. But it seems easy enough to switch device tree by editing /boot/armbianEnv.txt and rebooting. edit: I figured out why I wasn't getting the device tree I expected: I had forgotten that I had configuration in userpatches. I deleted all that and made a new image which, this time, loaded the kernel device tree at boot, as expected. But it made no difference to the outcome of the test: the WAN port still didn't work. I note that the kernel dts for nanopi-r2s-plus has changed between 6.12 and 6.13 but I don't see any further change to current mainline: 6.14-rc7. I have built an image with u-boot v2025.01 and kernel 6.14.0-rc4-edge-rockchip64. When I boot this with the device tree I have modified the WAN port works but when I switch to the unmodified kernel device tree the WAN port does not work. By inspection of /proc/device-tree I can see that the device tree for the WAN port changes when I change /boot/armbianEnv.txt and reboot, and that it is what I expect based on my modified dts and the default kernel dts. I am not aware of any other changes, between WAN port working and not working, other than editing /boot/armbianEnv.txt to change the value of fdtfile. When I say unmodified kernel device tree, I am referring to the device tree derived from cache/sources/linux-kernel-worktree/6.14__rockchip64__arm64/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s-plus.dts in the build environment: ``` // SPDX-License-Identifier: (GPL-2.0+ OR MIT) /* * (C) Copyright 2018 FriendlyElec Computer Tech. Co., Ltd. * (http://www.friendlyarm.com) * * (C) Copyright 2016 Rockchip Electronics Co., Ltd */ /dts-v1/; #include "rk3328-nanopi-r2s.dtsi" / { compatible = "friendlyarm,nanopi-r2s-plus", "rockchip,rk3328"; model = "FriendlyElec NanoPi R2S Plus"; aliases { mmc1 = &emmc; }; }; &emmc { bus-width = <8>; cap-mmc-highspeed; disable-wp; mmc-hs200-1_8v; non-removable; pinctrl-names = "default"; pinctrl-0 = <&emmc_clk &emmc_cmd &emmc_bus8>; status = "okay"; }; &gmac2io { phy-handle = <&rtl8211e>; tx_delay = <0x24>; rx_delay = <0x18>; mdio { rtl8211e: ethernet-phy@1 { reg = <1>; pinctrl-0 = <ð_phy_reset_pin>; pinctrl-names = "default"; reset-assert-us = <10000>; reset-deassert-us = <50000>; reset-gpios = <&gpio1 RK_PC2 GPIO_ACTIVE_LOW>; }; }; }; ``` Am I using the wrong kernel dts? My modification, that makes the WAN port work is: ``` // SPDX-License-Identifier: (GPL-2.0+ OR MIT) /* * Copyright (c) 2025 Ian Goodacre */ /dts-v1/; #include "rk3328-nanopi-r2s-plus.dts" /delete-node/ &rtl8211e; &gmac2io { phy-handle = <&rtl8211f>; snps,reset-delays-us = <0 15000 50000>; tx_delay = <0x22>; rx_delay = <0x12>; mdio { rtl8211f: ethernet-phy@1 { compatible = "ethernet-phy-ieee802.3-c22"; reg = <0x1>; realtek,ledsel = <0xae00>; }; }; }; ``` Edited March 21 by Ian Goodacre New test results. 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.