robertoj

OK. I solved the issue of
sun50i-h616-pinctrl 300b000.pinctrl: pin PC7 already requested by spi2.0; cannot claim for 300b000.pinctrl:71
 
by deleting the fragment, which pre-defines the IRQ. See the DTS for touch chip:
 
 
I see these successful messages
 
The same solution might work for those who want to use native SPI with chip selects, and get the error message I mentioned above

FOR ORANGE PI ZERO 3:
 
This is the version of the LCD DTS, to use NO CS and all pins in the lower end of the connector: ili9341-spi1-opiz3.dts
 
 
^ confirmed working in Orange Pi Zero 3, Linux 6.6.31, with drivers included in Armbian 24.8.0-trunk.21 bookworm
 
v My current ATTEMPT to make the touch screen work: ads7846-opiz3-spi-gpio.dts
 
It is not working... the errors may be visible here:
 
More tests:
 
It looks like PC7 is not available for IRQ GPIO due to SPI2... That was unexpected... I will try other pins
Does the opiz3 even have a SPI2???

Are you using the latest Debian Bookworm Minimal, or the more complete Ubuntu Jammy Server?
 
In either case, post the result of "lsmod". Run "ip a" and see if there's any "wlan" interface.
 
Run (root) nmtui to try to activate wifi. If nmtui is not available, run "apt install network-manager".
 
Or try it "armbian-config" (apt install armbian-config)
 
If you are using Debian Bookworm, try with Ubuntu Jammy instead... it worked for me yesterday, with Orange Pi Zero and wifi.

There the option of “overlay file system”. It makes your file system “forget” anything that is changed since the snapshot, upon each poweroff 
 
look for it in armbian-config

There the option of “overlay file system”. It makes your file system “forget” anything that is changed since the snapshot, upon each poweroff 
 
look for it in armbian-config

I am experimenting with a cheap ILI9341 screen and mi OrangePi Zero LTS
https://www.aliexpress.us/item/2251832431328471.html
 
I found these recent instructions to be able to display graphics here:
https://ryjelsum.me/homelab/xpt2046-ili9341-opi-zero/
with a reference to a previous experience (without mentioning success)
https://hackaday.io/project/190371-g-edm/log/217902-first-success-with-armbian-nanopi-and-ili9341-touch
and independently, I found these instructions and experiences here:
https://docs.armbian.com/User-Guide_Allwinner_overlays/
https://forum.armbian.com/topic/27457-connecting-banana-pi-m2-zero-with-ili9341-display-over-spi-on-latest-armbian-image/ <-just found it and it has some success with BananaPi M2 Zero
https://tech-de.netlify.app/articles/de547180/index.html
https://4pda.to/forum/index.php?showtopic=782242&st=5060#entry112401076
 
I connected with wires as shown in instructions: https://forum.armbian.com/topic/28674-text-version-of-orange-pi-zero-pinout/
And the LCD's LED input pin to 3.3V
 
I activated the spi-add-cs1 overlay in arbian-config
 
I copied the dts for opiZ into ~/ili9341/ili9341-touch-double-spi-cs.dts
Then, I executed:
 
cd ili9341 armbian-add-overlay ili9341-touch-double-spi-cs.dts  
Then, I rebooted, and my LCD just looks gray.
 
My armbianEnv looks like this:
verbosity=1 bootlogo=false console=both disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 overlays=spi-add-cs1 tve usbhost2 usbhost3 rootdev=UUID=7d9a7016-73db-4f9c-a5bd-e3e5ab53ffc4 rootfstype=ext4 user_overlays=ili9341-touch-double-spi-cs usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u  
my armbianmonitor -u: https://paste.armbian.com/arogurekiv
 
I am still not done checking against the experiences with Bpi M2-0, but I ask here: anyone has experience with ILI9341+XPT2046, in either OrangePi Zero or Zero 3?
 
Should I downgrade to Linux 6.1.53?

Just to keep track of my progress:
 
OrangePi Zero can drive a ILI9341, with this ili9341-spi1.dts, with the fb_ili9341.ko driver (not the drm driver). Works on Linux 6.1.104 and Linux 6.6.44
 
Pin connections inside the DTS code:
 
and this armbianEnv.txt
 

Frank,
Not the SSH password. The SSH KEY, which is a piece of information that the client uses to verify that the server is really the server you expect, not a new impostor.
The SSH password lets the server know that YOU are who you say you are.
 
For docker, don't try to put the whole OS in an external USB SSD. The OS in microSD card is the most reliable way to do it. Then, you can use an external USB SSD for all your Docker images and containers.
 
How was it ever working with Docker? Orange Pi Zero has 256 or 512MB RAM.

Try it with a new image, new SD, with new Linux kernel version too.
 
I have an orangepizero and it works better with Linux 6.x

Ok. I got one output pin to work. 😀
 
This is how to do it in OrangePi Zero 3, pin 8 PH2:
 

 
In Bash as root:
# addgroup --system gpio
# chown root:gpio /dev/gpiochip0
# chmod 660 /dev/gpiochip0
# nano /etc/udev/rules.d/61-gpio-tools.rules
{add line SUBSYSTEM=="gpio",KERNEL=="gpiochip*", GROUP="gpio", MODE="0660"}
# usermod -a -G gpio myusername
# apt install python3-dev
# reboot
 
In a new folder for your Python script, as normal user:
$ python3 -m venv .venv
$ source .venv/bin/activate
$ pip install gpiod
 
Create script (example in https://pypi.org/project/gpiod/ with one fix):
$ nano blink_pin.py
 
import time import gpiod #needed in example from gpiod.line import Direction, Value #Calculating PH2 "line" number #H=8 #2=2 #line=(8-1)x32+2=226 #also shown in https://github.com/rm-hull/OPi.GPIO/issues/79 LINE = 226 with gpiod.request_lines( "/dev/gpiochip0", consumer="blink-example", config={ LINE: gpiod.LineSettings( direction=Direction.OUTPUT, output_value=Value.ACTIVE ) }, ) as request: while True: request.set_value(LINE, Value.ACTIVE) time.sleep(1) request.set_value(LINE, Value.INACTIVE) time.sleep(1)  
Run script:
$ python3 blink_pin.py
 
When done working with your project:
$ deactivate
 
Pin 8 PH2 turns ON and OFF 😄
I haven't tested the other pins yet

I returned to checking on my opiz3, and saw that there's a kernel update available... with related updated dtb's
 
I will hold off from updating, and test it first in my non-production opiz3

Ok. I got one output pin to work. 😀
 
This is how to do it in OrangePi Zero 3, pin 8 PH2:
 

 
In Bash as root:
# addgroup --system gpio
# chown root:gpio /dev/gpiochip0
# chmod 660 /dev/gpiochip0
# nano /etc/udev/rules.d/61-gpio-tools.rules
{add line SUBSYSTEM=="gpio",KERNEL=="gpiochip*", GROUP="gpio", MODE="0660"}
# usermod -a -G gpio myusername
# apt install python3-dev
# reboot
 
In a new folder for your Python script, as normal user:
$ python3 -m venv .venv
$ source .venv/bin/activate
$ pip install gpiod
 
Create script (example in https://pypi.org/project/gpiod/ with one fix):
$ nano blink_pin.py
 
import time import gpiod #needed in example from gpiod.line import Direction, Value #Calculating PH2 "line" number #H=8 #2=2 #line=(8-1)x32+2=226 #also shown in https://github.com/rm-hull/OPi.GPIO/issues/79 LINE = 226 with gpiod.request_lines( "/dev/gpiochip0", consumer="blink-example", config={ LINE: gpiod.LineSettings( direction=Direction.OUTPUT, output_value=Value.ACTIVE ) }, ) as request: while True: request.set_value(LINE, Value.ACTIVE) time.sleep(1) request.set_value(LINE, Value.INACTIVE) time.sleep(1)  
Run script:
$ python3 blink_pin.py
 
When done working with your project:
$ deactivate
 
Pin 8 PH2 turns ON and OFF 😄
I haven't tested the other pins yet

Yeah, just noticed this myself.
 
I was pleased that Armbian 23.05 started up just fine on my Orange Pi Zero (H3 LTS), seeing as other discussions had said that Allwinner 32bit was not working.
 
Wireless is definitely not working OOTB, however. I updated firmware in armbian-config, but the Networking options don't show a wifi option. Neither ifconfig nor nmtui-connect list a wireless interface. No messages from xradio in dmesg.
 
I think maybe I saw a mention in an old forum post that the xradio driver doesn't work with kernel 6.x, so maybe that's it? Or maybe it's just not set up quite right? Or maybe there's something that users need to do in order to get it working?
 
In spite of the terrible reputation of the xradio driver, it was working adequately for me in Armbian bullseye. Very much hope that I can get it working in latest Armbian!

Yesterday, I was able to build the unpatched source of ffmpeg (the snapshot available in this date), and it ran fine, with CPU H264 decoding.
 
https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu
 
Then, I downloaded this libreelec patch.
https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/multimedia/ffmpeg/patches/v4l2-request/ffmpeg-001-v4l2-request.patch
with:
cd ffmpeg_sources/ffmpeg
patch -p1 < ffmpeg-001-v4l2-request.patch
 
There was only 1 hunk error.
patching file libavcodec/h264_slice.c
Hunk #1 FAILED at 808.
Hunk #2 succeeded at 861 (offset 7 lines).
1 out of 2 hunks FAILED -- saving rejects to file libavcodec/h264_slice.c.rej
 
I am working on fixing this patch correctly.