NanoPC-T6 Image (Single Partition) Kernel Upgrade

belveder79 · 11 May 2024 17:42

the overlay loading works…

It actually worked nicely after some trial and error. First I compiled it into the kernel, then I left the kernel untouched and just provided the overlay. The results are the same looking at the log.

I can do the same (compile in or overlay) with my own version of the 5.10.160 kernel, the difference is just that it (rkisp, rkcif, mipi) works there, while it does not on the 6.1.43 armbian… it is not the overlay, it is either something I am missing or something broken in the 6 kernel…

MichaIng · 11 May 2024 17:54

Did you test FriendlyELEC’s Linux 6.1 sources? GitHub - friendlyarm/kernel-rockchip: BSP kernel source
They should be mostly the same compared to what Armbian uses, but just to rule it out. If it fails the same way with that one, you could ask at that repository or FriendlyELEC repo.

It is anyway a little too late now to push Linux 6.1 for RK3588 devices, so I’ll postpone that for next DietPi release, giving us time to debug. I’ll however add it to our repository (and the needed component to RK3588 boards), so users can easily switch, if wanted.

belveder79 · 11 May 2024 19:41

just tried and it also fails with the friendlyelec kernel… 6.1.57 even worse… same error messages… it seems that there is an issue with the 6 branch - will try to investigate and check back with friendlyelec folks… but for the time being, 5.10.160 is the one I have to use… btw, I never observed the switch ETH1 and ETH2 on 5.10.160 - only on 6.1.y

overlay_6.1.57_friendlyelec.log (194.5 KB)

MichaIng · 12 May 2024 15:28

Interesting. However, since we want to vendor kernel, let’s hardcode the names. Can you print the output of the following:

udevadm info -a /sys/class/net/eth0 | grep KERNELS
udevadm info -a /sys/class/net/eth1 | grep KERNELS

belveder79 · 12 May 2024 15:31

Sure… this is from the 6.1.43 kernel now…

root@DietPi:~# udevadm info -a /sys/class/net/eth0 | grep KERNELS
    KERNELS=="0002:21:00.0"
    KERNELS=="0002:20:00.0"
    KERNELS=="pci0002:20"
    KERNELS=="fe170000.pcie"
    KERNELS=="platform"

root@DietPi:~# udevadm info -a /sys/class/net/eth1 | grep KERNELS
    KERNELS=="0004:41:00.0"
    KERNELS=="0004:40:00.0"
    KERNELS=="pci0004:40"
    KERNELS=="fe190000.pcie"
    KERNELS=="platform"

belveder79 · 12 May 2024 16:16

btw, I just found that someone has the same problem concerning the cameras:

MichaIng · 12 May 2024 17:57

Please try this:

cat << '_EOF_' > /etc/udev/rules.d/99-dietpi-nanopct6.rules
SUBSYSTEM=="net", KERNEL=="eth0", KERNELS=="0004:41:00.0", RUN:="/bin/true"
SUBSYSTEM=="net", KERNEL=="eth1", KERNELS=="0002:21:00.0", NAME="to_eth0", RUN:="/bin/true"
SUBSYSTEM=="net", KERNEL=="to_eth0", RUN="/bin/ip l s dev eth0 name eth1", RUN+="/bin/ip l s dev to_eth0 name eth0", RUN+="/bin/udevadm trigger -c add /sys/class/net/eth0 /sys/class/net/eth1"
_EOF_

It is a little hacky solution, but works well here with respective “KERNELS” matches on Orange Pi 5 Plus: Orange Pi 5 Plus | Network interface names can swap on reboot · Issue #6592 · MichaIng/DietPi · GitHub

belveder79 · 14 May 2024 06:11

Thx for taking care of this.

I applied the rules but I can’t really verify yet if it solves the problem… I will do a mass deployment on a multitude of NanoPC-T6 in about 2 weeks from now, so I can tell more about it afterwards… will let you know asap…

PS: I went back to my own kernel for now based on friendlyarm kernel 5.10.160, the nanopi5-v5.10.y_opt branch without overlays… camera stuff seems to work there

belveder79 · 3 June 2024 20:46

So today I tried deploying the image to a set of NanoPCs but I encountered an entirely different problem - the mac address of the interfaces is ALWAYS the same… then I stumbled upon your previous discussion

github.com/MichaIng/DietPi

NanoPi 5/6 | Set/change MAC address persistently

opened 02:01AM - 21 Aug 23 UTC

owendelong

Question

NanoPi R5S/R5C NanoPi 6 series

### Creating a feature request #### Is your feature request related to a prob…lem? Please describe: I often find it useful to get a system very close to what I want on multiple systems and then use dd to clone the entire drive, then change a few settings like IP Addresses, Hostname, etc. (personality files as it were) to make a new system with similar functionality. On DietPI (at least on NanoPi R6S and I admit it's hard for me to know whether this is hardware or software-related), this results in the MAC address(es) coming along for the ride (which is not desired). Booting a clean NanoPI installer allows me to see the original MAC address, but there's no documented way to stop the device from booting with the cloned address(es) (which is problematic in a number of ways). #### Describe the solution you'd like: Clear documentation of where and how the persistent MAC addresses for the interfaces are stored. A utility for restoring them to the hardware original addresses would be a bonus (for systems that have burned in addresses). #### Describe alternatives you've considered: I've tried multiple techniques to search the filesystem for the address without any luck. #### Additional context This particular set of NanoPI R6S units are being used as routers with two tagged (multiple VLAN) interfaces (internal LANs, Guest/DMZ LANs) and one external interface. Having duplicate MAC addresses hitting the ISP's upstream router for DHCP creates all kinds of (not) fun.

I used a newer Armbian build (your image from today) and the mac address is totally random sometimes after rebooting. I will try to use your previous hacky fix you posted, and will try to move on from there…

belveder79 · 25 September 2025 18:51

I’ll give it a try now again, say 15 months later…

@MichaIng can you please tell me from which repo the current kernel on Trixie is built?

it should be this one

vmlinuz-6.1.115-vendor-rk35xx

but I was not able to find the right git repo or tag. Is it from here

or here

or which one? Thx…

MichaIng · 25 September 2025 21:38

It is the Armbian repo you linked, with the default branch. We enabled static MAC addresses for NanoPi R4/R5/R6 variants in the meantime:

github.com/MichaIng/DietPi

NanoPi 5/6 | Set/change MAC address persistently

opened 02:01AM - 21 Aug 23 UTC

closed 07:45PM - 22 Jun 25 UTC

owendelong

Question

Solution available

Kernel related

NanoPi R5S/R5C NanoPi 6 series Bootloader related

### Creating a feature request #### Is your feature request related to a prob…lem? Please describe: I often find it useful to get a system very close to what I want on multiple systems and then use dd to clone the entire drive, then change a few settings like IP Addresses, Hostname, etc. (personality files as it were) to make a new system with similar functionality. On DietPI (at least on NanoPi R6S and I admit it's hard for me to know whether this is hardware or software-related), this results in the MAC address(es) coming along for the ride (which is not desired). Booting a clean NanoPI installer allows me to see the original MAC address, but there's no documented way to stop the device from booting with the cloned address(es) (which is problematic in a number of ways). #### Describe the solution you'd like: Clear documentation of where and how the persistent MAC addresses for the interfaces are stored. A utility for restoring them to the hardware original addresses would be a bonus (for systems that have burned in addresses). #### Describe alternatives you've considered: I've tried multiple techniques to search the filesystem for the address without any luck. #### Additional context This particular set of NanoPI R6S units are being used as routers with two tagged (multiple VLAN) interfaces (internal LANs, Guest/DMZ LANs) and one external interface. Having duplicate MAC addresses hitting the ISP's upstream router for DHCP creates all kinds of (not) fun.

If needed, we can do the same for NanoPC T6, but I do not own the board to test it.

belveder79 · 26 September 2025 14:04

Thx, got it to compile…

same story… 6.1.115 still has the same flaws as 6.1.45 and 6.1.99… means camera and rkisp usage is still limited to 5.10.X kernel…

MichaIng · 26 September 2025 14:51

Are the related kernel modules loaded? There should be a rockchip-isp one if I am not mistaken.
EDIT: Ah nope it has a different name. Maybe the Panthor driver causes issues in this context .

Should be even in the mainline kernel:

github.com/armbian/build

feat: enable rkisp module for rockchip64

main ← russkel:rkisp-module-enable

opened 04:21AM - 02 Sep 23 UTC

russkel

+5 -1

# Description Enable rockchip `rkisp` module for rockchip64 boards in edge. T…here has been driver support upstreamed into the kernel but it is not compiled for the `rockchip64` kernels. https://docs.kernel.org/admin-guide/media/rkisp1.html # How Has This Been Tested? Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration. - [x] Compiled edge 6.4.12 on rockpi 4c with modules enabled and it boots. Modules have not been enabled in device trees yet (I haven't done the work yet but hope to PR these) # Checklist: - [x] My code follows the style guidelines of this project - [x] I have performed a self-review of my own code - [x] I have commented my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [x] My changes generate no new warnings - [x] Any dependent changes have been merged and published in downstream modules

belveder79 · 27 September 2025 18:21

The armbian kernel rk-6.1-rkr5.1 is still broken - that’s it. works nicely with vendor 6.x kernel…

MichaIng · 28 September 2025 01:11

Hmm, that should be moreless the same kernel, both based on Rockchip Linux sources. Though Armbian is using a patched one from Radxa, which might differ in some FriendlyELEC board device trees or config or some patches from FriendlyELEC. We can try to compare these: GitHub - friendlyarm/kernel-rockchip: BSP kernel source