NanoPi R4S

[Werner]

 

 

 

 

 

https://wiki.friendlyarm.com/wiki/index.php/NanoPi_R4S

 

I am really excited about this board.

 

Quote

• SoC: Rockchip RK3399
  • CPU: big.LITTLE，Dual-Core Cortex-A72(up to 2.0GHz) + Quad-Core Cortex-A53(up to 1.5GHz)
  • GPU: Mali-T864 GPU，supports OpenGL ES1.1/2.0/3.0/3.1, OpenCL, DX11, and AFBC
  • VPU: 4K VP9 and 4K 10bits H265/H264 60fps decoding, Dual VOP, etc
• PMU: RK808-D PMIC, cooperated with independent DC/DC, enabling DVFS, software power-down, RTC wake-up, system sleep mode
• RAM: 1GB DDR3/4GB LPDDR4
• Flash: no Onboard eMMC
• Ethernet: one Native Gigabit Ethernet, and one PCIe Gigabit Ethernet
• USB: two USB 3.0 Type-A ports
• Pin header extension interface
  • 2x5-pin header: SPI x 1, I2C x 1
  • 4-pin header: USB 2.0
• microSD Slot x 1
• Debug: one Debug UART, 3 Pin 2.54mm header, 3V level, 1500000bps
• LEDs: 1 x power LED and 3 x GPIO Controlled LED (SYS, LAN, WAN)
• others:
  • 2 Pin 1.27/1.25mm RTC battery input connector
  • one UserKey
  • one 5V Fan connector
• Power supply: DC 5V/3A, via USB-C connector or Pin header
• PCB: 8 Layer, 66 mm x 66 mm
• Ambient Operating Temperature: -20℃ to 70℃

 

 

https://www.cnx-software.com/2020/11/12/nanopi-r4s-headless-rk3399-sbc-features-up-to-4gb-ram-dual-gigabit-ethernet-usb-3-0-ports/

The first comments below this blogpost are also not so bad besides the fact that USB-C is power-in only.

 

[gounthar]

What is the problem with the PCIe Gigabit Ethernet?

[dolphs]

Wow nice - This might become my new vpn / pihole setup,

depending on $$$ as current OPiOnePlus does its job well.

Suppose armbian images can be build soon for this board.

@Wernerthanks for your info!

[Jiri Brejcha]

This looks like a great board.

 

It would be great if it supported OTG on the USB-C port. Also, the horizontal orientation of the USB 3.0 ports and their proximity might not allow us to plug two larger USB devices (Wi-Fi adapter, USB to serial adapter) at the same time. 

 

Having said that, Armbian would be my go to OS for this board if/when available. 

[Werner]

2 hours ago, Jiri Brejcha said:

proximity

Lots of board have similar issues. Debt of compactness. Thankfully you can get adapters for cheap.

[TRS-80]

I have been stockpiling WNDR3800 which are nowadays inexpensive and able to run fully in freedom, but obviously this would be a much, much more powerful little board.

 

I seem to recall some past discussion of certain RK3399 boards being possible to run without blobs?  Especially without graphics or Wi-Fi, I think makes this even more of a possibility.  Also it's DDR3 (well the 1GB model anyway; as all DDR4 implementations so far also require blobs, to my understanding).

 

Yeah, interested to see how this comes along.  Thanks for sharing, Werner.  Any feedback on blobs, especially, I would be very interested in.

[Werner]

https://www.cnx-software.com/2020/12/01/buy-nanopi-r4s-sbc-optional-metal-case/

 

 

4GB version about 62€ including shipping and tax to Germany

[piter75]

2 hours ago, TRS-80 said:

I seem to recall some past discussion of certain RK3399 boards being possible to run without blobs?

At this point roc-rk3399-pc is the only one with blob-less boot sequence by default but it's certainly possible with some others too 

https://github.com/armbian/build/blob/master/config/sources/families/rk3399.conf#L19

And it's LPDDR4 too...

[TRS-80]

38 minutes ago, piter75 said:

And it's LPDDR4 too...

 

I view all knowledge as "provisional." 

 

Which is why I keep asking, and re-stating what "I think I know."  Thanks a lot for valuable information, that can otherwise be hard to come by.  I think I am starting to get an idea where to look, however, so thanks for that, too.

[dolphs]

Ordered 1Gb version incl housing just now ,

let's hope at least WIP status will appear next few months for this one.

[Werner]

I'm curios about the USB3 performance. If somebody has a chance to hook up a SSD and do some tests would be cool.

[TRS-80]

11 hours ago, scargill said:

or am I missing something

 

I think so.

 

https://forum.armbian.com/topic/6617-the-purpose-of-this-subforum/

[dolphs]

Device with housing arrived today, cannot wait to deploy armbian on it :-), but will need to have some more patience

Once image is ready ( to be build ) and entered matured state will swap it with my OpiOnePlus as I'll solely use it for wireguard ( and ddclient / chrony ) 

[Werner]

Mine is still in transit between Shanghai and ROW

There are a few other things that need to be sorted out to get Armbian working on it: https://github.com/armbian/build/pull/2415

[Werner]

Board does now properly boot on current and dev branch.

[Werner]

Can somebody verify that both usb connectors work with dev branch 5.10.4?

On my board the one closer to the corner does not work.

 

works with FriendlyELEC 4.19.111

[HoSe_Colonia]

Confirmed:

 

Armbian 21.02.0-trunk Focal with Linux 5.9.16-rockchip64

 

The one in the middle works:

 

[  922.891909] usb 6-1: new SuperSpeed Gen 1 USB device number 2 using xhci-hcd
[  922.913139] usb 6-1: New USB device found, idVendor=090c, idProduct=2000, bcdDevice=11.00
[  922.913162] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  922.913178] usb 6-1: Product: Intenso Flash Line
[  922.913193] usb 6-1: Manufacturer: SMI Corporation
[  922.915257] usb-storage 6-1:1.0: USB Mass Storage device detected
[  922.917468] scsi host0: usb-storage 6-1:1.0
[  922.969173] usbcore: registered new interface driver uas
[  924.022772] scsi 0:0:0:0: Direct-Access     Intenso  Flash Line       1100 PQ: 0 ANSI: 6
[  924.024647] sd 0:0:0:0: [sda] 245760000 512-byte logical blocks: (126 GB/117 GiB)
[  924.025007] sd 0:0:0:0: [sda] Write Protect is off
[  924.025029] sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00
[  924.025382] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[  924.033101] sd 0:0:0:0: Attached scsi generic sg0 type 0
[  924.058523]  sda: sda1 sda2 sda3
[  924.060440] sd 0:0:0:0: [sda] Attached SCSI removable disk

 

The left one (corner) does not:

 

[  463.509617] usb 6-1: USB disconnect, device number 2
[  463.515097] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[  463.515366] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=0x01 driverbyte=0x00

 

 

 

 

[piter75]

19 hours ago, Werner said:

Can somebody verify that both usb connectors work with dev branch 5.10.4?

On my board the one closer to the corner does not work.

You can use "dwc3-0-host" overlay in /boot/armbianEnv.txt to enable it now - it switches to port from otg to host mode.

 

overlays=dwc3-0-host

 

I will prepare some corrections to the device tree soon and will enable the host by default to make it consistent with vendor's configuration.

[mathieuh]

I recently received my NanoPi R4S 4GB (my first SBC) and have been looking into running armbian on it (my first experience with it).

 

A few things I've noticed:

- The official 20.11.6 build (buster) does not bring up the network properly. It pings but SSH never starts. 20.11.5 or a local build from trunk seem fine. Just mentioning in case others wonder why the currently "latest" on the official page doesn't work

- The gmac ethernet device naming seems unstable. It usually comes up as `eth1` but sometimes come up as `eth0`. It seems to depend on timing when the r8169 pci adapter is brought up (in the first case it's named `eth0` before being renamed to the stable `enp1s0`). Is there precedent in armbian to force the integrated adapter to a more stable name such as `eno1` ?

- The `armbian-hardware-optimization` script for `rk3399` seem to hardcode `eth0` for the gmac adapter, which causes errors when it ends up as eth1:

Jan 13 01:35:46 nanopi-r4s armbian-hardware-optimization[638]: /usr/lib/armbian/armbian-hardware-optimization: line 234: /proc/irq/$(awk -F":" "/eth0/ {print \$1}" </proc/interrupts | sed 's/\ //g')/smp_affinity: No such file or directory
Jan 13 01:35:46 nanopi-r4s armbian-hardware-optimization[638]: /usr/lib/armbian/armbian-hardware-optimization: line 235: /sys/class/net/eth0/queues/rx-0/rps_cpus: No such file or directory
Jan 13 01:35:46 nanopi-r4s armbian-hardware-optimization[638]: /usr/lib/armbian/armbian-hardware-optimization: line 237: /sys/class/net/eth0/queues/rx-0/rps_flow_cnt: No such file or directory

- When I first played with the official 20.11.05 build, I experienced the r8169 pci adapter sometimes not being detected on command line reboots (with cable plugged in if that makes a difference). I didn't see anything particular in the logs besides the device completely missing. I'll see if I can reproduce again and post the logs.

- The built-in chrony seem to ignore my DHCP provided NTP server, and insists on using its built-in list. Since this device will end up on an isolated VLAN, it'll keep failing to synchronize clock. Since this is not a desktop like device and I'm not particularly happy with NetworkManager either (I need to build up a more complex VLAN and bridge based topology), I'll probably just build a custom image without either and enable systemd's networkd and timesyncd.

- The build scripts seem to pull an inordinate amount of dependencies (e.g. gcc for a bunch of platforms) even when simply building an image using "prebuilt" kernel and packages.  Wondering if supporting a flow for "light" customization of images (mostly limited to package installation and adding configs) is something that was considered?

[Werner]

59 minutes ago, mathieuh said:

The build scripts seem to pull an inordinate amount of dependencies (e.g. gcc for a bunch of platforms) even when simply building an image using "prebuilt" kernel and packages. 

Feel free to provide a PR that fixes this

 

1 hour ago, mathieuh said:

wonder why the currently "latest" on the official page doesn't work

Issues with images that are not marked as supported are to be expected.

[Igor]

4 hours ago, mathieuh said:

A few things I've noticed:

 

Thank you for your notices.

This hardware is new for us, we only made two builds and probably not a single run via our testing suite. Things are not polished and will need a couple of weeks / months.

 

4 hours ago, mathieuh said:

The gmac ethernet device naming seems unstable. It usually comes up as `eth1` but sometimes come up as `eth0`. It seems to depend on timing when the r8169 pci adapter is brought up (in the first case it's named `eth0` before being renamed to the stable `enp1s0`). Is there precedent in armbian to force the integrated adapter to a more stable name such as `eno1` ?

We can try this method:

https://github.com/armbian/build/blob/master/config/sources/families/include/rockchip64_common.inc#L301-L307

If it works for you, https://www.armbian.com/get-involved

 

4 hours ago, mathieuh said:

The `armbian-hardware-optimization` script for `rk3399` seem to hardcode `eth0` for the gmac adapter, which causes errors when it ends up as eth1:

 

This script should be upgraded once to support multi adaptor. I think no other Linux care about such optimisations, we lack of resources to keep up ... 

 

4 hours ago, mathieuh said:

When I first played with the official 20.11.05 build, I experienced the r8169 pci adapter

All builds for R4S are experimental at this point and in case we have a Realtek driver issue, it can take far longer to stabilise things. 

 

4 hours ago, mathieuh said:

The built-in chrony seem to ignore my DHCP provided NTP server, and insists on using its built-in list. Since this device will end up on an isolated VLAN, it'll keep failing to synchronize clock. Since this is not a desktop like device and I'm not particularly happy with NetworkManager either (I need to build up a more complex VLAN and bridge based topology), I'll probably just build a custom image without either and enable systemd's networkd and timesyncd.

Network manager is here because its simple to get going for an average Joe. We usually don't provide networking per board, sometimes yes. 

 

Old school ifconfig type of network settings is also operational - just define it and it will override Network Manager. If you need systemd networkd and timesyncd it should also work. You don't need to build custom images for that. Just disable or configure NetworkManager accordingly (I think it is doable without uninstalling it)

 

4 hours ago, mathieuh said:

The build scripts seem to pull an inordinate amount of dependencies (e.g. gcc for a bunch of platforms) even when simply building an image using "prebuilt" kernel and packages.

We are optimising build script round the clock. Every day. Making an image from pre-build kernel was added not long time ago, while refactoring and optimising build system to not download tools require significant work. Since maintaining this tool is almost entirely our private costs and its not small, we can't really afford to pimp all "nice to have" features. We have constant flow of important, sometimes critical features / problems.

 

If you want to get this board to production levels faster and deeper - you need to https://www.armbian.com/get-involved We are already far over our limits and expects your help. Not the other way around.

 

10 minutes ago, Igor said:

Wondering if supporting a flow for "light" customization of images (mostly limited to package installation and adding configs) is something that was considered?

 

We provide lots of features - just dive into "DEVELOPER GUIDE".

https://docs.armbian.com/Developer-Guide_User-Configurations/

https://docs.armbian.com/Developer-Guide_Build-Preparation/

[mathieuh]

I definitely understand the lack of polish for such a new board, I already very grateful for where I got so far. As for latest being broken, I mainly wanted to make sure others looking could find the 20.11.5 build which boots fine,.

 

I managed to get networkd and timesyncd working, and found a way to get the gmac interface name stabilized using a systemd .link file targeting the device Path. Wondering if a udev method would be preferred? In this case I believe targeting by driver will not work, for some reason it seemed to be missing when I tried.

 

I was looking into rebuilding an image with these tweaks included, and so I could maybe contribute some of it back, but this is where I started struggling. The build environment is very picky, and while I have a few x64 linux systems around, none of them were full Ubuntu or capable: Synology NAS with docker (lacking bin fmt tools), Chromebook with linux crostini VM and docker (lacking loopback devices).  Now that I finally got a build environment running, I'll try to see where I can help.

 

Thanks for the pointers on the existing board customization. If you have any suggestions on how to improve the handling of multi adaptor boards in the scripts, I'll try to see what I can do.

[Igor]

3 hours ago, mathieuh said:

Wondering if a udev method would be preferred?

Yes.

 

3 hours ago, mathieuh said:

I was looking into rebuilding an image with these tweaks included, and so I could maybe contribute some of it back, but this is where I started struggling. The build environment is very picky, and while I have a few x64 linux systems around, none of them were full Ubuntu or capable:

 

It runs well under Docker if host is not too exotic ...

 

3 hours ago, mathieuh said:

If you have any suggestions on how to improve the handling of multi adaptor boards in the scripts, I'll try to see what I can do.

Universal approach seems like a lot of work, but adding few bits for second nic here https://github.com/armbian/build/blob/master/packages/bsp/common/usr/lib/armbian/armbian-hardware-optimization#L245-L253 is already a good to go.

[sfx2000]

On 1/12/2021 at 7:37 PM, mathieuh said:

A few things I've noticed:

 

- The gmac ethernet device naming seems unstable. It usually comes up as `eth1` but sometimes come up as `eth0`. It seems to depend on timing when the r8169 pci adapter is brought up (in the first case it's named `eth0` before being renamed to the stable `enp1s0`). Is there precedent in armbian to force the integrated adapter to a more stable name such as `eno1` ?

 

- When I first played with the official 20.11.05 build, I experienced the r8169 pci adapter sometimes not being detected on command line reboots (with cable plugged in if that makes a difference). I didn't see anything particular in the logs besides the device completely missing. I'll see if I can reproduce again and post the logs.

 

 

u-boot and device tree optimizing works wonders here - need to declare the interfaces before the kernel boots, otherwise it's going to grab the first one ready...

[hive]

I'm running into the issue that @mathieuh described where enp1s0 comes up and the other interface either doesn't come up or shows up seemingly randomly as eth0 or eth1

@mathieuhDid you ever find a fix for this?

@sfx2000 Do you have any pointers on u-boot and device tree optimization to resolve this?

Armbian on this board seems unreliable without resolving the network bringup consistency--What recommendations do people have to resolve this?

[RussianNeuroMancer]

On 3/14/2021 at 9:27 PM, hive said:

the other interface either doesn't come up or shows up seemingly randomly as eth0 or eth1

I didn't have this issue yet (at least on 5.10.21) but just in case I configured two networkd-based bridges, one with slave with Name=enp* and another slave with Name=eth*

[hive]

I built my own Armbian image from trunk (Armbian_21.05.0-trunk_Nanopi-r4s_focal_current_5.10.24.img) and it seems to work correctly.  It does not have the issues that I experienced using the pre-built image.

 

[Craven]

Hi, I have a question about the USB, it won't detect one of the USB port at the edge of the side.

 

I am currently using the latest armbian Focal (Armbian 21.02.3 Focal) and I added `overlays=dwc3-0-host` at the `/boot/armbianEnv.txt`

I also upgraded the kernel to the latest

but It still does not detect the USB port. I even upgrade the kernel to the latest `rockchip64_21.05.0`

 

[    0.000000] Kernel command line: root=UUID=907215a9-a8d9-4dac-8c3b-847a6c0a19ba rootwait rootfstype=ext4 console=ttyS2,1500000  consoleblank=0 loglevel=1 ubootpart=07c8ce4c-01 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u   cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1
[    1.251412] vcc5v0_usb1: supplied by vcc5v0_sys
[    1.251880] vcc5v0_usb2: supplied by vcc5v0_sys
[    1.256795] usbcore: registered new interface driver usbfs
[    1.256850] usbcore: registered new interface driver hub
[    1.256897] usbcore: registered new device driver usb
[    2.678800] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.10
[    2.678812] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.678821] usb usb1: Product: xHCI Host Controller
[    2.678829] usb usb1: Manufacturer: Linux 5.10.26-rockchip64 xhci-hcd
[    2.678837] usb usb1: SerialNumber: xhci-hcd.0.auto
[    2.679982] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
[    2.680128] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 5.10
[    2.680138] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.680147] usb usb2: Product: xHCI Host Controller
[    2.680156] usb usb2: Manufacturer: Linux 5.10.26-rockchip64 xhci-hcd
[    2.680163] usb usb2: SerialNumber: xhci-hcd.0.auto
[    2.681192] usbcore: registered new interface driver usb-storage
[    2.733118] usbcore: registered new interface driver usbhid
[    2.733124] usbhid: USB HID core driver
[    3.776194] usb 2-1: new SuperSpeed Gen 1 USB device number 2 using xhci-hcd
[    3.797179] usb 2-1: New USB device found, idVendor=21c4, idProduct=0cd1, bcdDevice=11.00
[    3.797201] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    3.797213] usb 2-1: Product: USB Flash Drive
[    3.797224] usb 2-1: Manufacturer: Lexar
[    3.797236] usb 2-1: SerialNumber: 04174MF5H7S9MPLV
[    3.798801] usb-storage 2-1:1.0: USB Mass Storage device detected
[    3.806730] scsi host0: usb-storage 2-1:1.0
[    3.872408] usbcore: registered new interface driver uas

 

Bus 002 Device 002: ID 21c4:0cd1 Lexar USB Flash Drive
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

 

Do you guys have any ideas?

Edited March 27, 2021 by Craven

[Igor]

On 3/27/2021 at 4:01 AM, Craven said:

and I added `overlays=dwc3-0-host` at the `/boot/armbianEnv.txt`

Have you developed an overlay???  I am not sure we have it - check with armbian-config -> system -> hardware

 

On 3/27/2021 at 4:01 AM, Craven said:

I even upgrade the kernel to the latest `rockchip64_21.05.0`

 

Why? We don't support this hardware and make no changes. You can check build system https://github.com/armbian/build and https://www.kernel.org/. Why do you think this forum section (Board bring up) exists?

 

There is no support (yet) for this hardware whatsoever and it might never be unless you start doing something. If you don't know much to help around this particular problem, you can trade your time in for https://forum.armbian.com/forum/54-help-wanted/
 

On 3/27/2021 at 4:01 AM, Craven said:

Do you guys have any ideas?

We do, but no time to investigate them.

[cheesesticks]

I'm having the same issue with interfaces and did some digging, it looks like systemd/udev v197 will solve this https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/