I am glad that you have the first 15% done: get your kernel module in the OS, and the uboot accepting the DTBO Now you are stuck in correcting the DTS, so that it configures the SPI pins correctly. My last advice for you (through this stage) is: make sure you don't have anything else using SPI pins. Deactivate "spi_dev" in armbian-config. Since I only had experience with H3 and H618 CPUs, I can't help with confidence. Post your question in the appropriate Rockchip forum section for up-to-date reliable advice. I can say that Radxa/Waveshare DTS is very out of date: it uses the fb_ili9486, which is "framebuffer" (poor fps), instead of the modern "DRM" display driver (high fps, will allow wayland). You should stay with that DTS with fb_ili9486, because it is still the closest starting point for you, and when you have it working, claiming all the GPIO pins needed, I can help again to use the DRM driver panel-mipi-dbi. Regarding MISO and MOSI, I only meant to change that nomenclature in the graphic that you show in the forum. I did't mean to change it in the DTS, if that's how other people make it work. Maybe you need to have the full linux source, so you can decompile the DTBO correctly, showing the gpio pin addresses or symbols. Is it possible that you get the Radxa/Waveshare original DTS?

@laibsch: Thanks, but your objections are worthless. You have zero sense of humor, son. @esalarm: As a Debian user since 1997 I did an aptitude purge between trying daemons. I can not make any of them set the time, as they usually do in normal Debian. There is something missing in the most current stable Armbian. I wish you would try it on an N2+. I am happy to use chrony, as I have for several years, although in this case it has no effect. But the new Debians seem to be moving to systemd for everything such as this, so I adapted. But that didn't work either. I can't be the only one; maybe the first?

Thanks @dale I'll test it out on my box first and add it later on today.

Thanks for the reply! I'll address everything one by one: I am using the generic red ili9488 3.5inch TFT available everywhere, in this case at this link. I also have a generic red ili9341 2.4 inch TFT I purchased years ago to also test with. Neither seem to work with the DTS. It is definitely not the blue 3.5 inch waveshare screen which looks significantly different. Yes, uboot messages through serial console confirm my dtbo is found and applied without errors. No FDT errors. Applying user provided DT overlay spi1-correctedgpio.dtbo panel-mipi-dbi.ko exists in /lib/modules on the custom compiled armbian running kernel 6.18, but not on the unmodified armbian provided image running kernel 6.12. When building armbian for panel-mipi I confirmed it was selected and it was marked "M" according to the github instructions. Here's the interesting one - basically every GPIO is unclaimed including the ones I have hooked up for the display when doing Here's the link to the rock3c DTS I'm referencing. The Rock 3 pins are named very differently so I translated as best as I could to my rock 4, but I believe they are correct as I found that Radxa distributes a waveshare clone DTS for the rock pi 4 and the pins are named as I have named them. I've pasted the waveshare clone DTS distributed by Radxa below for reference. Using MOSI and MISO do not work, and according to the waveshare DTS I should be using spi_tx and spi_rx. Will continue trying MISO and MOSI in future edits though as it doesn't hurt. You mentioning the waveshare display made me look into the DTBO distributed by radxa OS, I copied it to armbian and tried using it with the red display, and while it expectedly does not work, the pins I expect show up EXCEPT for touch IRQ, which is still unclaimed. I labelled touch, DC/RS, and reset pins for ease of reading in parenthesis. This makes me think I might have success formatting your ili9486 DTS to be similar with the waveshare DTS to get panel-mipi-dbi working on my red LCD. I get dmesg messages so its definitely closer. Here's the full waveshare DTS, note because I decompiled the DTBO with the dtc command, it looks like it lost the target pointers so I'm unsure (but can guess) what they point to. The GPIO pins are also lost but I know what pins they refer to as their pin number is in hex and I can narrow them down to the only pins available according to the pinout diagram. This doesn't affect the DTBO function as I paste the DTBO directly without decompiling, so in theory that should be unchanged and fully functional. At the very least, it claims the GPIO correctly.

@thanh_tan You found one armbian image to boot on Orangepi4A?