forumtrekker

Did a fresh install of community Armbian desktop this time, running current 6.12.60 from here. It seems there is no need to compile from scratch if you are using the panel-mipi driver from kungfupanda, I copied my DTS, panel-mipi.bin, etc. from my edge custom compiled installation to the community one and it worked fine after repeating the initramfs process, but I still get a stuck display after a bit, this time on the Armbian loading screen. SSH and Serial console work fine, its just the system stops knowing how to use the display after the initial boot sequence is done, and the kernel hands off the display to X11 / Wayland? This is consistent with how I believe tinydrm works, which is storing the image in memory and displaying new ones from memory if given (which in this case, none are given after a certain stage in the boot process and this hand off to the window manager never happens.) Need to figure out how to tell the system to keep using the drm display. I already tried putting /dev/dri/card0 instead of /dev/fb0 in 99-fbdev.conf, and I've been trying the following extraarg in /boot/armbianEnv.txt to try and get it to work. Screen still pauses halfway through boot messages / loading screen. extraargs=video=SPI-1:480x320@30

I got the display to work! I left out a phandle = <0x01> line in my ili9486@0 section, adding it made it work. DTS was fine otherwise. It's a little glitchy and laggy so I need to tinker with it more, but I see plymouth displaying properly! I can't seem to get into tty or XFCE, but I believe I'm not running wayland and it sounds like thats a requirement for tinydrm? I'll figure it out, but the hard part is over. Once I get everything polished I'll write a summary of my steps so its easy for others to follow. Working DTS for the red ili9488 display using tinydrm driver: Edit: Removing XFCE & plymouth seems to break things, display is pure white again. It also rearranges /sys/class/drm to be card1-SPI-1 instead of card0-SPI-1. Adding this line to /boot/armbianEnv.txt results in the blue and black stripes again, instead of a white screen, but prevents the screen from working with plymouth or XFCE. extras="fbcon=map:0" Reinstalling plymouth and XFCE reverts this white screen and shows boot messages again but no tty console, only if there is no fbcon line at all. Installing just plymouth and not XFCE shows boot messages only if fbcon=map:1 is set, note the 1 instead of 0. Still no tty. The last boot message is and the one after (which I see on serial console) is this, so maybe plymouth finishes writing boot messages to display and the system just never accesses it again? Maybe I need xorg to access /dev/dri/card0 instead of /dev/fb0, since it is not a fbtft device but a DRM one? [ OK ] Finished plymout… Write Out Runtime Data.

My latest post on page two shows the waveshare clone LCD DTS, working under FBTFT not DRM. The gpio formatting is strange, but it is what I lifted from Radxa provided DTS for a different waveshare LCD that I'm adapting for the displays here. This DTS I have is functional, and I'm certain the pins are correct as the Red ili9488 display shows purple / blue lines using FBTFT (probably incorrect init sequence, since it shows purple and red using your FBTFT init sequence under ili9341 driver instead of ili9486. fb_ili9486 does not work as you also experienced), and the Blue waveshare clone display works perfectly. Current working red DTS: Current working waveshare fbtft, laggy (waveshare LCD is a parallel display with shift register hacks and kind of bad, so lag is expected.) Haven't tried DMA or fbcp since fbtft is outdated anyway. I've commented what each line / hexadecimal represents, to make it easy to follow. I spent several weeks trying variations of the DTS you provided, and I was never able to get it to work properly. I only got positive results when I started using the formatting I am now. The formatting is semi-understandable, every gpio and spi is just referenced at the end of the file by line name and position in increases of 4 (0 refers to the first item in a line, 4 to the second, 8 to the third etc), instead of being directly called in their location. For example, the target of fragment0 is 0xfffffff, which at the bottom of the DTS in the fixups section, is referred to as spi1. The cs-gpios are referred to in fixups in both gpio4 and gpio1. I am using latest armbian compiled per your instructions / forum posts, running edge compiled armbian with kernel 6.18.0-rc6, with panel-mipi selected at kernel build time according to the KungfuPancake github, firmware placed in lib/firmware, and drm verified to be loaded and semi functioning. I've essentially followed all your forum posts but have not had the success you have had. I'm now wondering if I have to tell armbian how to use the display with DRM, because I read somewhere that fbtft will draw constantly to your screen, but DRM will only draw when called and by default stays a white screen until called by the system. I tried adding a line in /boot/armbian.conf which should use the /dev/fb0 device as a display when /sys/class/drm/card1-spi is present (which it is), but it doesn't change anything. Edit: it seems adding this is not necessary if plymouth is installed. extras="fbcon=map:1" I appreciate your help! EDIT: I went through the first page of this thread again to check I haven't missed anything. since I've done multiple reinstall's etc... and realized after installing xfce this time, I didn't go through the updating of initramfs to ensure panel-mipi loads properly with plymouth installed. Panel-mipi seemed to still load fine and be present, but I went through the steps in your thread here and it fixed the following error I was having since installing XFCE, AND the screen is showing blue and black bars. The evidence seems to be pointing to the drm driver being initialized and used properly, so i'm going to make sure my gpio pin polarity is correct in my DTS since DRM expects flipped values in some cases compared to FBTFT, then I will check my wiring and shorten them in case it is physics / interference problem, and finally I'll try other init sequences from lcdwiki. [ 4.601941] panel-mipi-dbi-spi spi1.0: No config file found for compatible 'panel-mipi-dbi-spi' (error=-2)

I think I have a partial success but I'm struggling to get anything but white on the red display! Will update when I have more results. panel-mipi is loading, and Card-1-SPI appears under /sys/class/drm/ which is very promising. Verified that /lib/firmware/panel-mipi-dbi-spi is still present, still patched with Kungfupancake's init, and is loaded according to lsmod (as well as dmesg) My current DTS: Edit: I installed XFCE to test, and strangely this has caused dmesg to throw errors related to panel-mipi. I had these same errors when panel-mipi was missing from /lib/firmware but it is still present there.

Good to know. I'm interested in getting the red LCD's to work as they are cheaper and more available, I purchased the waveshare only to test my SPI, SBC, and DTS formatting were functional. Now that I confirmed how to translate DTS to work with my SBC, I can work on the red ili9486/8 without worrying about it being a formatting issue.

I went out and bought a waveshare clone 3.5 inch display, to try and confirm I haven't spent the last few weeks trying to do the impossible with broken GPIO pins or something - and got a partial success eventually, using fbtft, displaying basic console and plymouth boot logs. It has poor fps like you said - which I expected, its the reason I tried to use the tiny DRM driver from the beginning, but now I know the rockpi and DTS is functional. The same DTS also shows a broken, purple / blue output of bars on my red ili9488 display only if I adjust the bus width to 16 instead of 8 (0x10, instead of 0x08), otherwise it remains a blank white screen. A bus width of 18 and 24 also only gave me a white screen, so 16 might be correct. I've been unable to confirm touch works, since I only have a basic console and I can't figure out how to start LXDE on a framebuffer device, but I do see messages insinuating it initializes under dmesg | grep spi. I could probably just query the GPIO interrupt to find out if touch is working. Not that important right now. I did realize that the big "fixups" section at the bottom is clearly used to replace the empty 0xfffffff targets throughout. I'm unsure why the DTS was written this way, but it works so I am not going to touch it (changing the targets and switching from hex to decimal values broke the DTS for some reason.) Unfortunately, a simple drop in replacement of fb_ili9486 with panel_mipi_dbi did not make either display work, even with the added arguments you use in your latest DTS. Clearly I have much more work to do. BUT I've finally confirmed the DTS works, and all GPIO is claimed and SPI is initialized for both displays (even if the red LCD is showing gibberish), so now I need to nail down the subtle differences with the displays like the bus and reg width and find the right combo of spi clock speed, reg bus widths, and buffer length to get it all to work with fbtft (if only aliexpress sellers put up datasheets or example code!). Then I can follow the second half of your journey to hopefully translate a working fbtft setup to a panel_mipi_dbi setup. Maybe get backlight PWM working. All this still on edge kernel 6.18, on a rockpi 4b plus.

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.

Hello! First of all, thank you robertoj for this treasure trove of information - truly, I searched so much of the internet before finding this, because seemingly nobody is sharing DTS files for tft screens at all that aren't on a raspberry pi (which uses a different system afaik). I am using a rockpi 4bplus, trying to get an ili9488/86 tft screen to work, and struggling. I've used your latest DTS from page 1, using panel-mipi, verified it loads into initramfs using your other threads, compiled my own armbian edge on kernel 6.18 (and tried on kernel 6.12), corrected all FDT err not found errors on the DTS for my use case (my gpio numbers were out of scope)... still, all I get on my display is a blank white screen with no dmesg errors or comments about spi, panel etc... ;-; Not sure what else to try at this point. I'll post my files below, along with translated gpio pin numbers: /dts-v1/; /plugin/; /{ compatible = "radxa,rockpi4b-plus", "radxa,rockpi4", "rockchip,rk3399"; fragment@0 { target = <&spi1>; __overlay__ { #address-cells = <1>; #size-cells = <0>; pinctrl-names = "default"; /* new for linux 6.13 */ pinctrl-0 = <&spi1_clk &spi1_cs0 &spi1_rx &spi1_tx>; /* new for linux 6.13 */ cs-gpios = <&spi1_cs0>, <&gpio4 26 0>; /* lcd, touch chip select */ panel: panel@0 { compatible = "panel-mipi-dbi-spi"; status = "okay"; reg = <0>; spi-max-frequency = <40000000>; width-mm=<84>; height-mm=<56>; reset-gpios = <&gpio4 29 1>; /* taken from rock3c setup, then modified for armbian */ dc-gpios = <&gpio4 28 0>; /* 1 is low, 0 is high */ write-only; format = "b6x2g6x2r6x2"; panel-timing { hactive = <480>; vactive = <320>; hback-porch = <0>; vback-porch = <0>; clock-frequency = <0>; hfront-porch = <0>; hsync-len = <0>; vfront-porch = <0>; vsync-len = <0>; }; }; ads7846: ads7846@1 { compatible = "ti,ads7846"; reg = <1>; pinctrl-names = "default"; spi-max-frequency = <1000000>; interrupt-parent = <&gpio4>; interrupts = <21 2>; /* 2 is IRQ_TYPE_EDGE_FALLING pendown-gpio = <&gpio4 21 0>; /* same as interrupt, pulled high */ vcc-supply = <&vcc5v0_sys>; /* Fill in the voltage according to the actual power supply c> /* OPTIONS */ ti,x-min = /bits/ 16 <0>; ti,y-min = /bits/ 16 <0>; ti,x-max = /bits/ 16 <0XFFF>; ti,y-max = /bits/ 16 <0XFFF>; ti,pressure-min = /bits/ 16 <0>; ti,pressure-max = /bits/ 16 <0XFFF>; ti,x-plate-ohms = /bits/ 16 <400>; ti,swap-xy = <1>; }; }; }; };