Ryzer

Hi jimw, You are currently addressing the pin controller twice as it performs both pin control and gpio control operations. Try something like this which should work. The led node should make it visible in '/sys/class/leds' /dts-v1/; /plugin/; /{ compatible = "allwinner,sun7i-a20"; fragment@0 { target = <&pio>; __overlay__{ my_led_pin: my_led_pin { pins ="PH0"; function = "gpio_out"; }; }; }; fragment@1 { target-path = "/"; __overlay__ { leds: leds@0 { compatible = "gpio-leds"; pinctrl-names = "default"; pinctrl-0 = <&my_led_pin>; status = "okay"; led: led { label = "my_led"; gpios = <&pio 7 0 0>; default-on; }; }; }; }; }; note the pinctrl control reference '&pio' always take 3 arguments the first is the number of the port which starts with A=0 and goes to I=8. The second is the pin on that particular port and finally the pin state which can either be active high = 0 or active low = 1.

Hi Pet, The axp209 modules should already be loaded by default, if not then they should at least be included in the kernel. This is the pmic onboard the cubietruck. Are you using a lipo or coin cell for rtc? You can check the current state by look at '/sys/bus/i2c/devices/i2c-x/x-0034/battery. Replace x with the i2c bus that the axp209 is assigned to. Normally this should be 0 but not always the case. For example this it what it looks like on my device: [ 2.973703] axp20x-i2c 1-0034: AXP20x variant AXP209 found [ 2.981221] input: axp20x-pek as /devices/platform/soc/1c2ac00.i2c/i2c-1/1-0034/axp20x-pek/input/input0 [ 3.000378] axp20x-i2c 1-0034: Backup (RTC) battery charging is disabled [ 3.000562] axp20x-i2c 1-0034: AXP20X driver loaded [ 5.367992] axp20x-gpio axp20x-gpio: DMA mask not set [ 5.382424] axp20x-gpio axp20x-gpio: AXP209 pinctrl and GPIO driver loaded [ 21.124944] axp20x-adc axp20x-adc: DMA mask not set best of luck Ryzer

Hi Usual user, Thank you for your time I and patience. After a bit of recent testing I have found out that for a reason a have yet to figure out, that the sun4i-a10-pcduino.dtb is being loaded rather than the sun4i-a10-pcduino2.dtb as expected. For the time being I have renamed sun4i-a10-pcduino.dtb as sun4i-a10-pcduino-backup.dtb and change sun4i-a10-pcduino2.dtb to sun4i-a10-pcduino.dtb. Now the output of "sys/kernel/gpio" looks like: gpiochip0: GPIOs 0-287, parent: platform/1c20800.pinctrl, 1c20800.pinctrl: gpio-34 (PB2 ) gpio-98 ( |usb2-vbus ) out hi gpio-225 ( |cd ) in lo IRQ ACTIVE LOW gpio-228 ( |usb0_id_det ) in hi IRQ gpio-232 (PH8 ) gpio-233 (PH9 |lcd_backlight ) out lo gpio-234 (PH10 ) gpio-239 ( |pcduino:green:tx ) out hi ACTIVE LOW gpio-240 ( |pcduino:green:rx ) out hi ACTIVE LOW gpio-259 (PI3 |dc ) out hi gpio-266 (PI10 ) gpio-267 (PI11 ) gpio-268 (PI12 ) gpio-269 (PI13 ) I dont have my tft display to hand at the moment to further test if this actaully works but this intially looks a bit more promising. I will provide an update as soon as I get a chance to test with the display attached. Thanks Ryzer

Hi Eric, if you want to go down the wsl route then have to install windows terminal rathern and run wsl from there as from my own previous attempts got it compiling before running it some strange issue. For any kernel related patching you will need to run ./compile.sh with kernel-patch. The first number is the port number as Allwinner SOCs have there pins arranged into banks of ports where for example C = 2. The second number is the pin on that port and the third is indeed the active state of the pin. Indeed, please see here: https://docs.armbian.com/User-Guide_Armbian_overlays/ Dated but not yet removed. Although the patch is specifically target at rockchip, with some adjustments it could be to work with Allwinner. The core display driver will be same regardless of what SOC is driving it, The only thing that differs is the underlying spi implementation. You would need make sure that it is configurable as a loadable module within the sunxi configuration. Just checked the config menu and under staging/fbtft/ there is an option to configure the ST7796S. Hope you find this useful Ryzer

Hi Koliber93, Before trying to the ili9341 display working can you confirm that spi0 works with a simple spidev setup then move onto to trying to configure the display. Do not mix up pin functions, you should have a seperate node for the spi pins and additional gpio used for the display. Normaly the spi pins should already defined under the pinctrl node in which case we can simply refer to associated label. for reference please see: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/boot/dts/allwinner/sun8i-r40.dtsi?h=v6.6.66 As suggested by robertoj, I would stick with the hardware cs pin as I have had nothing but problems with gpio defind cs lines in recent kernels. If a simple SPI set works then please feel free to try the following overlay: /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3", "allwinner,sun8i-r40"; fragment@0 { target = <&pio>; __overlay__ { display_pins: display_pins { pins ="PH26", "PH27"; function ="gpio_out", "gpio_out"; }; }; }; fragment@1 { target = <&spi0>; __overlay__ { #address-cells = <1>; #size-cells = <0>; status = "okay"; pinctrl-names = "default", "default"; pinctrl-0 = <&spi0_pc_pins>; pinctrl-1 = <&spi0_cs0_pc_pin>; cs-gpios = <0>; /* PC23 for CS */ num-chipselects = <1>; display: display@0 { compatible = "adafruit,yx240qv29", "ilitek,ili9341"; reg = <0>; pinctrl-names = "default"; pinctrl-0 = <&display_pins>; spi-max-frequency = <24000000>; rotation = <270>; bgr = <0>; fps = <10>; buswidth = <8>; height = <240>; width = <320>; reset-gpios = <&pio 7 26 0>; /* PH26 for Reset */ dc-gpios = <&pio 7 27 0>; /* PH27 for Data/Command */ debug = <3>; }; }; }; __overrides__ { rotation = <&display>, "rotation:0"; fps = <&display>, "fps:0"; debug = <&display>, "debug:0"; }; }; I do find it strange however that you are not getting any activity on the DC line, are you sure you have probes labelled correctly? Best of luck Ryzer

Hi SGTMM, what type of TFT display are you trying to interact with? If you want to an alternative to fbtft, I would suggest look at drm based device drivers. Here you can find a list of the currently supported displays: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/gpu/drm/tiny?h=v6.6.63

Hi WDR_s, did you manage to make any progress. if you are still getting the pinctrl errors as shown above the problems relate to PC0 (Pin 64) and PH6 (Pin 230). Are you running any addtional overlays? Can you check sudo cat /sys/kernel/debug/gpio to ensure the pins are not being used elsewhere? Best of luck Ryzer

Hi Wollik, I would suggest avoiding using any Port A pins as these tend to be use for the Ethernet connector hence the error message above. Please refer to the Actually schematic for the BPI MI. You can find a copy here: https://linux-sunxi.org/LeMaker_Banana_Pi. The Allwinner A20 and A10 both share the same pin controller driver, which is why it shows up the log as sun4i. Best of luck 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

Hi robertoj, Do not activate spidev as I have mention above, doing so will cause a conflict. The Spidev driver and the ili9341 cannot access the spi bus at the same time. Without seeing your currently overlay its difficult to provide further assistance. Best of luck Ryzer

Hi robertoj, I have had some partial success with kernel 6.6 with my pcduino however I am not sure if the chip select issue I am currently facing would be relevant to you given its A10 which use a different SPI driver to the H3. What I would Intially suggest is making sure the pins that you are using are configure in the pin controller. You can check this by looking /sys/kernel/debug/pinctrl/1c20800.pinctrl/pinmux-pins and then using grep spi1 to filter out pins other than those used by spi1. Secondly check that the drm based ili9341 driver is present on your system and that you are not using the older fb_ili9341 which has been deprecated and has no garentee of working in newer kernels. Best of luck Ryzer