Will it be fixed in the future kernels ?

The system info: https://paste.armbian.com/ekotoqigos

nanopi-r4s:~:% ip a 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 68:27:19:ad:02:09 brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.180/24 brd 192.168.100.255 scope global dynamic noprefixroute eth0
       valid_lft 85963sec preferred_lft 85963sec
    inet6 fe80::ca55:3549:7a23:57fa/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

nanopi-r4s:~:% sudo dmesg | grep -i pcie
[    2.211030] rockchip-pcie f8000000.pcie: host bridge /pcie@f8000000 ranges:
[    2.211102] rockchip-pcie f8000000.pcie:      MEM 0x00fa000000..0x00fbdfffff -> 0x00fa000000
[    2.211138] rockchip-pcie f8000000.pcie:       IO 0x00fbe00000..0x00fbefffff -> 0x00fbe00000
[    2.212106] rockchip-pcie f8000000.pcie: no bus scan delay, default to 0 ms
[    2.212182] rockchip-pcie f8000000.pcie: no vpcie12v regulator found
[    2.713110] rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout!
[    2.713187] rockchip-pcie: probe of f8000000.pcie failed with error -110

nanopi-r4s:~:% uname -a
Linux nanopi-r4s 6.1.50-current-rockchip64 #3 SMP PREEMPT Wed Aug 30 14:11:13 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux

nanopi-r4s:~:% cat /etc/os-release 
PRETTY_NAME="Armbian 23.8.1 jammy"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.3 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.armbian.com"
SUPPORT_URL="https://forum.armbian.com"
BUG_REPORT_URL="https://www.armbian.com/bugs"
PRIVACY_POLICY_URL="https://www.armbian.com"
UBUNTU_CODENAME=jammy
ARMBIAN_PRETTY_NAME="Armbian 23.8.1 jammy"

I've checked the following post, and this bug should already be fixed, I don't know why it reappeared.

The kernel message is old message: `PCIe link training gen1 timeout!`.

I expect the new message should be something like: `PCIe link training gen1 timeout with x%d!\n`.

It seems that the `drivers/pci/controller/pcie-rockchip-host.c` patch is not included in the latest nanopi r4s jammy 6.1 kernel?

https://github.com/armbian/build/pull/4308/files

NanoPi R4s, enp1s0 ethernet device not showed up after reboot

run modprobe ledtrig-netdev to check if it's loading the driver properly. If not, add the file /etc/modules-load.d/ledtrig.conf 
add just this line:

ledtrig-netdev

Then, create /etc/tmpfiles.d/leds.conf and add this:

w /sys/class/leds/green:lan/trigger - - - - netdev
w /sys/class/leds/green:lan/device_name - - - - eth0
w /sys/class/leds/green:lan/link - - - - 1
w /sys/class/leds/green:lan/tx - - - - 1
w /sys/class/leds/green:lan/rx - - - - 1

w /sys/class/leds/green:wan/trigger - - - - netdev
w /sys/class/leds/green:wan/device_name - - - - eth1
w /sys/class/leds/green:wan/link - - - - 1
w /sys/class/leds/green:wan/tx - - - - 1
w /sys/class/leds/green:wan/rx - - - - 1

w /sys/class/leds/red:power/trigger - - - - activity

Note that "red:power" is actually the "green:sys" LED. I don't see a way to control the red power led (which is fine, the green:sys is what want to control anyway).

I also use NetworkManager and set my ethernet names to eth0 and eth1 instead of the default names...

Here's all the choices available for "triggers":

none
usb-gadget usb-host
kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock
disk-activity disk-read disk-write
mtd
nand-disk
heartbeat
cpu cpu0 cpu1 cpu2 cpu3 cpu4 cpu5
activity
default-on
panic
usbport
mmc1
rfkill-any rfkill-none
r8169-0-100:00:link r8169-0-100:00:10Mbps r8169-0-100:00:100Mbps r8169-0-100:00:1Gbps
stmmac-0:01:link stmmac-0:01:10Mbps stmmac-0:01:100Mbps stmmac-0:01:1Gbps
netdev

"activity" is also a good one for red:power if you prefer that to "heartbeat"

I can't figure out how to set it to peripheral mode so I can have some usb-gadget love. Anyone figured out a fix?

https://paste.debian.net/1337993/

it is a compressed tar.gz file since I included all the results of the command

Analysis.txt

I was looking for a Noble Gnome-based image for NanoPi R4S, and only found one that is trunk-based, and had BIG RED letters stamped on it: DO NOT USE FOR PRODUCTION.

Is there anything coming in that regard? Will we have a proper Noble Gnome-based release for NanoPi R4S?

Thanks!

i ve been lately working with nanopi-r5s which comes with a default openwrt os installed on EMMC.

but i prefer working on the armbian images. that is why i installed debian 12 bookworm from https://www.armbian.com/nanopi-r5s/

anyway, r5s refuses to boot from sd card for no matter what. until i corrupted the emmc by mistake(i started flashing a default image to emmc but then took the power off before it is done). 

so now it boots from sd card.  but now when m trying to install the image from sd card to emmc through armbian-install. it only shows option 5 and 6. as if it can not detect the emmc.

so what m trying to figure out is:

how to force nanopi r5s to boot from sd card even though there is openwrt at emmc and how then could i flash my sd os to the emmc.

thanks in advance

i recently observed a weird behavior with my nanopi R4s(jammy os).

when the power goes OFF then ON in like 5 seconds duration then the nanopi does not boot up at all!

i need to remove the adapter for like 15 seconds so it would be able to boot again!

is this normal?

Everything seems to work just fine, but I am missing my second network interface. Only the WAN interface is shown.

Is there a software fix I can apply, or should it be fixed in the OS image?

armbianmonitor -u output:
https://paste.armbian.com/gipilapuve

I have a problem with my NanoPi R4S. The WAN (eth0) port does not work well when it is configured to work on 1Gbps/Full. When this setting is active there is about 15% packet loss, which is quite annoying.

In my tests I have already been able to identify that if I configure the port to work at 100Mbps/Full everything works normally. So I found the forum-post below, that explain that some u-Boot version wasn't setting the correct clock configuration for the netwok device at boot time, but now I have installed the linux-u-boot-nanopi-r4s-edge  22.08.6 and linux-image-edge-rockchip64 22.08.8 but the problem still there. 

I've read millions of forums for the solution, and so far I haven't made much progress. Would anyone be able to help me?

in dmesg it looks like:

[    1.853954] rk_gmac-dwmac fe300000.ethernet: IRQ eth_wake_irq not found
[    1.853967] rk_gmac-dwmac fe300000.ethernet: IRQ eth_lpi not found
[    1.854071] rk_gmac-dwmac fe300000.ethernet: PTP uses main clock
[    1.854234] rk_gmac-dwmac fe300000.ethernet: clock input or output? (input).
[    1.854244] rk_gmac-dwmac fe300000.ethernet: TX delay(0x28).
[    1.854253] rk_gmac-dwmac fe300000.ethernet: RX delay(0x11).
[    1.854267] rk_gmac-dwmac fe300000.ethernet: integrated PHY? (no).
[    1.854320] rk_gmac-dwmac fe300000.ethernet: cannot get clock clk_mac_speed
[    1.854326] rk_gmac-dwmac fe300000.ethernet: clock input from PHY
[    1.859341] rk_gmac-dwmac fe300000.ethernet: init for RGMII
[    1.860175] rk_gmac-dwmac fe300000.ethernet: User ID: 0x10, Synopsys ID: 0x35
[    1.860191] rk_gmac-dwmac fe300000.ethernet:         DWMAC1000
[    1.860199] rk_gmac-dwmac fe300000.ethernet: DMA HW capability register supported
[    1.860206] rk_gmac-dwmac fe300000.ethernet: RX Checksum Offload Engine supported
[    1.860212] rk_gmac-dwmac fe300000.ethernet: COE Type 2
[    1.860218] rk_gmac-dwmac fe300000.ethernet: TX Checksum insertion supported
[    1.860224] rk_gmac-dwmac fe300000.ethernet: Wake-Up On Lan supported
[    1.860283] rk_gmac-dwmac fe300000.ethernet: Normal descriptors
[    1.860291] rk_gmac-dwmac fe300000.ethernet: Ring mode enabled
[    1.860297] rk_gmac-dwmac fe300000.ethernet: Enable RX Mitigation via HW Watchdog Timer
[   11.139092] rk_gmac-dwmac fe300000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
[   11.178717] rk_gmac-dwmac fe300000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet] (irq=75)
[   11.189571] rk_gmac-dwmac fe300000.ethernet eth0: No Safety Features support found
[   11.189610] rk_gmac-dwmac fe300000.ethernet eth0: PTP not supported by HW
[   11.190145] rk_gmac-dwmac fe300000.ethernet eth0: configuring for phy/rgmii link mode
[   14.868809] rk_gmac-dwmac fe300000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx

I was thinking that the line below was the problem, but I'm confused now:

Quote

rk_gmac-dwmac fe300000.ethernet: cannot get clock clk_mac_speed

armbianmonitor -u: https://paste.armbian.com/joperiqoso

The ethernet device naming seems inconsistent.  

Sometimes one interface comes up as eth0 and sometimes as eth1, and sometimes not at all.  The enp1s0 interface seems to reliably come up, but not with the right config (sometimes it uses the config for enp1s0 and sometimes for eth0).

I am trying to assign status IP addresses (on different networks) to each interface, but because of the unreliable bringup of the network interfaces, I can't get a config that starts up correctly and consistency on reboots or cold boots.

As a test I ran the friendly-core-lite-focal from FriendlyCore and it does not have this issue.

Is there something I need to do on Arabian to get the network interface bringup to work?

I have static IP configs in /etc/network/interfaces.d called eth0, eth1 (these are the same, call it network A, because the 2nd network seems to sometimes come up as eth0) , and enp1s0 (configured for my second network, call it network

I'd greatly appreciate any help in making the network bring up consistent.

I ask for you help with following issue:

Device: Nanopi-r4s 4GB

Background:

I'm happy with my device running from SD - but wanted to preemptively upgrade to eMMC based setup for improved reliability.

I bought "original" FriendlyELEC SD-to-eMMC adapter + 64GB eMMC module.

with normal microSD it boots great, with the sd-to-eMMC - nothing multiple attempts, tried both cloning my old SD & writing fresh image but both didn't help.

eMMC type is 1.8V\3.3V HS400 speed, i think i need to address that in the .dtb file ?

any help would be much appreciated

Uri

I now have my Nanopi R4S for quite a while but never got it to run stable over a longer period of time. Now I finally connected another board to its debug serial in the hopes to catch something that causes the board to freeze.

Well this is what I have collected:

https://p.na4.eu/?bc818aefadc9b5b2#DAunYKXghkaqcLhh8SLWMKTWABewpwPJRnHMHDemR98Y

The log is complete, there is nothing missing between 08:51 and 19:14. This is how I collected it.

Basically during the state of throwing errors the board becomes unresponsitive and continously heats up. Active cooling was in place so no danger of overheating.

https://paste.armbian.com/ijoromadit

Result is the same for current 5.15.y kernel.

After NanoPi R4S reboot, ethernet interface `enp1s0` disappeared. I tried soft reboot for several times but failed. 

If I shutdown the board and power plug out/in again, then `enp1s0` appears. I tested it several times and 100% same results.

Any idea please?

wg* is for vpn. please ignore them.

due to a project I'm working with the Friendly Elec Nanopi R4S board for which I've to use the i2c bus to read data from a sensor. Unfortunately I've not been able to access it, since the system does not recognize it. I tried with different configurations using the /boot/armbianEnv.txt file with no results, however the i2c ports are enabled.
To rule out functionality problems in the sensor, I connected it to other boards (e.g. nanopi Neo3 using Armbian) without problems.

Do you have any idea what could be the cause of this problem? Thanks!

First of all, thanks for the Armbian project, love it so far, but had a slight problem with a kernel upgrade. To be honest, I forgot how I installed Armbian since it was a while ago, but I've been using this for a year or so.

I saw that unattended-upgrades installed a new kernel and I should reboot for this change. I was a bit apprehensive, but went ahead and rebooted. The NanoPI R4S didn't come back up. I attached a serial console to debug. The console showed that the initramfs was read successfully from the SD card, but then tried to mount to root filesystem by UUID and failed (it kept saying it tried to run /boot/local-block and eventually giving up and complaing that it couldn't find the root filesystem with UUID=...). I checked if the device was present in /dev, I only saw /dev/mmcblk1, but no "p1".

After a lot of debugging and trying, I noticed that if I took the SD card out, then put it back in, dmesg would show that it found the partition and only then it showed both /dev/mmcblk1 as well as /dev/mmcblk1p1. At that moment, if I exit the initramfs, it boots the system as normal.

After some trial and error, I noticed this happens with the linux-image-current-rockchip64=22.02.1 image. I can boot without problems with the linux-image-current-rockchip64=21.08.2 image, so I downgraded to that version of the package and put it on hold for now. I now have a working system with the linux-image at the 21.08.2 version, even though I upgraded the other packages (like linux-u-boot-nanopi-r4s-current to) their 22.x versions!

I looked around for a solution to this problem (or even understand it), but couldn't find something, so I decided to file this bug report. I did see someone mention changing the dtb (/boot/dtb/rockchip/rk3399-nanopi-r4s.dtb? /usr/lib/linux-image-current-rockchip64/rockchip/rk3399-nanopi-r4s.dtb? I don't know which one ends up in the initramfs) which I tried, but ultimately this did not fix my problem.

Now whenever I install the new kernel and I need to reboot, I know I can take out the SD-card a couple of seconds after booting, then put it back it to let the OS detect the partition. It's not ideal, but better than having to open up the case and attach a serial console.

Is this a known problem? Are there known solutions for this? I'm afraid this problem might persist with newer versions of the kernel and I do not want to be stuck at this version and not get security updates.

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.