Architecture | Linux DietPi 5.10.160-legacy-rk35xx #1 SMP Fri Feb 2 07:51:33 UTC 2024 aarch64 GNU/Linux
SBC model | NanoPi 6 series (aarch64)
Power supply used | 12V/2A
SD card used | Sandisk Ultra 8GB
Steps to reproduce
I’m trying to replace the Kernel with my own build, which I did in the past when the partition layout was Android-like (separate boot/kernel partition to enclose the img files). I’m building my kernel as described on the NanoPC-T6 page (as I always did) with the 5.10.16 kernel branch. This actually gives me the same kernel version (legacy) as it is installed right now.
I follow the steps in 12.4.2 Build kernel linux-v6.1.y to build the nanopi6-images and then I can flash the kernel.img and the boot.img to the Android layout - boot, works.
Tried to update the uImage and other stuff on the boot directory on the single-partition layout - fails miserably, does not boot any more. I included the custom modules build, but not the dts (those I took from the legacy for now.
Also tried to create bindeb-pkg to have debian packages (image,headers,libc) - no luck either.
Expected behaviour
I would expect that replacing the uInitrd-*, the vmlinuz-* and the System.map should actually do the trick, but does not.
Is there a known procedure to update the kernel for the NanoPC-T6 with the new single-partition layout?
rebooted, works. Need to check if overlays of dtbs also works…
PS:
So this also does not work - there is something missing. For some reason if I just did a soft “reboot” it worked, but after pulling the plug and restarting it cold, it did not work again…
rockchip$ file vmlinuz-5.10.160-legacy-rk35xx
vmlinuz-5.10.160-legacy-rk35xx: MS-DOS executable PE32+ executable (EFI application) Aarch64 (stripped to external PDB), for MS Windows
EDIT: Ah wait, for the single-partition layout? You do have an image with a single partition already, don’t you? Else uname -a should not contain 5.10.160-legacy-rk35xx, or am I missing something? Below works on an image with linux-image-legacy-rk35xx package on single-partition image. For migration on old older images with 8 partitions, I need time for testing.
Here is a simpler solution, as we have packages for Linux 6.1 already, which work well on Orange Pi 5, but needs testing on NanoPi T6, to be sure:
cd /tmp
wget https://dietpi.com/downloads/binaries/testing/linux-{image,dtb}-vendor-rk35xx.deb
dpkg -i linux-{image,dtb}-vendor-rk35xx.deb
reboot
Well, I’m booting off the SDCard right now with a single partition, yes, but I want to move to EMMC (single partition also) once I have a working version.
I don’t necessarily need a version 6 kernel, I need to patch the devicetree for some devices attached. That’s why I need to run through the steps all one by one…
Can you provide the instructions to build the debian packages?
Isn’t it possible to apply your device tree changes via overlay(s)? So it can survive kernel package upgrades.
If you find time to test the Linux 6.1 build, that would be great. I want to move all RK3588 boards to this version, but the NanoPC T6 is the only relevant board I have not here to test myself .
That works without any issues on the NanoPC-T6, so you did a good job, as always
─────────────────────────────────────────────────────
DietPi v9.3.0 : 09:50 - Thu 05/09/24
─────────────────────────────────────────────────────
- Device model : NanoPi 6 series (aarch64)
- CPU temp : 31 °C / 87 °F : Cool runnings
- LAN IP : 192.168.0.218 (eth1)
- MOTD : Open Beta v9.4 | Please help testing our upcoming release:
https://github.com/MichaIng/DietPi/issues/7060
─────────────────────────────────────────────────────
DietPi Team : https://github.com/MichaIng/DietPi#the-dietpi-project-team
Patreon Legends : Chris Gelatt, ADSB.im
Website : https://dietpi.com/ | https://twitter.com/DietPi_
Contribute : https://dietpi.com/contribute.html
Web Hosting by : https://myvirtualserver.com
dietpi-launcher : All the DietPi programs in one place
dietpi-config : Feature rich configuration tool for your device
dietpi-software : Select optimised software for installation
htop : Resource monitor
cpu : Shows CPU information and stats
root@DietPi:~# uname -a
Linux DietPi 6.1.43-vendor-rk35xx #1 SMP Sat Apr 27 18:12:21 UTC 2024 aarch64 GNU/Linux
root@DietPi:~#
Yes, Overlay is one part of the story. This is a pain by its own, so I usually just include particular dtsi files in the original dts files and it is included automatically.
The other issue is drivers. I need drivers for camera sensors, like OV4689 or OV9281, IMX214, IMX219 and so on… In the end I still need the entire kernel tree and then I can just resort to building the kernel myself.
PS:
So I tried to write an overlay, compile it within the armbian-kernel and copy it over to the board. Unfortunately it does not seem to get loaded (for whatever reason). I think I just have to put the name into the user_overlays= clause without the prefix, so rk3588-nanopi6-ov9281.dtbo becomes nanopi6-ov9281 but it does not get applied as it seems…
yes, I saw that everything should be there, thank you
My device tree overlay is simply not loaded, or it is loaded, but does not work which is more likely… I verified that the loading functionality through overlay-user actually works, so it has to do with my implementation.
I’ll probably try to just include the device tree like I did previously, and then gradually move to the overlay version.
One last question. The best way to move the 1-partition SD-card solution to the EMMC is simply to do a dd to a single partition on the EMMC, right? Again following merely this Blog, right?
Best is to flash a new image to the NVMe. Else yes, that blog post should work. Note that “partition” is not right here, since you dd the whole drive content, including partition table and all its partitions (which is a single only, yes. You dd/dev/mmcblk0 (the drive itself), not /dev/mmcblk0p1 (the first partition), which would not result in a bootable image.
just including the devicetree file in the dtb compilation works, but the overlay does not… tricky…
There is one more thing I noticed. The NanoPC-T6 has 2 Ethernet ports and usually the ETH1 is the working one… however, sometimes it seems the ports switch roles… then ETH2 works as if it was ETH1 with the same MAC address… that’s very weird… ever read something like that?
Same happens on Orange Pi 5 Plus. I’ll implement udev rules to hardcode the interface names, but I need some device identifier to match them. I’ll check back with the commands to list device identifiers, something with the udevadm tool.
Is there any easy way to check the messages when loading the device tree overlay? There is a serial interface on the Debug UART enabled which should show any error messages before booting, right?
Yes, attaching a USB-UART adapter and serial console should show bootloader/U-Boot logs, including failures up to the point where the kernel was loaded, and login prompt (on successful boot). Kernel logs themselves are done on HDMI (/dev/tty1) by default. One would need to switch the two console devices in /boot/dietpiEnv.txt kernel command-line arguments to have kernel and init/systemd logs as well on the serial console: the last console= argument is used for this.
Works nicely, but does not help in the end unfortunately. It seems I have to stick to the rockchip kernel for the time being. There is something weird happening to the mipi and rkisp stuff…
Tried asking for help on friendlyelec discord, but no luck so far…
Well, it seems that the rkisp and mipi things are messed up in the 6.1 kernel. I can‘t really tell what is wrong… if you compare the two log files there are no errors in the 5.10 version, but in the 6 version it starts with the „subdev not found“ errors and in the end the rkisp mainpath does not give images… the rkaiq server also fails…
7.247712] rkisp_hw fdcb0000.rkisp: Missing rockchip,grf property
[ 7.249179] rkisp_hw fdcb0000.rkisp: max input:0x0@0fps
[ 7.250748] rkisp_hw fdcb0000.rkisp: no find phandle sram
And goes on when it comes to rkcif… actually I think that is the problem…
I thought the overlay method does not work in general? Did you check whether the overlay was actually applied or failed? In case of any overlay failure, our /boot/boot.scr applies again the default device tree.
.
