robertoj

That fixed it, it's now detected on i2c3 (i2cdetect -y 3)
Python also can interact with it
 
 
root@orangepizero2w:~# i2cdetect -y 3 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- 27 -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- Thank you SteeMan❤️

THANKS TO USER KungFuPancake, who showed me his github repo, where he indicates to use the latest Armbian-edge, and provides the a command byte sequence for the ili9488
 
https://github.com/KungfuPancake/v0_ips_touch_display?tab=readme-ov-file
 
If you see inverted colors, edit the panel-mipi-dbi-spi.txt and comment the line #command 0x21 before using the mipi-dbi-cmd
 
If you have the cheap chinese clone LCD (see first post), use this DTS (change the gpio codes as needed):
 
 
 
 
 
 

This is from panel-mipi-dbi-spi.txt
 
command 0xE0 0x00 0x03 0x09 0x08 0x16 0x0A 0x3F 0x78 0x4C 0x09 0x0A 0x08 0x16 0x1A 0x0F command 0xE1 0x00 0x16 0x19 0x03 0x0F 0x05 0x32 0x45 0x46 0x04 0x0E 0x0D 0x35 0x37 0x0F  
This is from LCDWIKI_SPI.cpp for ili9488:
0xE0, 15, 0x00, 0x07, 0x10, 0x09, 0x17, 0x0B, 0x41, 0x89, 0x4B, 0x0A, 0x0C, 0x0E, 0x18, 0x1B, 0x0F, 0xE1, 15, 0x00, 0x17, 0x1A, 0x04, 0x0E, 0x06, 0x2F, 0x45, 0x43, 0x02, 0x0A, 0x09, 0x32, 0x36, 0x0F,  
They are other commands that differs slightly. 
 
I've found other sources for the init sequence which seems all to be close to panel-mipi-dbi-spi.txt :
 
* Juj fbcp lib: https://github.com/juj/fbcp-ili9341/blob/master/ili9488.cpp#L28
* Bodmer eTFT_SPI lib for microcontrollers : https://github.com/Bodmer/TFT_eSPI/blob/master/TFT_Drivers/ILI9488_Init.h#L11
* Jarret Bucket Adafruit GLX lib : https://github.com/jaretburkett/ILI9488/blob/master/ILI9488.cpp#L378
* this one is for STM32 : https://github.com/RobertoBenjami/stm32_graphics_display_drivers/blob/master/Drivers/lcd/ili9488/ili9488.c#L219

In the same manner, we can found init sequences for other chips in these libraries, eg ili9486.
 
There's already a driver in the kernel source : https://web.git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/gpu/drm/tiny/ili9486.c?h=linux-6.12.y but it is specific to Waveshare 35a or PiScreen displays (these with 4 kind of shift register ICs onboard).
 
So for now, while waiting for a new ili9488 display arrives home, I'm digging further around the right init sequence for ili9486.

For reference and as a bookmark reminder
 
* https://github.com/bkosciow/gfxlcd/blob/master/gfxlcd/driver/ili9486/ili9486.py
* https://github.com/ZinggJM/ILI9486_SPI/blob/master/src/ILI9486_SPI.cpp
* https://github.com/RobertoBenjami/stm32_graphics_display_drivers/blob/master/Drivers/lcd/ili9486/ili9486.c
* https://github.com/Bodmer/TFT_eSPI/blob/master/TFT_Drivers/ILI9486_Init.h
* https://github.com/ZinggJM/ILI9486_SPI/blob/master/src/ILI9486_SPI.cpp
* https://github.com/DeadReDeamed/Raspberry-Pi-LCD-ILI9486-Driver/blob/main/LCD_Driver/LCD_Driver.c
 

@robertoj In terms of the actual TV encoder itself not significantly different, the same TV encoder driver is used for the H3. It just parses a different compatibility string to address any differences. If it still works on a device like the Orange Pi Zero then that is strong indicator that it is likely to work on the Banana Pi M1
 
Another thing to be mindful of is that the TV encoder is only part of the Display Engine. The A10 and A20 (which is the SOC on the Banana Pi M1) both have the 1st generation Display Engine where as the H3 is based on the 2nd generation.

I noticed it is applied somewhere between the existing patches. Have you tried to rename it to something like zzzz_yourpatchfile.patch so, since they are ordered alphabetically, it is applied at the very end, just like your chances have been made with all the previous patches already applied.

Thank you again, the lcd panel works.. Have a good days!!!..
 
armbian v25.02 rolling for Orange Pi 4 LTS running Armbian Linux 6.12.13-current-rockchip64
 
Linux orangepi4-lts 6.6.62-current-rockchip64 #1 SMP PREEMPT Tue Feb 11 11:37:33 +03 2025 aarch64 GNU/Linux  

@bhouseski I regularly boot directly from a usb connected SSD drive which is twice as fast as the SD card.
First you have to put u-boot on the SPI flash.  Find  u-boot-sunxi-with-spl somewhere on the SD card you are running and flash it to SPI.
The following is from the u-boot manual:
 
Installing on SPI flash from Linux
If the devicetree enables and describes the SPI flash device, you can access the SPI flash content from Linux, using the MTD utils:
 
# apt-get install mtd-utils
# mtdinfo
# flashcp -v u-boot-sunxi-with-spl.bin /dev/mtdX
 
You can then try to boot without an SD card installed. I had some difficulty in getting u-boot to consistently see the USB devices until I added a delay into the boot environment to allow time for the USB to connect.
 
Stop the boot procedure and do the following.  (The usb_pgood_delay variable did not exist on the opz3.)
 
    editenv usb_pgood_delay
        -> input a number, bigger than the existing (ms)  (I used 5000, 5 sec)
    saveenv

Hello
 
Did anyone have success with connecting an ili9486 to an orangepi zero 3 or another SBC?
 
I read that starting with linux 5.4, we need to change the reset pin polarity to 1, as show in https://github.com/swkim01/waveshare-dtoverlays/issues/24
 
I just got this LCD https://www.aliexpress.us/item/3256803856059047.html
 
It is the bigger borther of the ili9341 which I already have working according to: https://forum.armbian.com/topic/44191-orangepi-zero-lts-ili9341-tft-lcd-and-later-orangepi-zero-3/#comment-204672
 
 
The interesting thing is: when I use the ili9341 dtbo with the ili9486, I see a fraction of the X11 desktop, in the left 15% of the LCD screen... so at least I know that the connections and lowest level protocol is working.
 
However, when I try changing the compatible to ilitek,ili9486, with all the settings the same (except for rotation->rotate), I stay with a white screen.
 
actually, some other Aliexpress buyer says that my LCD is ili9488… so everyone needs to check their actual lcd controller. I need to recompile Armbian tomorrow
 
It appears that ili9488 is a clone of st7796s, which has this example DTS https://github.com/Sergey1560/fb_st7796s/blob/master/dts/sun50i-h6-st7796s.dts
 
It also appears that having the correct init bytes is critical. Here's another reference: https://forum.allaboutcircuits.com/threads/configuration-of-lcd-with-linux.145849/

Well, I tried my very best to find a solution, just to run into other Armbian peculiarities. 
1st, the problem with the missing signature can be solved by telling apt to ignore it.
Hence I created my apt.config settings in /etc/apt/apt.config.d as following:
cat 99mysettings Acquire::AllowInsecureRepositories "1"; Acquire::AllowWeakRepositories "0"; Acquire::AllowDowngradeToInsecureRepositories "1"; So apt started to work on it, giving the appropriate warnings:
 

 
which I ignored, so it started the upgrade:

just to learn, that I'm stuck again w/ Armbian. something w/ "unknown compression"
 

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.