Mainline Linux/Debian for NanoPi R5S/C

General Discussion
44

Will the Dietpi images for the R5C moving forward include the Kernel in this image (6.1.0-10-arm64) or will it continue to be the existing 5.10.160 ?

45

@innovodev The issue is that mainline doesn’t have all the features that the SoC supports. At least in mainline 6.1. DietPi currently just replaces the rootfs from the vendor image so they could upgrade to the new vendor kernel which is also based on 6.1 but the main goal I’ve read here multiple times is that it should be based on an Armbian image which currently is very much in development (there’s been commits this week) but is close to being done.

Until then there’s this amazing project called “debian-image-builder” from pyavitz on GitHub that would allow you to compile/build your own minimal image (very easily) on which you could run the DietPi script on.

1 Like
46

Thank you for the explanation. I am not a kernel build guy, otherwise I would have jumped right in. Hopefully the Armbian branch will be finished soon and merged into the DietPi Image (I do love DietPi ecosystem, they have spoiled us with great software:).

47

Armbian released a version for R5S with kernel 6.5, but it is still staging:

This version works also on my R5C, with small defects like network leds not working.
This version creates a single partition, instead of the 8 partitions system of Friendly Elec

1 Like
48

I assume there won’t be an easy way to update from vendor to Armbian base in a running DietPi instance while keeping the rootfs?

Since Rockchip uses a proprietary partition scheme in their kernel/uboot or would it work since updating would override anything vendor related?

@MichaIng what do you think?

49

On this version, I find the classical problem : a module I want to build does not build. Reason ?
apt says :
Coundn’t find any package by glob ‘linux-headers-6.5.3-edge-odroid’
And make creates an error because “build” directory is not found.

50

If I remember correctly they based a lot around the odroid and I’d assume somewhere they haven’t renamed it to the R5S / published the packages. Maybe open an issue in their GitHub/forum

51

Just following up on this board. Seems that there is a community build for the R5C (the picture shows the R5S, but the build is for the R5C, the R5S has it’s own build page). Will the Dietpi image be updated to use it?

52

It has been already. Our current R5S/R5C images ship with mainline kernel.

What is still missing is a migration for running DietPi systems. I did not find time to test and implement it, but it should be possible.

For reference, somehow CPU and RAM benchmarks are slower with mainline kernel, but probably acceptable and might become better with future kernel versions: NanoPi R5S/R5C and 6 series | Move to Armbian kernel and bootloader builds by MichaIng · Pull Request #6902 · MichaIng/DietPi · GitHub

53

Armbian meanwhile has Rockchip BSP 6.1 on their GitHub. It is actually based on mainline linux 6.1 and not some 2.x mess ported up. For full HW support (the reason I and probably many others in the first place considered and found DietPi) it would in my opinion still make more sense to go that route for anything that’s not RK3588.

54

The Rockchip kernel however is not that different from what we had before, which was Rockchip 5.10 BSP. Of course configurable with boot config/scripts in /boot.

So unless there is significant downsides of mainline kernel, I’d stick with that. The Rockchip kernel should be btw easily installable via:

apt install linux-{image,dtb}-rk35xx-legacy

But I am not entirely sure whether it works, since Armbian does not have the option to install that one in their build system, only mainline LTS “current” and latest “edge” for rockchip64 family. This has been changed a while ago for all RK356x boards.

I would actually, and we do use this Rockchip BSP based kernel for RK3588 boards, since those seem currently much worse supported by mainline kernel, at least in LTS. But I actually did not find the time to just test it.

EDIT: Ah, now I see the difference between legacy 5.10 and “vendor” 6.1, okay I was not aware of this. Not sure why they did not just update “legacy” instead? rk35xx/rockchip-rk3588: vendor: the unthinkable! add `vendor` branch for new 6.1-rkr1 BSP vendor kernel, and keep `legacy` for the 5.10-rkr6 BSP vendor kernel by rpardini · Pull Request #6356 · armbian/build · GitHub
That seems reasonable for our RK3588 images. We can build and host that kernel on our server. But still not sure whether it will work on RK356x, at least Armbian added this “vendor” target to RK3588 SBCs only.

55

Vendor 6.1 differs in the point that it’s not too hacky and because some legacy SoC‘s aren’t supported by it. Anything RK 35XX and above definitely works. Soon mainline mesa (which is backported to Vendor 6.1, being tested right now) also will replace Panfork since Panthor for G610 (RK3588) is now released and mainline (from 6.9/6.10 per Collabora Blog). That will also result in better support for Mali Bifrost from RK356X

56

If you ask me DietPi‘s main attractiveness comes from it being lean but also the full support from BSP. If anyone wants to run mainline on any of the current RK boards there are more than enough projects and images available and those can be turned into dietpi with the script in a pinch

57

We actually try to use mainline kernel where possible :smile:. Most vendors provide their own Debian images based on Rockchip BSP 6.1, so that is not hard to get either.

The question really is whether there are significant benefits of the Rockchip BSP on RK356x, with typical DietPi setups. If not, I’d prefer to not use and indirectly promote it. It would be much better if Rockchip contributed to mainline kernel right from the start, instead of maintaining their own always outdated fork. StarFive shows well how this can work for a chip manufacturer, if they want it.

58

If you need someone to test it, I am more than happy to do it. As always thanks for your prompt responses.

59

We have problems with the WiFi on the R5C.
On a cold start, the WiFI is not found in lspci
After a reboot, it is found and works normally.

I am not testing on a just installed Dietpi but with all our software installed.
Have you an idea which could help debugging this problem ?

I found the error in syslog :

DietPi kernel: [ 1.028652] pci_bus 0000:01: busn_res: can not insert [bus 01-ff] under [bus 00-0f] (conflicts with (null) [bus 00-0f])

But I do not know what to do with it !

60

Update : this line is not the reason of the problem, because after reboot, when initialization is OK, it is present, also. I attach the logs of successful and failed start of the WiFi.
syslog-failed.log (136,3 Ko)
syslog-good.log (120,6 Ko)
WiFi-lspci.txt (601 Octets)

61

I confirm I have the same error at cold start. syslog gives the same error than Averell7.
I tried to run a pci rescan without success : echo 1 > /sys/bus/pci/rescan
It returns rtw_8822ce error beacon valid.

I think I am not deep enough in the rescan.

However, if I reboot, the bus connects and it works perfectly.

In the “good” syslog, I see this main difference right after kernel: [ 1.128824] pci_bus 0000:01: busn_res: can not insert [bus 01-ff] under [bus 00-0f] (conflicts with (null) [bus 00-0f]):

kernel: [    1.129039] pci 0000:01:00.0: [10ec:c822] type 00 class 0x028000
kernel: [    1.129169] pci 0000:01:00.0: reg 0x10: initial BAR value 0x00000000 invalid
kernel: [    1.129199] pci 0000:01:00.0: reg 0x10: [io  size 0x0100]
kernel: [    1.129341] pci 0000:01:00.0: reg 0x18: [mem 0x00000000-0x0000ffff 64bit]
kernel: [    1.129990] pci 0000:01:00.0: supports D1 D2
kernel: [    1.130018] pci 0000:01:00.0: PME# supported from D0 D1 D2 D3hot D3cold
kernel: [    1.140341] pci 0000:00:00.0: BAR 14: assigned [mem 0xf4200000-0xf42fffff]
kernel: [    1.140407] pci 0000:00:00.0: BAR 6: assigned [mem 0xf4300000-0xf430ffff pref]
kernel: [    1.140444] pci 0000:00:00.0: BAR 13: assigned [io  0x1000-0x1fff]
kernel: [    1.140484] pci 0000:01:00.0: BAR 2: assigned [mem 0xf4200000-0xf420ffff 64bit]
kernel: [    1.140582] pci 0000:01:00.0: BAR 0: assigned [io  0x1000-0x10ff]

Edit: It could be linked to isc-dhcp-client according to french people in another forum. I tried to uninstall it, I coldstarted again, no success. However, the startup is much quicker.

62

Hi again,
Doing a rescan after boot allows to see the hardware with lspci command but I didn’t manage to start wlan0 interface after that.
echo 1 > /sys/devices/platform/3c0000000.pcie/pci0000:00/pci_bus/0000:00/rescan

I tried to put it in boot sequence but it is always too late compared to interfaces init.
Does anyone has a clue? The only way I currently found is to reboot after a cold boot which is not really suitable.
Thank you for your help if you can.

63

@Krophil
I am currently investigating this due to another report. Can you test whether this kernel and bootloader changes something?

cd /tmp
wget https://dietpi.com/downloads/binaries/testing/linux-{image,dtb}-current-rockchip64.deb
wget https://dietpi.com/downloads/binaries/testing/linux-u-boot-nanopi-r5c-current.deb
dpkg -i linux-{image,dtb}-current-rockchip64.deb linux-u-boot-nanopi-r5c-current.deb
source /usr/lib/u-boot/platform_install.sh
write_uboot_platform "$DIR" "$(lsblk -npo PKNAME "$G_ROOTFS_DEV")"
reboot

It seems like the PCI BAR address errors are unrelated to the issue. We had those in reboots (after which the WiFi module works) as well as on cold boots, leading to some other differences in logs. So far I think the relevant logs start with rtw_8822ce error beacon valid, followed by firmware downloads, same as reported here:

Further ideas I have is to remove a patch which could be related: PCIe width only x1 for a x4 card - Pine RockPro64 - Armbian Community Forums
And a Linux 6.8 based build, which is currently running: Armbian · MichaIng/DietPi@e4c2818 · GitHub