Sma

You could try armbian-config, i believe in the hardware section you can disable the desktop from there.

Ahhh gotcha. Maybe that's probably a step I'm missing. I'll look back through the thread for it. Focusing on getting the LCD display to work first, I went to a different image, and went through the steps I previously did, but this time went through the steps on the lcd wiki to load the lcd driver (not the touch sensor yet). After reboot no real change. I checked Dmesg, and it does show the below, which is more than I got before (just the first line with the warning). (This was the result of using an older DTS) [ 5.598832] fbtft: module is from the staging directory, the quality is unknown, you have been warned. [ 5.608672] systemd[1]: Mounting sys-fs-fuse-connections.mount - FUSE Control File System... [ 5.614293] systemd[1]: Finished systemd-remount-fs.service - Remount Root and Kernel File Systems. [ 5.615861] systemd[1]: systemd-pstore.service - Platform Persistent Storage Archival was skipped because of an unmet condition check (ConditionDirectoryNotEmpty=/sys/fs/pstore). [ 5.620811] systemd[1]: Starting systemd-random-seed.service - Load/Save Random Seed... [ 5.621197] fb_ili9341: module is from the staging directory, the quality is unknown, you have been warned. [ 5.621724] sun50i-h616-pinctrl 300b000.pinctrl: supply vcc-pa not found, using dummy regulator [ 5.622378] fb_ili9341 spi0.0: fbtft_property_value: regwidth = 8 [ 5.622388] fb_ili9341 spi0.0: fbtft_property_value: buswidth = 8 [ 5.622400] fb_ili9341 spi0.0: fbtft_property_value: debug = 0 [ 5.622409] fb_ili9341 spi0.0: fbtft_property_value: rotate = 0 [ 5.622419] fb_ili9341 spi0.0: fbtft_property_value: fps = 10 [ 5.622583] sun50i-h616-pinctrl 300b000.pinctrl: pin PA7 already requested by spi0.0; cannot claim for 300b000.pinctrl:7 [ 5.622595] sun50i-h616-pinctrl 300b000.pinctrl: error -EINVAL: pin-7 (300b000.pinctrl:7) [ 5.622610] fb_ili9341 spi0.0: error -EINVAL: Failed to request reset GPIO [ 5.622649] fb_ili9341: probe of spi0.0 failed with error -22 (This was the below is the newer DTS this reply of Peters) [ 5.550586] fbtft: module is from the staging directory, the quality is unknown, you have been warned. [ 5.560145] fb_ili9341: module is from the staging directory, the quality is unknown, you have been warned. I noticed the difference between the older and newer DTS is pin assignments. I just compared the pinouts for the MPI3508 and the Orange Pi Zero 3 and everything seems to match up with their labels, with the one exception, on my OPiZ3, SPI1/CS/PH9(pin 24) is one pin above the TP_CS pin (26) on the MPI3508. I think another issue I'm having is the DTS that's been posted here is for the bigger Orange Pi, with the 40pin header, and my OPi has the 26pin header, which is the same count as that on the LCD. Because of that I probably need to rename/number something in the DTS, but I'm not sure what yet.

To be honest, I'm not sure what ads7846 is. This is the thread I've been following. They're been working on various Orange Pi Zero's. Most recently the Zero 2 and Zero 3. They have been working to get Armbian to work on the Zeros, and have gotten it working, and a few weeks ago were working on getting the SPI bus support going, which as far as I understand it is working now, but I'm not familiar with how that all works. Still learning a lot of how this works with armbian, and orange pi etc. UPDATE I noticed in the 99-fbdev.conf file it has Option "fbdev" "/dev/fb1". FB as i understand is frame buffer. I had a look in /dev earlier and didn't see any /dev/fb0 or fb1. I did something that did show /dev/fb0, so i went back into that config file and changed it to fb0. After a reboot the desktop popped up on the HDMI output, so at least now I know how to get the HDMI back. I may have to dig into dmesg and see if there are any clues in there.

OK, so still at the nothing happens stage for me. Nothing on the HDMI or LCD. evtest comes back with /dev/input/event0: DELL DELL USB Keyboard /dev/input/event3: BRLTTY 6.5 Linux Screen Driver Keyboard Whatever that BRLTTY is (something to do with TTY service?), doesn't seem to be anything to do with the touch screen, as it doesn't show any input when I try it (though if the pins aren't right that could be it). gpioinfo for chip1 has 32 lines, I'm assuming that's where the GPIO would show up for the screen, but it says they're all unused. Chip0 has 287 lines, most seem to be unnamed/unused (see bottom for examples). After dinner, I'll see if I can get the HDMI to come back. I guess the next step is to check the pinouts on my OPiZ3 compared with the screen and with the pinout above where it's said to have worked. For reference, I'm using the latest image that @pixdrift provided in another thread (bookworm edge 6.7.4). However, I may try the previous one, as now that I look at it, the one I'm using now appears to have something to do with audio. Also, I went into Armbian config and turned on all the options for SPI and the TFT options as well. Maybe I'll go back and turn TFT off and run the command that added the DTS again. When I tried that it said it was already configured so might be interfering and not loading that DTS. line 64: unnamed kernel input active-high [used] line 65: unnamed unused input active-high line 66: unnamed kernel input active-high [used] line 67: unnamed kernel input active-high [used] line 68: unnamed kernel input active-high [used] line 69: unnamed unused input active-high line 70: unnamed unused input active-high line 71: unnamed unused input active-high line 72: unnamed unused input active-high line 73: unnamed "interrupt" input active-high [used] line 74: unnamed unused input active-high line 75: unnamed unused input active-high line 76: unnamed "red:status" output active-high [used] line 77: unnamed "green:power" output active-high [used] line 78: unnamed unused input active-high line 79: unnamed unused input active-high line 80: unnamed "regulator-usb1-vbus" output active-high [used] ... line 192: unnamed kernel input active-high [used] line 193: unnamed kernel input active-high [used] line 194: unnamed kernel input active-high [used] line 195: unnamed kernel input active-high [used] line 196: unnamed kernel input active-high [used] line 197: unnamed kernel input active-high [used] line 198: unnamed unused input active-high line 199: unnamed unused input active-high line 200: unnamed unused input active-high line 201: unnamed unused input active-high line 202: unnamed unused input active-high line 203: unnamed unused input active-high line 204: unnamed unused input active-high line 205: unnamed unused input active-high line 206: unnamed unused input active-high line 207: unnamed unused input active-high line 208: unnamed unused input active-high line 209: unnamed unused input active-high line 210: unnamed "reset" output active-low [used]

Finally getting around to testing your steps @Peter Gregory I did it once with a newer image, but wasn't sure which one. When it rebooted nothing happened on the mpi3508, or the monitor on HDMI. I'm about to run through the steps you documented and see what happens. However, I haven't checked on the wiring. I'm using the OPiZ3, with that supposedly just hooking it up so that the ground and 3.3v pins are in the right places it's supposed to work, but I haven't checked the pinouts compared with what you have for your wiring. If this second round of setting up the OS doesn't work I'll have to look into the wiring. This might not be a bad thing, currently, the screen hangs off the side, due to how it has to be rotated. If I have to wire it to make it work, that may allow me to rotate it so it doesn't take up a bigger footprint.

The latest images should have working wifi. I haven't tested personally myself, since...two weeks ago maybe. I recall someone not long ago saying that the Wi-Fi CPU usage issue was fixed too. I haven't had the time lately, but I'm looking to make it work with the MPI3508 LCD Touch screen. I may have to end up compiling support for it, but I've gotta look at the various resources to figure it out.

Nice! I know this is an old post, but I have the same screen, MPI3508. I'm trying to get it to work on the Orange Pi Zero 3. As far as I recall from looking at the pin diagrams, physically it should work. Software/drivers on the other hand I haven't had much luck with. Though until recently, as far as I'm able to understand anyway, SPI hasn't been working on the builds they've been working on for the OPiZ2/3 until recently. Just curious though, in some places it seems like this, or similar displays can work without using the HDMI connection or am I misunderstanding? I guess similar screens may be capable of displaying images just using the 24-pin connector on the OrangePi, while others only use it for the touch interface. I'll look back over the steps you went through later and see if I can apply them to what I do know. Otherwise I'll look into what it takes to compile an image, and combine what you have, with what they've been doing to make Armbian work on the OPiZ2/3.

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

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

I may try to get in on this. I'm looking to use my OPiZ3 for discord bots, and later maybe some other projects like an all-sky camera/weather station, that'll likely not be for the Z3 since it probably wouldn't be able to handle the image processing/storage, but that is a bit down the road still. I'm also thinking about MAYBE adding addressable LED support to the bots, so bot status could be displayed via different colors/patterns. I haven't done any work yet to port the existing bot from node.js to python, which is I think where I want to take it. I'll go back and find the latest image you posted @pixdrift and let it run, maybe tinker with setting up the bot and note down temps etc (I'm sure theres a way to have it log that data?). So far in my limited testing, the heatsink has barely been warm, and the temps haven't been very high, hovering around 100F give or take. I do have a heatsink, it's a full plate, with the standard OEM heat transfer pads. The plate covers the whole board, along with a plate on the bottom. I also have a 3.5" touch screen, but since you all are working on the SPI/i2c stuff, I haven't tried getting it to work yet. It is of course running off the power provided by the pin headers though, and is connected via HDMI. The interesting thing is that Armbian was still set for 1920x1080 when I connected the 3.5" screen, and it worked, but of course, all the fonts were so tiny you couldn't read them. The recommended resolution for the screen wasn't listed when I went to change it, but it displays fine at the lowest resolution that Armbian lists. Everything is readable at least.

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.