Ryzer

Hi robertoj, This would most like be set somewhere within the SPI controller driver. I tried that in my other post with not much success but I will try to give it another shot. maybe you could try reversing the min and max values best of luck Ryzer

Hi robertoj, There are addtional touchscreen parameters that you could try to address the cursor movement being wrong. based on what you have said I would suggest adding the line 'ti,swap-xy = <1>;' to: ads7846: ads7846@1 { reg = <1>; /* Chip Select 1 */ compatible = "ti,ads7846"; spi-max-frequency = <1000000>; status = "okay"; pinctrl-names ="default"; pinctrl-0 = <&ads7846_pins>; interrupt-parent = <&pio>; interrupts = <0 7 2>; /* PA7 IRQ_TYPE_EDGE_FALLING */ pendown-gpio = <&pio 0 7 1>; /* PA7 */ /* driver defaults, optional*/ 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 <0xFFFF>; ti,x-plate-ohms = /bits/ 16 <400>; }; In regards to the crashing that, will be a bit harder to pin down. Thinking about I would suggest double checking 'interrupts = <0 7 2>;' as I would have expected it to be something like 'interrupts = <0 7 IRQ_TYPE_EDGE_FALLING>. That said, it does appear to be registering correctly when looking here: Does /proc/interrupts list the gpio as being set to trigger on falling edge as expected? 24MHz is the maximum speed that the ili9341 will work at in spi mode. It may be possible that there indeed problems with the driver but without investigating deeper its hard to say. Raspberry Pi have there own distinct linux kernel fork so the problems mentioned may not be common to the mainline kernel used by Armbian. I wonder if the crashes are possibly caused by the cs lines of both devices being pulled low at the same time under certain conditions. best of luck Ryzer

Hi robertoj, I can see some lines that look problematic. Firstly you are defining cs-gpio twice. Once here: Note - Remember that 0 refers to the native cs line (PC3) Here the pinctrl references are wrong. I am not sure how strictly the ordering matters but for clarity 'pinctrl-names' should be before the actual pin control nodes. Adding spi-add-cs1.dtbo is not needed as all it does it defined the pins to use as cs lines which you have already done above anyway. My other suggestion would be to look into what the latest bindings should for the ads7846 touch controller. Let me know how you get on with following overlay: best of luck Ryzer

Hi Usual user, Please find attached the dts sources copied from cache/sources/linux-kernel-worktree/6.6__sunxi_armhf/arch/arm/boot/dts/allwinner sun4i-a10.dtsi sun4i-a10-pcduino.dts sun4i-a10-pcduino2.dts The most recent version of the spi-ili9341-tft.dts overlay can be found here: https://github.com/Ryzer58/sunxi-DT-overlays/blob/master/examples/spi-ili9341-tft.dts cheers Ryzer

Hi Robertoj, That was due to a little mixup in the overlays used with similiar names of spi-ili9341-tft and spi-tft-ili9341.dts. When working with spi-ili9341-tft.dts I assumed it was correct and working but I when I double checked the environment file on the 5.15.88 kernel the working overlay I was using was spi-tft-ili9341.dts. I cant remember what exactly the issue was as intially spi-ili9341-tft.dts did not work when compiled under 5.15.88. I have since recompiled it and it now does indeed work mostly, the only bit I need to address is getting the backlight to come on automatically which it does on spi-tft-ili9341.dts but not on spi-ili9341-tft.dts. I should have remember from before that the reset pin is not strictly necessary and in my case the reset pin aligns with the board reset pin. One other thing I have to be careful of is the connections do not appear to be great so if I accidently knock the screen it goes white then I have to reboot to get the display back.

Hi usual user, Ok I have updated to the latest version of libgpiod so now I can run gpioset -c0 34=on. This is the result:

Hi robertoj Glad you found a solution that works. Just be mindful that the fb tft based drivers such as fb_ili9341 are no longer actively maintained and likely to be removed in future. I dont know the full details but just a brief overview of things are supposed to work. The underlying spi hardware will always be controlled by the spi controller driver as defined in the main SOC dtsi file which then exchanges information with the display driver at the other end which in our case is the ili9341. drm_mipi_dbi is a dependance of the ili9341. Again I dont know its exact function but I imagine its something to do with configure the resoution of the display as it can also be used to define a custom display as well. Looking at spi-max-frequency this appears to be set to high, it should be no greater than 24MHz. Getting h264 may be possible but it depends on the display data from the display engine being able to be sent spi controller. It should be but you will need to check in and figure out which input device relates to the ADS7846 touch controller. All the best Ryzer

Hi usual user, I will admit that is a bit strange. gpiochip1 is the mapping for the IO on axp209 pmic. For some reason it is assigned a different base under kernel 6.6. if we look at gpio via the sysfs approuch this is more clearer to see. Another issue is that neither is 100% accurate as some listed gpio lines do not actually exist as there is not a single port that is associated with 32 pins. https://linux-sunxi.org/A20/PIO That said if the mapping was incorrect then surely the dc pin and backlight pins woud not be correct either. Kernel 5.15.88 Kernel 6.6: Are you sure this is right as it returns an error and gpioset -h does not list a -c option

Hi usual user, I have attempted your suggestion but to no avail unfortunately. I did a bit of digging into previous commits to armbian build and found an interesting patch for the 5.15 kernel series:drv-spi-spi.c-fix-cs_gpio-spi-support.patch This like a promising place to start from. Unfortunately I no longer have a copy of the kernel source code specificly for 5.15.88. and only managed to find 5.15.165 listed on kernel.org. I guess I’ll need to closely examine spi.c under kernel 6.6 to figure out how it now handles GPIO-based chip selects. Just to confirm all the builds where current when they where created. The only additional alterations that I had to do was a patch to enable hdmi support and adjust the perf unit IRQ number so that it does not conflict with a serial port.

Hi usual user, which location do I source the old dtb from as there is a pcduino2.dtb at /boot/dtb/ as well as /boot/dtb-5.15.88. So far I have tried with fetching the spi-ili9341-tft.dtbo from the prevous build to no avail. As another test I have tried using the spi-gpio module in place of spi-sun4i but have been unable to get that to work at all. Do you have an A20 based board that you are able to test with the current kernel? If anyone else is experiencing the same issue it would be good to know.

Hi robertoj, Before you revert to an old image I would suggest one last thing. If the screen is grey then that is progress, xserver just has to be configured to use it. I encountered the exact same problem when trying to the display module working with the Raspberry PI as alternative option. Then I remembered that we need to create a configuration file. It needs to be saved to "/etc/X11/xorg.conf.d/". Call it something like 99-fbdev.conf and write the following: Section "Device" Identifier "myfb" Driver "fbdev" Option "fbdev" "/dev/fb1" EndSection if you do 'sudo dmesg | grep drm' it will list all the display devices although we can also see the devices list in the xorg.log. [ 93.742] (II) Platform probe for /sys/devices/platform/display-engine/drm/card0 [ 93.743] (II) xfree86: Adding drm device (/dev/dri/card2) [ 93.743] (II) Platform probe for /sys/devices/platform/soc/1c40000.gpu/drm/card2 [ 93.745] (II) xfree86: Adding drm device (/dev/dri/card1) [ 93.745] (II) Platform probe for /sys/devices/platform/soc/1c69000.spi/spi_master/spi0/spi0.0/drm/card1 Even though it is not erroring, it is not finding a valid configuration so it switches back to the default display device which is normally the display engine. [ 93.745] (II) no primary bus or device found [ 93.745] falling back to /sys/devices/platform/display-engine/drm/card0 All the best Ryzer

Hi Usual user, Thanks for your suggestion but looking under "/sys/kernel/debug/gpio" provides similiar output. kernel 5.15.88: Kernel 6.6.16:

Hi robertoj, Glad you are making some progress. I know it says spi0.0 in the log but really it is still pointing to spi1. To get the id in software to match the physical id we have to explicity assign. This is not critical and does not impact on actual function but if you want to set it to match to avoid confusion, this can be done by adding the following fragment to the overlay: fragment@0 { target-path = "/aliases"; __overlay__ { spi1 = "/soc/spi@01c69000"; }; }; I see that the display is being mapped to /dev/fb1, from my experience it tends not to work unless mapped to /dev/fb0. You could try FRAMEBUFFER=/dev/fb1 and see if that triggers any sort of output. From what I tell can from the Sunxi wiki the Orange Pi Zero can provide composite ouput that appears to be enabled by default which would likely be mapped to /dev/fb0. Best of luck Ryzer

I have recently been trying to get my spi ili9341 working under kernel 6.6, having gotten it working previously. I checked to ensure there were no changes in the overlay required by the newer kernel. I confirmed that the pins were configured correctly and that the ILI9341 DRM module had loaded.. Despite this I was met with a white screen. Think I must have missed something I swapped out my SD card for another using an image based on kernel 5.15.88, where I was able to recieve a display. Looking back over the dmesg log, I noticed a slight difference in behaviour with the older kernel. firstly we can clearly see that the SPI driver is requesting to use gpio 34 as a chip select line compared to kernel 6.6. Secondly using gpioinfo to see which pins are currently set as output, to observe if gpio 34 has been set. A slight draw back with this approach is that it does not currently acknowledge when gpio are configured for spi. Kernel 5.15.88: Kernel 6.6.16: I later tried again but with my Pcduino3 using a more recent build based on kernel of 6.6.44 but achieved the same result. To confirm my theory that the problem lies somewhere within the chip select intialisation, I temporarily rerouted the pin used for the display to the Pcduino's native chip select pin (PI10) and recompiled the overlay to match. Now when I booted the pcduino I was met with a terminal window.

Hi robertoj, Looking at your overlay it looks almost there. The &spi0_pi_pins that I used will not work for the H3 as it has no port I exposed. Looking at pin controller section of the sunxi-h3-h5.dtsi spi0 only seems routed to one place so in this case you only need spi1_pins. please see here: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/boot/dts/allwinner/sunxi-h3-h5.dtsi?h=v6.6.47 If using the native chip select cs-gpios is not necessary unless you have a second chip select line that is normal gpio. Unfortunately it wont show under /dev/ however you can check if an spi bus is enabled by looking at /proc/device-tree/soc/spi@1c69000/status. Its odd that you dont have it by default, I thought both are still included at least in the current kernels. Best of luck Ryzer