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…
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.
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
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_
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
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
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…