ldiaz

@A-P if you connect the screen to the PIZero as a Hat it sure SPI1 as SPI pins are those of this interface. SP1 CS=0. Also DC, RST/DC seems correctly mapped. The relevant part of the dmsg is this: [ 308.268459] fbtft: module is from the staging directory, the quality is unknown, you have been warned. [ 308.281149] fbtft_device: module is from the staging directory, the quality is unknown, you have been warned. [ 308.284168] m25p80 spi0.0: spi-nor spi0.0 10000kHz 8 bits mode=0x00 [ 308.284388] fbtft_device: spi_busnum_to_master(1) returned NULL [ 308.291574] fbtft_device: failed to register SPI device [ 418.056146] fbtft_device: module is from the staging directory, the quality is unknown, you have been warned. [ 418.058972] m25p80 spi0.0: spi-nor spi0.0 10000kHz 8 bits mode=0x00 [ 418.059177] fbtft_device: spi_busnum_to_master(1) returned NULL [ 418.066383] fbtft_device: failed to register SPI device it seems the spi_busnum=1 is not activated / registered as present. This, in principle, could be accomplished by inserting this in the armbianEnv.txt overlays=spi-spidev param_spidev_spi_bus=1 As regards current location of drivers mine are here: root@orangepizero:~# ls /lib/modules/4.11.5-sun8i/kernel/drivers/staging/fbtft/ fb_agm1264k-fl.ko fb_hx8347d.ko fb_ili9163.ko fb_ili9340.ko fb_ili9486.ko fb_s6d02a1.ko fb_ssd1306.ko fb_st7735r.ko fb_tls8204.ko fb_upd161704.ko fbtft_device.ko fb_bd663474.ko fb_hx8353d.ko fb_ili9320.ko fb_ili9341.ko fb_pcd8544.ko fb_s6d1121.ko fb_ssd1331.ko fb_st7789v.ko fb_uc1611.ko fb_watterott.ko flexfb.ko fb_hx8340bn.ko fb_hx8357d.ko fb_ili9325.ko fb_ili9481.ko fb_ra8875.ko fb_ssd1289.ko fb_ssd1351.ko fb_tinylcd.ko fb_uc1701.ko fbtft.ko But I'm using 4.11 kernel version. It should not be relevant if the module system is propperly configured. Hope It can be useful

@A-P Honestly I have not tested the ili9486 you are using but the li9341 that @glow is ussing. However they should work both. I think the best way to trouble shoot this is: 1. Could you share your screan pinout and wiring to the OpiZero? 2. Could you share dmesg after modprobe of the driver? 3. what is on your armbianEnv.txt? Regards,

This was my original proposal to use an overlay I posted one initial version that I wan't able to make work but I'm not a DTS expert maybe someone can simply aling it with the patch that @martinayotte created.

overlay is nothing special is only hardware definition SPI o IC2 have not hw discovery mechanims. Try spi-dev overlay without loading the driver and check if spi1 devices are created. My wiring is the following: display ZERO GPIOS VCC - 3.3 V pin 1 GND - GND pin 25 (any GND would do as they internaly connected) CS - SPI1 CS0 pin 24 RESET - GPIO1 pin 11 DC - GPIO0 pin 13 MOSI - SPI1 MOSI pin 19 SCK - SPI1 SCLK pin 23 LED - GPIO3 pin 15 MISO - SPI1 MISO pin 21 SPI port are fixed pins, you must configure only DC/RESET/LED according to your wiring. name=fb_ili9341 gpios=dc:0,led:3,reset:1 speed=16000000 busnum=1 rotate=0 bgr=1

@glow. Mine has a spi flash. But the fact is that H2+ gpios for SPI0 are not accesible in the GPIO header, so in any case you need to connect the display to the SPI1 not the 0. As you have done here: Try the overlay spi-dev with busnum=1 as I commented in my previus post. Then try to load the driver for the display with modprobe.

@A-P There is no more detail in dmesg about the error? It's very strange that @glow solution to busnum=0 works as OPIZERO has no pins to connect to SPI0 bus in the GPIO header. Check this: Busnum=1 will use the pins for SPI1: SPI1_CLK,SPI1_MISO,SPI_MOSI and SPI1_CS. For other needed pins (this will depend on the screen) you need to select the GPIOS manually. Be aware of the mapping: Check your wiring to verify it is correct with fbtft parameters. What errors are shown in dmesg? For checking that thet SPI1 works well you can use the spi-dev overlay simply puting this in /boot/armbianEnv.txt: overlays= <other overlays> spi-spidev param_spidev_spi_bus=1 after reboot /dev/spi* files should be present.

I confirm that raschid patch worked also for me. It include botth DTS mods for opizero and the patched driver for 4.11. May thanks for the success. I will some perfomance test also. As regards distance to AP I think this could be improved with a better antenna. The one that come with the zero seems really low quality,

Thanks @raschid, I'll give it a try!

That would be even better. do you think @martinayotte will be able to do it from his private build?

Yes that would cover points 1,2,3 of my proposal. Would it be possible to implement the 4 point (DTS part) with an overlay?

That's great news at least this solution will be a solution from some users. The driver is crapy but at least permit transmitting wireless which is a must in some applications. I understand to not include the solution in standard images. There is , however, the option to include as an option in the build tool for those that assume the risk of this crashy driver. As far as I understood to make it work it is needed to do following steps: build with newest patches that solve (aes-arm) crashes. Use correct fifteenhex' driver compatible with 4.11. I think this can be done changing the current add-xradio-wireless-driver.patch.disabled with the correct version. Still if it is remain as disabled it could be enabled manually by the user and compile the correct version. Use XRADIO_* kernel settings to activate the configuration and compilation. By default they can be commented (unset) but the user can remove the contents and get the driver compiled installed in custom builds. Provide a suitable DTS that inform the kernel that the xr819 is present with valid params. Current build system do not do configure it. Can this be done with an overlay? If yes then it can be included in the overlay section of the build script so it get compiled and can be activated by the user in armbianEnv.txt. If this approach is possible we can find a compromise between not supporting the driver in standard images but easy for custom compilation activation. What do you think? Regards,

The fbtft is included in main-line build you don't need to download or install anything else. As you say the once ftft_device is activated if wiring is correct the screen works with out problem in /dev/fb0. X windows also works with out problem. For touch screen you need to load the overlay I posted.

Hi Im using main-line/dev version not legacy. The GPIO are those of the SPI1 interface + some extra for additional signals required. in my case gpios=dc:0,led:3,reset:1. For display only its not needed to install any overlay only notro's fbtft. In case that what to use the touch screen then you need to use a device tree overlay using with spidev and spi-add-cs1 overlays. (attached my version) For touch you need and additional CS GPIO defined in spi-add-cs1 and one more for IRQ from the touch screen. I picked "PA7". regards, touch.dts

@raschid, @martinayotte I was able to compile the driver under 4.11 using this version: https://github.com/fifteenhex/xradio/commit/3f80a7c69a4d00b93bb187edc6beef2b4c38bada. Also I mokypatched the current patch in armbian/build to align the driver compiled during image build process including the XRADIO_* settings. The build is correct and the driver is loaded when booted: Linux orangepizero 4.11.5-sun8i #2 SMP Fri Jun 23 14:44:29 CEST 2017 armv7l GNU/Linux root@orangepizero:~# lsmod Module Size Used by sunxi_cir 16384 0 xradio_wlan 102400 1 sun8i_codec_analog 24576 0 mac80211 335872 1 xradio_wlan cfg80211 204800 2 mac80211,xradio_wlan still no wlan0 is available. It is possible that it has to be with associated DTS files that have been changed also. I'm trying with an overlay to properly configure it but still no success. I'm not an expert on Device-tree but it seems to be in-line with the needs to make the driver work. When loading the overlay there a msg showing that there are duplicate entries and lots of warnings in the compilation. /dts-v1/ /plugin/; / { compatible = "xunlong,orangepi-zero", "allwinner,sun8i-h2plus", "allwinner,sun8i-h3"; fragment@0 { target = "/aliases"; __overlay__ { ethernet1 = &xr819wifi; }; }; fragment@1 { target = "/reg_vcc_wifi"; __overlay__ { regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; startup-delay-us = <70000>; }; }; fragment@2 { target = "/wifi_pwrseq"; __overlay__ { pinctrl-names = "default"; pinctrl-0 = <&wifi_rst>; }; }; fragment@3 { target = <&mmc1>; __overlay__ { vmmc-supply = <&reg_vcc3v3>; vqmmc-supply = <&reg_vcc_wifi>; /*max-frequency = <16000000>; */ /delete-node/ xr819; xr819wifi: sdio_wifi@1 { reg= <1>; compatible = "xradio,xr819"; pinctrl-names = "default"; pinctrl-0 = <&wifi_wake>; interrupt-parent = <&pio>; interrupts = <6 10 1>; interrupt-names = "host-wake"; local-mac-address = [dc 44 6d c0 ff ee]; }; }; }; fragment@4 { target = <&pio>; __overlay__ { wifi_wake: wifi_wake@0 { allwinner,pins = "PG10"; allwinner,function = "irq"; allwinner,pull= <0>; }; }; }; fragment@5 { target = <&r_pio>; __overlay__ { wifi_rst: wifi_rst@0 { allwinner,pins = "PL7"; allwinner,function = "gpio_out"; allwinner,drive = <0>; allwinner,pull = <0>; }; }; }; }; Any Idea?

Yes it work fine for me. This are my fbtft options: name=fb_ili9341 gpios=dc:0,led:3,reset:1 speed=16000000 busnum=1 rotate=0 bgr=1 I think your problem is busnum. In OPIZero the SPI bus=0 is connected to a SPI flash you should use bus 1.

Thanks for the links. But i normally build my own images using lib build tools. I tried to build version 4.10 with xradio support but I cant do it with current master branch. any idea how to get the last version of build tools that will enable that. regards,

I understand Reading this thread that the driver can’t be compiled in 4.11 according to @martinayotte. However, @fifteenhex claims that it is working with the patch. Could you clarify what is the status? I understand the decision to exclude the driver from the default build but I think it would be great to make it work as an option for custom builds. It could be a crapy driver as you all comment. But i For those, like me, that use custom builds what is the last commit of the build tool that still use 4.10? I tried to find any tag in the master branch but I was unable to find it. Thanks,

It's working now! The key point was the missing bank in interrupts parameter. interrupts = <0 7 2>; /* high-to-low edge triggered change to PA7*/ The display I use has a pull up resistor for IRQ to vref , however it works if the the pin sections is "gpio_in" or "irq" , also it works bias-pull-up is activated or not. I tested the four possibilities (gpio_in+no bias, irq+no_bias, irq+bias-up, gpio_in+bias-up) and works in all cases. thank you Zador for you help . As promised I will create a post with a tutorial for setting up a touch screen for this boards. In principle it should valid for all h3 based boards with a commented DTS as example. Regards,

Thanks I give a try later with your sugestions. If it works I will Post a tutorial with the solution. This tfts are very low cost but could be very nice for certain applications. < $15 package including TF, board and touch screen.

Dear, I've trying to replicate Oskar archivements in an OrangpiZero with a 2.4" touch screen with an ili9341 for screen and XPT2046 (ADS7846 compatible as I have read). I'm runing a Mainline armbian dev version as next is not available for this board, I made sure that the ADS7846.ko is complided and included in the build. The display works fine with fbtft driver once configured the DC/LED/RESET gpios and selecting the bus=1. The device is connected to SPI1 (spi0 is connected to a flash in this board). I have included in the sun8i-h3-spi-add-cs1.dts to armbiamEnv.txt to a new pin "PA10" is usable as CS1 for SPI1. This in principle will enable to use 2 chip-select in the same SPI1 master. I have validated this assumption using the sample overlay in the repository: https://github.com/armbian/sunxi-DT-overlays-armbian/blob/master/examples/sun8i-h3-spi-double-spidev.dts if I load this overlay changing spi0 by spi1 i can see that two dev files are present in /dev directroy with spi1.0 and spi1.1 as expected. Following Oskar's approach I tried to adpapt the RPI overlay for my OPIZero. This is the file as source: /* * Generic Device Tree overlay for the ADS7846 touch controller * */ /dts-v1/; /plugin/; / { compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709"; fragment@0 { target = <&spi0>; __overlay__ { status = "okay"; }; }; fragment@1 { target = <&spidev0>; __overlay__ { status = "disabled"; }; }; fragment@2 { target = <&spidev1>; __overlay__ { status = "disabled"; }; }; fragment@3 { target = <&gpio>; __overlay__ { ads7846_pins: ads7846_pins { brcm,pins = <255>; /* illegal default value */ brcm,function = <0>; /* in */ brcm,pull = <0>; /* none */ }; }; }; fragment@4 { target = <&spi0>; __overlay__ { /* needed to avoid dtc warning */ #address-cells = <1>; #size-cells = <0>; ads7846: ads7846@1 { compatible = "ti,ads7846"; reg = <1>; pinctrl-names = "default"; pinctrl-0 = <&ads7846_pins>; spi-max-frequency = <2000000>; interrupts = <255 2>; /* high-to-low edge triggered */ interrupt-parent = <&gpio>; pendown-gpio = <&gpio 255 0>; /* driver defaults */ ti,x-min = /bits/ 16 <0>; ti,y-min = /bits/ 16 <0>; ti,x-max = /bits/ 16 <0x0FFF>; ti,y-max = /bits/ 16 <0x0FFF>; ti,pressure-min = /bits/ 16 <0>; ti,pressure-max = /bits/ 16 <0xFFFF>; ti,x-plate-ohms = /bits/ 16 <400>; }; }; }; __overrides__ { cs = <&ads7846>,"reg:0"; speed = <&ads7846>,"spi-max-frequency:0"; penirq = <&ads7846_pins>,"brcm,pins:0", /* REQUIRED */ <&ads7846>,"interrupts:0", <&ads7846>,"pendown-gpio:4"; penirq_pull = <&ads7846_pins>,"brcm,pull:0"; swapxy = <&ads7846>,"ti,swap-xy?"; xmin = <&ads7846>,"ti,x-min;0"; ymin = <&ads7846>,"ti,y-min;0"; xmax = <&ads7846>,"ti,x-max;0"; ymax = <&ads7846>,"ti,y-max;0"; pmin = <&ads7846>,"ti,pressure-min;0"; pmax = <&ads7846>,"ti,pressure-max;0"; xohms = <&ads7846>,"ti,x-plate-ohms;0"; }; }; Using the double-port template y created the following file. touch.dts: /dts-v1/ /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@0 { target-path = "/aliases"; __overlay__ { spi1 = "/soc/spi@01c69000"; /* Change spi0 -> spi1 */ }; }; fragment@1 { target = <&pio>; /* Change &gpio -> &pio */ __overlay__ { ads7846_pins: ads7846_pins { pins= "PA7"; /* TIRQ of the screen is connected to PA07" */ function = "gpio_in"; /*input. - should be irq?*/ pull = <0>; /* none. - should be bias-pull-up? */ }; }; }; fragment@2 { target = <&spi1>; __overlay__ { #address-cells = <1>; #size-cells = <0>; status = "okay"; /* Leave the first CS as in template */ spidev@0 { reg = <0>; /* Chip Select 0 */ compatible = "spidev"; spi-max-frequency = <1000000>; status = "okay"; }; /* Addapt ads definition */ ads7846: ads7846@1 { compatible = "ti,ads7846"; reg = <1>; pinctrl-names = "default"; pinctrl-0 = <&ads7846_pins>; spi-max-frequency = <2000000>; interrupts = <7 2>; /* high-to-low edge triggered change to PA7*/ interrupt-parent = <&pio>; /* Change gpio -> pio */ pendown-gpio = <&pio 0 7 0>; /* change to bank=0(A) port 7 -> PA7*/ /* driver defaults */ ti,x-min = /bits/ 16 <0>; ti,y-min = /bits/ 16 <0>; ti,x-max = /bits/ 16 <0x0FFF>; ti,y-max = /bits/ 16 <0x0FFF>; ti,pressure-min = /bits/ 16 <0>; ti,pressure-max = /bits/ 16 <0xFFFF>; ti,x-plate-ohms = /bits/ 16 <400>; }; }; }; }; I have removed all section about __overides__ as I don't know how to manage parameters. I load compule the dts using fresh verion of DTC compliler to accept parameter -@. I load the dtbo with the following command dynamicaly with a cat command to sysfs. The kernel detects correctly the DT and try to load the ads7846 driver but it fails with a non informative message: error -22. It seems that the driver do not initalize due to irq for the spi device is 0. Do you have any idea on how to solve this? Regards,

Very interesting Oskar. I've been playing about with spi tfts too on orange Pi Zero though. Could you share your dts files? thnx