ST7796 display w/ opiz3

[Eric Johnson]

I know I need to find out which drivers to use... I just don't know where to start, I know I've seen some people having success with these displays - ili9488, and a couple others - I just don't know if this fits one of those overlays or not. (nothing I've tried so far has worked).

 

Any help identifying and pointing in the right direction, I would greatly appreciate. Trying to get this to work on my Orange Pi Zero 3 4gb.

 

(uploading images has failed.... so I guess I'll link them?)

https://imgur.com/a/NORYCj7

 

*edit 12/21  - renamed topic since I've Identified the display, going to track my (our?) progress with trying to get it to work.

Edited December 21, 2024 by Eric Johnson
identified first issue

[Eric Johnson]

I got a reply from the manufacturer.  ST7796. 

 

 

Will this DTS work with the ST7796? (going to try it this weekend if no other solution mentioned beforehand)

 

 

 

Edited December 20, 2024 by Eric Johnson

[WDR_s]

Hello
Try this one, it might work on your screen.
 

 

[Eric Johnson]

Quote

Hello
Try this one, it might work on your screen.

 That uses a different touch controller than my screen (FT6236 vs my XPT2046). 

[robertoj]

Check here for the byte command sequence for st7796s and combine with the dts in my thread

 

https://forums.raspberrypi.com/viewtopic.php?t=380704

 

using the dts as is with your different touch controller likely wont hurt it, it may just throw error messages in dmesg|grep spi

 

or delete the touch part of the dts, or disconnect the spi pins to the touch controller if you want to be safer.

[Eric Johnson]

Quote

Check here for the byte command sequence for st7796s and combine with the dts in my thread

 

https://forums.raspberrypi.com/viewtopic.php?t=380704

 

using the dts as is with your different touch controller likely wont hurt it, it may just throw error messages in dmesg|grep spi

 

or delete the touch part of the dts, or disconnect the spi pins to the touch controller if you want to be safer.

 

to be clear, do you mean the 9341 dts (which uses the xpt2046 touch control, which my display has) or the 9488 dts?

 

I haven't gotten as far as trying anything yet, I'm having trouble getting the SPI to work on my opiz3. Either that, or I'm having trouble getting wiringOP to work properly enough on Armbian in order to verify SPI is working. wiringOP verifies other GPIO as functional (and so does my meter) - but SPI seems to be a no-go. I've tried every SPI overlay in the armbian-config utility.

[robertoj]

I meant the ili9488 DTS

 

Also avoid using any other SPI related DTS, when working with a LCD DTS. They will interfere with each other.

 

Use only the ili9488 DTS that I posted, only changing:

* the GPIO number codes, to make it fit your wiring connections

* the content of the *.txt file with the one in the raspberry forum

[Eric Johnson]

Ok. My efforts have been futile... but then again, I'm a noob at this. I'm thinking my pin numbers aren't matching up properly - I'm not 100% that I understand the <&pio 1 2 3> format. I have no clue what the first number is, I'm guessing the second number is the pin, and the third is high/low? (forgive my ignorance, I've tried researching this, but am not finding anything specific to this)

 

the changes marked in that raspberry pi forum I made to armbianEnv.txt (I'm assuming that's the armbian equivalent to the pi's config.txt?) - but it just occurred to me that the format is different. I don't think the armbian file uses "dtoverlay", rather just "overlay". I'll adjust that now and see if that  makes a difference. (edit - no matter what I do there, it doesn't load. absolutely nothing in dmesg about it one way or another)

 

This is what I've got:

 

/dts-v1/;
/plugin/;
/ {
    compatible = "allwinner,sun50i-h616";
    fragment@0 {
        target = <&spi1>;
        __overlay__ {
            status = "okay";
            cs-gpios = <&pio 7 24 0>,<&pio 2 26 0>; //chip select  pins 24 for LCD, 26 for touch
            panel: panel@0 {
                compatible = "panel-mipi-dbi-spi";
                reg = <0>;
                spi-max-frequency = <40000000>;
                width-mm=<79>;
                height-mm=<52>;
                reset-gpios = <&pio 2 22 0>; // pin 22, PC7
                dc-gpios = <&pio 2 18 0>; // pin 18, PC14
                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 = <&pio>;
                interrupts = <2 11 2>; /* PC6, pin 11 */
                pendown-gpio = <&pio 2 11 1>; /* PC6, pin 11  */

                /* 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>;
            };
        };
    };
};

 

Edited December 28, 2024 by Eric Johnson

[ag123]

I know zero about display panels and near zero about device tree and its interactions.

But that i went googling around and found out where the source codes for some of the lcd panel drivers are found in the kernel source codes

 

apparently the 'new' drivers for the various LCD panels may be found under 

 root/drivers/gpu/drm/panel

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/panel

some of the 'older' drivers could be under

fbtft

https://github.com/notro/fbtft/wiki

implemented under fbdev

 root/drivers/video/fbdev

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/video/fbdev

apparently fbtft may no longer be in more recent kernels from 5.4

https://github.com/notro/fbtft/wiki

 

a 'compatible' statement match in the driver is found for ILI9341 lcd e.g.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/panel/panel-ilitek-ili9341.c#n563

 

I did not find a driver name that has 7796, some of them found has sitronix-st* file names e.g. for st7789

a 'compatible' statement is found here

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/panel/panel-sitronix-st7789v.c#n672

 

take note that ST7796 may be using SPI rather than MIPI

http://www.lcdwiki.com/4.0inch_SPI_Module_ST7796

I've yet to try interfacing with ILI9341 which I've and I do not know how to configure SPI and in turn its driver with SPI 

 

things found from random google searches

https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next/+/refs/heads/akpm-base/Documentation/devicetree/bindings/display/ilitek%2Cili9341.txt

 

https://lore.kernel.org/lkml/20220618123035.563070-2-mail@conchuod.ie/

this is what is found so far

but there is still a lot more questions than there are answers, e.g. how to test if the spi is after all responding, how to test if the lcd is after all responding,

some hints can probably be found by reading the driver source codes, e.g. those embedded messages would likely show up in dmesg if after all the appropriate driver is loaded 

[Eric Johnson]

Thank you for the links. I went down a rabbit hole, beginning with those, and ultimately decided to build my own Armbian image. It's building as I type this... results tbd. Hopefully this will eliminate the step referenced in the rPi forum.

Another relevant link or two:

https://github.com/armbian/build/pull/7550 (st7796 patch)(fbtft referenced, although I thought that was dated?)(does this mean I can reference this directly from a dts??)(nevermind, upon review, this is for a rockchip board, not allwinner. leaving link here in case it becomes relevant.)

http://www.lcdwiki.com/res/MSP4021/ST7796S-Sitronix.pdf (datasheet)

http://www.lcdwiki.com/res/MSP3525_MSP3526/ST7796_Init.txt (initialization script, relevant??)

 

*edit - sidenote - I ordered a rPi a couple weeks ago (as the screen is intended for a rPi) because I was going to give up on getting this screen to work with this board... also, because this board was installed in a 3d printer. Well. I also acquired another 3d printer and another opiz3, so, that opiz3 is running one of the printers, a laptop is running the other two, and THIS opiz3 is set aside specifically to get this damned screen to work with it. The rPi, I'll deal with that later. As things develop with these opiz3's, I'll probably acquire more of them, and continue to experiment. I come from a (amateur) background of server-side web programming and database management, then I got into 3d printers, and as a result, this. So, while I may not have a clue as to what I'm doing at the moment, I'll figure it out, and perhaps, be able to contribute in some meaningful way toward making stuff work with these boards in the future.

Edited December 29, 2024 by Eric Johnson
afterthoughts

[ag123]

my guess is if you build it from source, look in the same directory trees for the drivers you should find the patched kernel sources and may be there could be the drivers specific to st7796

the kernel sources I'd guess is normally found under

cache/sources/linux-kernel-worktree/

after a build

you could try looking in the further sub trees for panel drivers e.g.

root/drivers/gpu/drm/panel

I'm not too sure if it isn't there that if you could patch your files there for the build, I'd think there are other related matters

e.g. how to integrate that in the makefiles, config etc

and there is likely armbian specifics on how to appropriately create the patch

a thing would be to check if st7789 driver works for st7796, st7789 is in the kernel but nothing specific to st7796 at least from the origin source tree.

you could perhaps try the compatible string from the st7789 driver

 

fbtft may no longer work in the recent kernels e.g. 6.x (i'm not sure about this one)

however, you may nevertheless want to try it out just in case it works after all

https://github.com/armbian/build/blob/bab9b3fbe383a2a2b1224d2bd4ca4d26142ed020/patch/kernel/archive/sunxi-6.6/patches.armbian/Add-FB_TFT-ST7796S-driver.patch#L142

^ note that this is for st7796s

and the relevant github repo is fbtft wiki itself

https://github.com/notro/fbtft/wiki

if you build from source, you could find that under drivers/staging/fbtft in cache/sources/linux-kernel-worktree/

do check if you may need to enable that during config for the kernel build itself

 

[Eric Johnson]

Well, naturally,  I ran into problems building.  I'm building on Ubuntu 24.04 from windows wsl,  and apparently that comes with it's own set of problems.  Chroot wasn't working properly. Found a fix,  implemented, then ran into qemu not working properly. Had to build qemu from source,  then forgot to refix the chroot problem (because I did fresh install of Ubuntu,  thinking that might fix qemu. It didn't. ). Will attempt again tonight and hunt for your references in the process.  

[ag123]

well, it isn't necessary to build in another virtual machine like docker etc if you are using linux running in wsl

you can build it directly in your shell using

 

compile.sh PREFER_DOCKER=no

 

https://gist.github.com/ag88/05245121cce37cb8f029424a20752e35#-building-armbian-in-systemd-nspawn-container

 

[Eric Johnson]

Hmm. Running in powershell wasn't working (something with utf-8), so I was running from ssh (I don't understand how that worked and shell didn't).  Either way,  I wasn't using docker. 

[ag123]

you can probably run it directly in the shell that wsl presents, which has to be in Ubuntu itself. But that PREFER_DOCKER=no runs the build directly in that shell without spawning another docker instance.

root (via sudo called internally) is needed to run it, but that it mostly stays within the build folder. root is needed due to the use of loop devices which is used to create the image.

it can be run as root without much fanfare and it should complete a build and leave your image in output/images. 

 

flashing that image is the same as how you would when you downloaded it say from Armbian

https://www.armbian.com/orange-pi-zero-3/

 

building from source opens up all the knobs and switches that you can tweak, I think it is even possible to change the kernel version. standard selections offers current and 'edge'. 'edge' is what I mostly choose as that would be a more recent kernel than stock.

 

you may need to explicitly 'enable', rather select your board (i.e. orange pi zero 3) from the menu presented during the build

 

 

[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.

 

On 12/28/2024 at 8:35 PM, Eric Johnson said:

I'm not 100% that I understand the <&pio 1 2 3> format. I have no clue what the first number is, I'm guessing the second number is the pin, and the third is high/low?

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.

 

On 12/28/2024 at 8:35 PM, Eric Johnson said:

I don't think the armbian file uses "dtoverlay", rather just "overlay"

Indeed, please see here: https://docs.armbian.com/User-Guide_Armbian_overlays/

 

On 12/29/2024 at 9:10 PM, Eric Johnson said:

https://github.com/armbian/build/pull/7550 (st7796 patch)(fbtft referenced, although I thought that was dated?)(does this mean I can reference this directly from a dts??)(nevermind, upon review, this is for a rockchip board, not allwinner. leaving link here in case it becomes relevant.)

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

 

 

Edited December 31, 2024 by Ryzer
Additional details