Add support for NanoPi R2S Plus #7913
Conversation
ig3
requested review from
ColorfulRhino,
SuperKali,
amazingfate,
catalinii,
efectn,
joekhoobyar,
paolosabatino,
pyavitz,
rpardini,
JohnTheCoolingFan,
Manouchehri,
TRSx80,
TheSnowfield,
Tonymac32,
ahoneybun,
brentr,
clee,
igorpecovnik,
krachlatte,
lanefu and
schwar3kat
as code owners
github-actions
bot
added
size/medium
|
@ig3 the device tree in mainline Linux should already work as-is, did you test without any of your DT mods after you updated to U-Boot v2025.01? |
|
Also think |
Would you act as a maintainer of this board? BOARD_MAINTAINER="" For .csc this is obligation free, for supported, testing & reporting its status before release. https://docs.armbian.com/User-Guide_Board-Support-Rules/#standard-support |
|
@Kwiboo I first made a board config for NanoPi R2S Plus that was based on the Armbian NanoPi R2S device tree but eMMC and WAN network port didn't work, as expected, as that was the case with the NanoPi R2S image. I modified it following what FriendlyElec did in their kernel and then both worked. But then I changed the board config to use the device tree from the kernel as-is. The eMMC worked but the WAN port did not. Again I had to make changes to accommodate the change from rtl8211e to rtl8211f on the WAN port. With those changes, both eMMC and WAN port work. The board config I have submitted is based on the kernel device tree rather than what is used for NanoPi R2S in Armbian. @igorpecovnik I only have one NanoPi R2S Plus, without the WiFi add-on, and very little experience with the build framework, device trees and u-boot, but otherwise would be happy to look at any issues as they arise. Best effort, subject to my availability. I'll test kernel upgrades from time to time in any case. Would that suffice? |
|
@Kwiboo Regarding BOOT_SCENARIO, I'm not familiar with it or trust.ini or the implications of going one way or the other. But quite happy to take advice on the matter. I only stumbled through getting it to work. Edit: I think there was an error message about trust.ini and I followed the suggestion in the error message. Recollection is a bit vague now. It seemed a small detail - one among many unfamiliar details that 'just worked', well enough from my perspective. |
|
I should say that I'm quite happy to keep the configuration for NanoPi R2S Plus in my userpatches. I submitted the pull request as a small contribution in appreciation of all that Armbian project provides for me. So only accept it if it seems good for the project. No worries either way, but thanks much for Armbian! |
Keeping an eye on the device before (major) kernel / u-boot upgrades are most critical so its nice that someone is around to report - knowing that something is wrong with the device is already an added value, fixing the problem = nice but not mandatory - we also only do what we can / possible / time permits. |
The WAN port most likely did not work because of an issue in mainline Linux where the RTL8211F PHY is not reset prior to being probed. Now that you have moved to use a mainline U-Boot defconfig for the NanoPi R2S Plus, the RTL8211F PHY should be reset by U-Boot and Linux should be able to probe it. I.e you should no longer need a custom
I have no insight or interest into what or how stuff works in Armbian, it is not something I use myself. However, I keep seeing people having issues that should already work with upstream mainline Linux and U-Boot. And those issues is mostly due to an old and broken versions of U-Boot is being used with latest mainline Linux. So when it relates to a board I maintain in U-Boot or have helped upstream in mainline Linux I try to understand if there is a real issue that could/should be fixed in upstream or not. NanoPi R2S Plus is one such board and in this case I think you just needed to use a newer mainline U-Boot with a defconfig made for your board. |
|
@Kwiboo I didn't know you maintain the board in u-boot - that's a pleasant surprise. And I do very much appreciate your guidance. I think I get your point about initialization. I changed u-boot to v2025.01 after I had modified the dts in the kernel. The modification made the difference between working and not working with the older version of u-boot but perhaps it is not necessary with u-boot v2025.01. I attempted to test this today but I have encountered some difficulties. First, I tried to rebuild with board config modified to use the dts/dtb from the kernel directly, so no modification. Build failed due to failure to apply a patch. It seems the build framework updated the kernel from 6.12.17 to 6.12.18 without me changing anything about kernel version. I suspect version 6.12 is specified and it gets the most recent. The failing patch is nothing to do with what I am doing but looking at commits to armbian/build since 0c2e63c, which I was working against last week, I see commit 45621aa, which looks relevant. I pulled the most recent commits to armbian/build and rebuilt, this time without errors applying patches. But now, when I boot from a freshly flashed SD card, there is something wrong at the console. Everything appears normal up to the first prompt to set root password. But the second prompt doesn't appear. Instead, each time I press the enter key, everything scrolls up, but no further / other output. And I get the same behaviour at the console and via an ssh session. I flashed my image from last week and all works as expected. Then, just in case, I rebuilt using the modification I had made to the kernel dts for the WAN port but got the same behaviour in the first boot script. What's changed?
When I first had the trouble with the patch, I did clean make-kernel, make-uboot, cache and sources, in case I had messed something up on my end, before I looked to updates to armbian/build. I'm not adept enough with the build framework to make it build again with 6.12.17, though I expect there is a way: setting some switch on the command line but otherwise leaving everything as I had done last week. If I could, I might be able to step through the various armbian/build commits to try to isolate the cause of the new behaviour. With the console not working at first boot, I don't know how to investigate. Is there a simple way to skip the first boot script and get straight to a root prompt? Edit: I don't see anything obvious in kernel commits since 6.12.17. I wonder if armbian/build commit 7f32a58 has something to do with the change - just going by the description. I'll have a closer look later. Edit: It seems armbian/build commit 7f32a58 is the immediate cause of the changed behaviour at first boot. It adds some lines to packages/bsp/common/usr/lib/armbian/armbian-firstlogin, to Enable wait-online.service in firstlogin config. If I comment out the new lines I get the old / good behaviour. If I put them back in I get the new / bad behaviour. It's not obvious to me how those lines can cause the new behaviour nor if it an adverse interaction with my build only or more general. I have some other commitments for the next few days but I'll look at it further, when I can. |
|
If I wasn't to impatient, I would have seen that after a timeout the script proceeds. After setup and logging in I find: And from syslog around that time: Also, in multiple earlier tests, I was able to ssh to the server and observe the same behaviour of the script via ssh as via the console which suggests that the network was working about the time of the error. |
|
After completing first boot setup and logging in via ssh I get: edit: the error appears a couple of minutes after issuing the command. |
|
A little more testing... The NanoPi R2S Plus has two network interfaces: I have been testing with connection to the LAN port only: enx72bfff86495e systemd-networkd-wait-online.service appears to be testing both network ports. The ports can be tested separately. I tested each and each one behaves the same: if the network is connected the test completes quickly; but if there is no network cable in the port, the test times out after two minutes. Much of the advice about such timeouts is focused on passing the test as soon as one interface is configured, either with the option --any or by ignoring interfaces that will not be coming up or by specifying the one interface that should come up. But what of the scenario where the first boot of the board is with a console connection and no network yet connected? Then, even if all the hardware and image are in good order, it seems one must wait for a timeout (two minutes per the documentation). I understand that some services should not start until the network is up but why should the first login script wait? If it is running on the console, there is no need to wait for the network to complete initial setup. If it is running in an ssh session, the network is sufficiently up to complete initial setup. I don't see the value of waiting for the network to come up in the midst of that initial setup. edit: <deleted nonsense about starting one of the 'wait-online' services> I get it now. I misread the script. And, if it going to be started again, a message to the user advising so that a delay is understandable would be helpful. As-is, the first prompt for root password is presented, then after entering it there is a two minute delay before the error message appears after which the second prompt for root password appears. This is probably not the best context for pursuing this, but it's the context in which I am impacted. Issue #7896 is now closed. |
|
@Kwiboo : I made a new image with u-boot v2025.01 and dts from kernel 6.12.18 without any modification. The LAN port works but the WAN port does not. |
Description
Add support for FriendlyElec board NanoPi R2S Plus
Enables eMMC and WAN port.
Device tree for the kernel is the kernel device tree for NanoPi R2S Plus with a patch to enable the WAN network port.
u-boot version is v2025.01 which has native support for NanoPi R2S Plus.
Four files added. No changes to existing files.
How Has This Been Tested?
Build current and edge images. Booted from SD. Installed with armbian-install to boot from eMMC with system on USB drive then removed SD card and booted from eMMC. Test LAN and WAN ports by ssh connection.
Checklist: