Sma

So, it is working!  It just wasn't working with my edge custom built image: Armbian_23.08.0-trunk_Orangepipc_bookworm_edge_6.5.5_minimal.img.
I reproduced my efforts on the latest armbian image Armbian_23.8.1_Orangepipc_bookworm_current_6.1.47.img and it is working as expected.
The display works and the touch events are working properly.  I changed my wiring to test swapping LCD and Touch.  Here is my working wiring chart:

1 - VCC     (1)  3.3v
2 - GND     (6)  GND
3 - CS         (24) PC3 SPI0 CS
4 - RESET     (26) PA21 GPIO 11
5 - DC         (31) PA8 GPIO 22
6 - SDI (MOSI)    (19) PC0 SPI0 MOSI
7 - SCLK    (23) PC2 SPI0 CLK
8 - LED        (33) PA9 GPIO 23
9 - SDO (MISO)    (21) PC1 SPI0 MISO
10 - T_CLK      (23) PC2 SPI0 CLK *
11 - T_CS       (18) PC7 GPIO 5
12 - T_DIN    (19) PC0 SPI0 MOSI *
13 - T_DO    (21) PC1 SPI0 MISO *
14 - T_IRQ    (29) PA7 GPIO 21
 
Here are steps to get the display working:
 
Install latest armbian image: Armbian_23.8.1_Orangepipc_bookworm_current_6.1.47.img
 
sudo armbian-config
 
enable desktop
 
sudo nano /boot/armbianEnv.txt
 
user_overlays=touchscreen
extraargs=fbcon=map:1
 
nano touchscreen.dts
 
/dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@0 { target = <&pio>; __overlay__ { spi0_cs1: spi0_cs1 { pins = "PC7"; function = "gpio_out"; output-high; }; opiz_display_pins: opiz_display_pins { pins = "PA21", "PA8", "PA9"; function = "gpio_out"; }; ads7846_pins: ads7846_pins { pins = "PA7"; function = "irq"; }; }; }; fragment@1 { target = <&spi0>; __overlay__ { #address-cells = <1>; #size-cells = <0>; status = "okay"; pinctrl-1 = <&spi0_cs1>; pinctrl-names = "default", "default"; cs-gpios= <0>, <&pio 2 7 0>; /* PC7 */ ads7846: ads7846@1 { reg = <0>; /* Chip Select 0 */ compatible = "ti,ads7846"; spi-max-frequency = <500000>; 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 0>; /* PA7 */ /* driver defaults, optional */ 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>; }; opizdisplay: opiz-display@0 { reg = <1>; /* Chip Select 1 */ compatible = "ilitek,ili9341"; spi-max-frequency = <16000000>; status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&opiz_display_pins>; rotate = <90>; bgr = <0>; fps = <10>; buswidth = <8>; dc-gpios = <&pio 0 8 0>; /* PA8 */ reset-gpios = <&pio 0 21 1 >; /* PA21 */ led-gpios=<&pio 0 9 0>; /* PA9 */ debug=<0>; }; }; }; };  
sudo armbian-add-overlay touchscreen.dts
 
sudo nano /etc/modules-load.d/fbtft.conf
 
fbtft
fb_ili9341
 
sudo nano /usr/share/X11/xorg.conf.d/99-fbdev.conf
 
Section "Device"
  Identifier "myfb"
  Driver "fbdev"
  Option "fbdev" "/dev/fb1"
EndSection
 
reboot and your display and touch should work!

@MrK I missed your messages earlier and I can see your frustration.

The challenge for me personally is my ability to understand what you're proposing in your changes as I am just not at that technical level (a weak mind ), but I wish I was! That absolutely doesn't mean your changes aren't valid (or correct), but I am concerned (as I believe others are) that Armbian may not be the place for these improvements to be added, and they should perhaps be discussed in a kernel dev mailing list etc. and then make their way into Armbian by way of kernel changes? I understand @Gunjan Gupta questions/concerns about changing things (potentially unnecessarily) as I feel Armbian don't want to end up maintaining a kernel patch set very few in the project understand

Do you have the details for the mailing lists which deals with the components you're discussing? If not, perhaps someone from the forum can assist with a link and/or suggestion for how to get these patches/changes to the right place.
 
I really value your technical knowledge and experience in this space because I think what you're suggesting will improve the capabilities of the boards we're using, I just want to make sure these contributions are discussed with people responsible for this code upstream so everyone (even outside of Armbian) can benefit, and the changes can be discussed and maintained with like minded developers.

No I don't know everything. Infact I always say that "Knowledge is like an ocean and we spend our whole life to get a drop out of it"
 
But you seem to lack common sense of not touching things that are not needed to be touched. And it seems you get offended when someone tells you otherwise.
 
Because I am maintainer of only one H618 device i.e. Orange Pi Zero 3 which is quite new community supported device. I have other platinum support and standard support devices that I am maintainer of to support and that take more priority than this device.
 
Let me know if you need help with it.

@MrK I think you owe @Gunjan Gupta an apology.  There is no need for such language when people are volunteering their time and efforts, or ever for that matter.
 
@MrK you are in the wrong forum.  Changes such as you are proposing should be done at the Linux kernel level.
 
@MrK I am not sure the following comments are worth posting. But if it helps you, I would recommend that you learn to work with others in a team environment.  You will get more things done and with better results.  If you had been working for me I would have fired you for behaving this way. It is just too disruptive.

Awesome! Well, sort of....haha. I've had my OPiZ3 running for...looks like over 8 days now, on the PR6116 image @pixdrift was so kind to make available awhile back. Though granted it's just sitting there, not doing anything other than running random screen savers. Now of course I have to shut it down and grab one of the latest images to test. 

I've got a 3.5" touch screen attached to it, so I guess I'll see if i can get touch working, and if I'm not mistaken it SHOULD work without the HDMI hooked up, but maybe I have a false impression of what it's connector does. Maybe it only handles touch. If so no biggie, I can keep using it with HDMI as is. 🙂

I created the download page for it. So it should be even easier now - https://www.armbian.com/orange-pi-zero-3/

I can't advise on that, but it looks like it should work though.
 
On another note, the 3.5" lcd screen I have has a headphone out plug, so I should be able to test audio once an image with a fix is available. I haven't tried compiling any of them yet, I could give it a shot I guess.
 
I'll have to test to confirm my microhdmi to hdmi cable supports audio. But I don't see why it wouldn't.

Well.. one small line for orangepizero3.wip, one giant leap for Orange Pi Zero 3

The overlay PR fix from @Stephen Graf has been merged into Armbian.. thanks for sticking with it.. awesome to have more people contributing 
https://github.com/armbian/build/commit/08623d0e37dc02cb728b264f1e64771ddaba8025

 

@jokakilla ahh that's the same heatsink I have for mine, but from Amazon. 

Sorry for the large image, i'll try to make it smaller next time. 
 
Interestingly though, using x11vnc, i can move the mouse around, click on things, and use the keyboard over VNC, and the LCD stays off (no signal). It doesn't wake up until I hit something on the keyboard connected to the OPi. Not an issue for me, just an interesting observation.
 

@Gunjan Gupta No offence taken.  I am always impressed by people who have to communicate in a language other than their native. Keep giving me advice and I will keep trying to learn.
 
In that respect can you tell me why this dts does not compile:
 
sysadmin@orangepizero3:/mnt/dtbo$ dtc -O dtb -o sun50i-h616-i2c3.dtbo sun50i-h616-i2c3.dts
sun50i-h616-i2c3.dts:19.29-23.19: ERROR (phandle_references): /fragment@1/__overlay__: Reference to non-existent node or label "i2c3_ph_pins"
ERROR: Input tree has errors, aborting (use -f to force output)
sysadmin@orangepizero3:/mnt/dtbo$ more sun50i-h616-i2c3.dts
/dts-v1/;
/ {
        compatible = "allwinner,sun50i-h616";
        fragment@0 {
                target-path = "/aliases";
                __overlay__ {
                        i2c3 = "/soc/i2c@5002c00";
                        i2c3_ph_pins = "/soc/pinctrl@300b000/i2c3-ph-pins";
                };
        };

        fragment@1 {
                target = <0xffffffff>;
                __overlay__ {
                        status = "okay";
                        pinctrl-names = "default";
                        pinctrl-0 = <&i2c3_ph_pins>;
                };
        };
        __fixups__ {
                i2c3 = "/fragment@1:target:0";
        };
};
 
 

For those that may just be following this thread and not the GitHub repository, my changes for CPU Frequency on the zero3 were merged into the main Armbian Build repository last night, so rebuilding from armbian/build:main will add working CPU Frequency on zero3  I will build images at this PR for people to use (will let you know when they are up).

https://github.com/armbian/build/pull/6127
 
I will take a look at the I2C issue you've raised next @Stephen Graf as it looks like a fairly quick fix.

Hi @pixdrift, last night I tested your image of @Gunjan Gupta 's PR6106. Not surprisingly I got the same half-screen thing, you mentioned in your above reply. I was however able to fix it by guessing where the mouse cursor was and getting into the display settings. 
 
These are my notes from testing last night, on the Orange Pi Zero 3 2gb, using a 128GB SanDisk Ultra MicroSDXC  UHS-1 (A1) to run the image (PR6106_20231229_b1fb0d159_Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.7.0-rc7_xfce_desktop.tar.xz):
GUI Glitch: Using the HDMI port on the OPiZ3 - Asus 23" monitor at 1920x1080 (xfce desktop) Couldn't see the cursor and moving the mouse up would cause the display below where the mouse should be to change to solid colors (almost as if the pixel under the mouse cursor was being displayed across the entire screen below where the cursor would be) Managed to fix the glitch by guessing where the mouse was to bring up menus, and using arrow keys to navigate menus to change graphics settings Setting the scale to anything above 1.0 the glitch went away and the GUI was fine The fix seemed to work for different resolutions After a reboot, the glitch appeared on the login screen, but after logging in (not as root, I should try that but I suspect the glitch will remain as the fix was under my username), display settings made previously loaded and the glitch went away. Wifi glitch? (possibly related to the Bluetooth issue? I didn't test connecting to any Bluetooth devices, but mine did say it was on. I'll try pairing to something next time) It worked on the initial boot/setup/updates, but after getting into the xfce desktop the wifi seemed to disconnect. It would attempt to reconnect but kept saying it disconnected. After another reboot, it seemed to work fine and I was able to run apt-get update from a terminal, as well as install other apps, and visit sites using Chromium Some things seemed a little sluggish, especially the browser. I didn't think to take note of the CPU usage at idle, or what the clocks were running at. It did seem that some of the cores were under 10% usage and then one of them (core 4 i think) would seem to spike to 100% at idle, but I'll try to track that a little better next time I boot it up. Hopefully, that helps somewhat. I suspect the GUI glitch be fixed by setting the scale in a config file somewhere so that it doesn't happen on the login screen, but I don't know enough, without some googling, to try it.
 
 
 

Hi everyone!

As you can guess I'm looking to use my new OPi Z3 with Armbian. I'm currently looking to use it for two little Discord bots. But may eventually come up with other uses for it down the line.
 
Since @pixdrift asked others...I have the Orange Pi Zero 3 2gig version. No expansion boards ATM but I did get the MPI3508 3.5" LCD touch screen that uses the 26pins. Sadly because of the pin layout it kind of hangs off the side, it powers up though, but needs some tweaking/drivers to make it display anything. Aside from the official Orange Pi OS, I haven't gotten any GUI up and running yet. I am playing around with the MiniArch image @iun cuim posted a little further back. I went through the steps, in order, got it updated, and installed Endeavouros/GUI, but when I reboot it just goes back into the terminal login. I'm sure it's something simple I'm missing. (I'm using the onboard HDMI at the moment). 

It's further than I've gotten so far, aside from using the Official OrangePi image. All the other images I've tried the OPiZ3 wouldn't boot at all, the red light wouldn't come on (as I'm sure you're aware). I even tried the new builds of Noble and Trixie (for OPiZ2) which some said they were using on the PiZ3 I thought, unless I misread. 

Anyway, I'm looking forward to trying out the other images that any of you are kind to get set up for us. I'm willing to help as much as I can with testing and hope I'm not too much of a burden/slow down since I'm new to this. I am, however, somewhat familiar with Linux, but it's been some years so I may be a bit rusty with some things lol

On another note, I looked at the pinout for the LCD screen I got, it appears there are several pins it doesn't use, but of course, it blocks them. Later on I may look into somehow tapping into those pins to do, something, maybe control LED light strips, temp sensor connections, etc. Two other projects that I'm close to finishing are with an Arduino UNO (well, Elegoo Uno) and an ESP32 Cam. The Uno I'm using on my telescope to remotely control its focus, mainly when I live stream from the telescope. The ESP32 Cam I'm going to use to smarten up our garage opener. Since the ESP32 has a cam onboard, I can log in, see if the door is opened or closed, and close it if need be. I'll have to tap off of some of its pins to get an output to activate a relay, a similar process to what I'd need to do on the OPiZ3 with its 26 pins with the LCD attached. 

Hi everyone,
 
Apologies, have been away for Christmas.. and still not completely back on deck.

My Zero2W with expansion and expansion boards for Zero2 and Zero3 arrived during the break so I will also have those to test.

Welcome to the new people in the forum! @johndo100 and @Mako, can you let us know which boards and which variants you have (ie. memory configuration) and if you have IO boards? would be great to get some more testers with hardware contributing feedback here

Regarding testing for @Gunjan Gupta I am happy to create builds of his pull request efforts into mainline Armbian to make it easier for others to test, all I ask is that when people are posting feedback for different images they provide a link to the image they have downloaded/flashed so we can keep track of which feedback relates to which build. I will also include the PR (pull request) and commit ID in the builds I do.

I will try and get a build / image of the 6106 PR that @Gunjan Gupta is requesting testing for.. out today.

I am interested in what people prefer to test as there is a large number of combinations. I will build Bookworm and Bookworm + XFCE initially, and happy to take feedback if people have trouble with Debian.