Ian Goodacre

@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 = <&eth_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>; }; }; }; ```

For whoever might be interested in NanoPi R2S Plus: I have built an image for my NanoPi R2S Plus that has the WAN port and eMMC working, so I am able to install and boot from eMMC with system on a USB attached disk drive, and with LAN and WAN ports both working. I haven't tested whether the WAN port works from u-boot (e.g. for booting via BOOTP) - the dts/dtb used by u-boot is different from that in the kernel. To achieve this, I have a new board configuration that uses v2025.01 u-boot and a dts that includes the dts for NanoPi R2S Plus in the kernel, with modification to make the WAN port work (eMMC works with the kernel dts as-is). Otherwise, it is a copy of the board configuration for NanoPi R2S, with the name changed. This is all done via configuration in my userpatches of Armbian build framework. If you're interested, you can get the configuration from my userpatches git repository: https://github.com/ig3/armbian-userpatches I have submitted a pull request to have these changes added to the Armbian build framework but it is not yet accepted.

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.

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.

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.

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

Reported and updated: the indication of an 'empty' patch is false. Accept it and a non-empty patch file is produced.

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.

I have created an Armbian board config: nanopi-r2s-plus.csc, and a patch to the in kernel device tree rk3328-nanopi-r2s-plus.dts, to fix the WAN port. This avoids name collisions with both FriendlyElec and Linux kernel. The new patch is rk3328-nanopi-r2s-plus-a1.dts and it includes rk3328-nanopi-r2s-plus.dts, provided by the kernel. Working for me with the 6.12 kernel. What are the prospects for getting this into armbian/build? Should I just submit a pull request?

I haven't thought so far as kernel updates. That's another puzzle to ponder 😉

I have initial success: I have modified dts for nanopi-r2s-plus and now have my device with both LAN and WAN ports working with 6.12 kernel. I wonder about naming conventions. Existing dts files for nanopi-r2* seem to follow the naming conventions used by FriendlyElec. For the nanopi-r2s-plus, FriendlyElec added rk3328-nanopi-r2-rev24.dts. I added rk3328-nanopi-r2s-plus.dts instead, starting with a copy of rk3328-nanopi-r2-rev00.dts (used for NanoPi R2S). The names used by FriendlyElec seem arbitrary to me but maybe there is some bigger pattern that I am not yet seeing. Also, mainline kernel has rk3328-nanopi-r2s-plus.dts, rk3328-nanopi-r2s.dts and rk3328-nanopi-r2c.dts. Armbian has rk3328-nanopi-r2-rev00.dts and rk3328-nanopi-r2-rev06.dts for the latter two. I wonder why Armbian is not using those in the kernel. Maybe for historical reasons? I had tried to use rk3328-nanopi-r2s-plus.dts initially but WAN port didn't work and when I tried to 'fix' it, I ended up with the configuration that didn't boot. Maybe I should revisit the mainline dts, now that I have one working. In the meantime, I think the patch I have added to Armbian overwrites rk3328-nanopi-r2s-plus.dts from the kernel, which isn't ideal. But I am reluctant to add yet another name just to avoid conflicts with the names used by mainline and FriendlyElec. The names in mainline make more sense to me. Is there any guidance anywhere about coordination between FriendlyElec, Armbian and mainline kernel, as far as the dts files are concerned?

@jock, @Werner: thanks for the guidance. I have recovered my system and learned enough about the basic boot process that I can now get back to modifying the device tree to make the RTL8211F based network interface work. I think I now have a much more solid foundation and hope I can progress by little steps. I'll post again when I have it working.

Thanks Werner. I have found some of the log message text in the u-boot source code. As you suggest, it seems to be stuck in u-boot and not getting to a Linux kernel at all. I'm guessing BOOTP is a fallback in case it can't find an image to load on any storage. 'scanning usb for storage devices... 0 Storage Device(s) found' doesn't look good. It should be booting from the SD card. It did, before I messed with the device tree. I think u-boot cannot find any image to load so it presents a prompt ('=> ') and waits for a command to tell it what to load. I will have to capture the whole log and see what other clues I can find. At the moment, I only have a bit of cut-and-paste of the end of it. I guess I broke the device tree so it can't find the image to load on the SD card. I really need to learn how to inspect the device tree generated by armbian/build when the system doesn't boot. I guess it's in the image somewhere. I'm hobbled by my ignorance but learn a little each day 😉

I have a NanoPi R2S Plus. If I boot the FriendlyElec Debian image both network ports work: LAN and WAN. If I boot the Armbian NanoPi R2S image, it boots OK and the LAN port works but the WAN port does not work. I believe the WAN port does not work because the NanoPi R2S has an RTL8211E chip but the NanoPi R2S Plus has an RTL8211F chip. I found some notes about problems with network on other boards that had the same change of chip (e.g. radxa RockpiE) and the device tree changes required to accommodate the new chip. So I tried to patch armbian/build to make the same changes for the NanoPi R2S Plus. I am not familiar with armbian/build or device trees. None the less, I seem to have made some progress. My latest image attempts to bring up the WAN port. It gets an IP address from dhcp server. But then it tries to get various files by TFTP and fails. It has no server IP and I have no TFTP server running. Part of the console logs: Now I am lost. I don't understand why it is trying to load files by TFTPGET. Maybe I have something wrong in the device tree so it is loading an incorrect device driver. There is the line 'Device 0: unknown device'. The first file it attempts to retrieve appears to have the MAC address of the LAN port in the filename. It continues trying to load various files then fails and presents a prompt: '=> ' Can anyone give me pointers to where to look / what to read to understand what is going on? Is that a u-boot prompt? Any pointers would be much appreciated and, again, this is all new to me - I am blundering about in my ignorance.

I logged in to the Armbian forums today, for the first time in a long time. I got a message that I had to confirm my email. I didn't capture a screenshot and the screen is now gone. I promptly received an email, subject: We've Missed You! Your Account is Active Again. This had some details of my recent access and: "If this was you, please ignore this email. Otherwise, you should secure your account immediately." There was a button: Review Activity & Secure Account. I clicked that button. A page opened with the message: Oops! The page you are trying to access is not available to guests, but may be available if you sign in. I went back to the page that I got when I tried to login, telling me a confirmation email had been sent. At the bottom was a link to resend the confirmation email. I clicked that and this time I promptly got an email with subject: Please confirm your email address change. It had a button: Confirm this address. I clicked it and was then logged in. So, I got in, but it was a bit roundabout. When I first logged in and got the page indicating I need to confirm my email, it seems the email confirmation email wasn't sent. The welcome back email advising of recent activity was fine, except that the button in it went to a non-existent page. The button URL, slightly redacted, was: https://forum.armbian.com/index.php?app=core&module=system&controller=redirect&url=https://forum.armbian.com/settings/devices/&key=**********&email=1&type=loginAfterInactivity. The Resend confirmation email link on the initial page after login worked fine. So, a couple of minor problems with the forum authentication. I looked through the forums and none looked appropriate to an issue with the forums themselves, so I have posted here. Apologies if it is off topic for the off topic forum 😉 Please let me know if there is a better way to get this to the attention of those managing the forums. On the other hand, it is only a minor issue and there are probably more important / valuable things to do, so no worries if this stays as-is. Regards, Ian