pixdrift

As you mentioned you had a serial adapter plugged into zero2 but not to the pc, its possible that the uart adapter might have sent some garbage character just when it says press any key to stop booting and hence it got stopped there. I have seen that happens sometimes when my serial adapters usb plug touches some metal or when I touch the same.

@pixdrift  I built an image for the zero3 from your repository and I am not having any difficulties with the overlays.
 
If you think it is the overlays that are causing your boot problems you can try putting your system drive on another machine and removing the overlays line in:
 
sysadmin@orangepizero3:~$ more /boot/armbianEnv.txt
verbosity=1
bootlogo=false
console=both
disp_mode=1920x1080p60
overlay_prefix=sun50i-orangepizero2-3
rootdev=UUID=8b58b731-6024-4fbe-bd3e-c784b3b9a449
rootfstype=ext4
overlays=i2c3 ir otg-host spi1-cs0-spidev uart5
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u
 
Armbian-config creates and modifies this line when you enable/disable overlays.
 
If that resolves the problem try adding overlays one at a time. I would suggest this order:
i2c3
ir
spi1-cs0-spidev
uart5
otg-host

@pixdrift You will need a connection to the console uart to catch the log of the overlays. It all happens at boot time before the OS is started.
On the system as root go to armbian-config and then System and Hardware. enable (space) all of the items offered. Then save, back and reboot. Watch the output of the console.
 
U-Boot 2024.01-rc5-armbian (Dec 31 2023 - 01:13:07 +0000) Allwinner Technology
CPU:   Allwinner H616 (SUN50I)
Model: OrangePi Zero3
DRAM:  1 GiB
Core:  57 devices, 25 uclasses, devicetree: separate
WDT:   Not starting watchdog@30090a0
MMC:   mmc@4020000: 0
Loading Environment from FAT... Unable to use mmc 0:1...
In:    serial@5000000
Out:   serial@5000000
Err:   serial@5000000
Allwinner mUSB OTG (Peripheral)
Net:   Unsupported value 13, using default (13)
Unsupported value 13, using default (13)
eth0: ethernet@5020000using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in
MAC de:ad:be:ef:00:01
HOST MAC de:ad:be:ef:00:00
RNDIS ready
, eth1: usb_ether
starting USB...
Bus usb@5200000: USB EHCI 1.00
Bus usb@5200400: USB OHCI 1.0
scanning bus usb@5200000 for devices... 1 USB Device(s) found
scanning bus usb@5200400 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Autoboot in 1 seconds, press <Space> to stop
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
3259 bytes read in 2 ms (1.6 MiB/s)
## Executing script at 4fc00000
U-boot loaded from SD
Boot script loaded from mmc
299 bytes read in 2 ms (145.5 KiB/s)
31257 bytes read in 4 ms (7.5 MiB/s)
Working FDT set to 4fa00000
268 bytes read in 3 ms (86.9 KiB/s)
Applying kernel provided DT overlay sun50i-h616-ir.dtbo
512 bytes read in 3 ms (166 KiB/s)
Applying kernel provided DT overlay sun50i-h616-light.dtbo
failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND
339 bytes read in 3 ms (110.4 KiB/s)
Applying kernel provided DT overlay sun50i-h616-mcp2515.dtbo

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

 

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

 

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

 

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

 

Not wanting to side track this thread off the Orange Pi, but I found some info about an upcoming h618 board from Sipeed, the Longan Pi 3H, which is similar to the Orange Pi Zero2W.

From the news I have read and the store, it's in early production and appears to have limited availability.
https://www.aliexpress.us/item/3256806204597847.html?gatewayAdapt=glo2usa

The reason it may be useful in this thread, is the mainlining effort they have undertaken may have some crossover with what we are looking at for the Orange Pi Zero 3, so their repository may be a good point of reference for patches/changes etc:
https://github.com/sipeed/LonganPi-3H-SDK
 
-edit-
 
Couldn't help myself, I have ordered one 

Yup mine is running with a heatsink (kit from aliexpress). Idle 37°C. After running "stress --cpu 4" for a few minutes it's going up to 60°C. The sensor values delivered from the SOC seem legit.
 
Have been running some stress tests for io and ram too without instabilities: "stress --cpu 4 --io 4 -m 4 --vm-bytes 512M -t 300".
Not sure if the cpu frequency and so on is controlled by the kernel, driver or by the SOC internally. So no idea if this is interesting but the data shown by cpufreq-info seems ok. After stress testing high percentage is at 1.51 GHz. When idling the percentage of time in 480 MHz is rising. So switching between different frequencies looks good. Unfortunately the tool is printing stuff in german.
 

 

@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 have a zero3 with 1G ram. I just stuck some small heats sinks on the cpu and mem. A stress test and results are included below.
Before Armbian was viable I compiled the Linux kernel on this system using the Zunlong image.  It ran for a couple of hours with all 4 cpus at 100%.  The temperature stayed constant at about 65, but it worked without a problem.
 
sysadmin@orangepizero3:~$ sudo stress --cpu 4 --io 4 -m 4 --vm-bytes 256M -t 300
stress: info: [2144] dispatching hogs: 4 cpu, 4 io, 4 vm, 0 hdd
stress: info: [2144] successful run completed in 301s
 
12:07:25   480 MHz  3.60   0%   0%   0%   0%   0%   0%  41.3 °C  0/5
12:07:31   480 MHz  3.39   0%   0%   0%   0%   0%   0%  41.3 °C  0/5
12:07:36  1512 MHz  3.20  22%  15%   7%   0%   0%   0%  43.8 °C  0/5
12:07:41  1512 MHz  4.07 100%  64%  35%   0%   0%   0%  48.0 °C  0/5
12:07:46  1512 MHz  4.78 100%  64%  35%   0%   0%   0%  48.7 °C  0/5
12:07:51  1512 MHz  5.44 100%  64%  35%   0%   0%   0%  49.3 °C  0/5
...
12:12:09  1512 MHz 13.22 100%  66%  33%   0%   0%   0%  56.7 °C  0/5
12:12:14  1512 MHz 13.20 100%  64%  35%   0%   0%   0%  56.5 °C  0/5
12:12:19  1512 MHz 13.18 100%  65%  34%   0%   0%   0%  56.4 °C  0/5
Time        CPU    load %cpu %sys %usr %nice %io %irq   Tcpu  C.St.
12:12:25  1512 MHz 13.17 100%  64%  35%   0%   0%   0%  57.0 °C  0/5
12:12:30  1512 MHz 13.16 100%  65%  34%   0%   0%   0%  56.8 °C  0/5
12:12:35  1512 MHz 13.14  96%  62%  30%   0%   3%   0%  56.8 °C  0/5
12:12:40   480 MHz 12.17   0%   0%   0%   0%   0%   0%  51.0 °C  0/5
12:12:45   480 MHz 11.28   0%   0%   0%   0%   0%   0%  49.9 °C  0/5
12:12:50   480 MHz 10.45   0%   0%   0%   0%   0%   0%  49.1 °C  0/5
12:12:55   480 MHz  9.69   0%   0%   0%   0%   0%   0%  48.4 °C  0/5
...
12:56:56   480 MHz  1.00   0%   0%   0%   0%   0%   0%  39.1 °C  0/5
12:57:01   480 MHz  1.08   0%   0%   0%   0%   0%   0%  39.5 °C  0/5
12:57:06   480 MHz  1.07   0%   0%   0%   0%   0%   0%  39.3 °C  0/5
12:57:11   480 MHz  1.06   0%   0%   0%   0%   0%   0%  39.2 °C  0/5

Also the contribute/PR process as documented in the Armbian Docs:  https://docs.armbian.com/Process_Contribute

I think the overlay files for zero2 and zero3 can be the same as the hardware layout is identical. Zero2w is different.
I have put together and tested 3 overlay files,
- enable i2c3
- enable spi1 and create spidev
- change usbotg to host
I could use the i2c3 and spi1 overlays to fix the PH5 duplication if it will not be done in sun50i-h616.dtsi.
Usb2 and 3 are already enabled and work without further changes.
I am still looking into uart5 to determine what is required. Ir is another item to look at.  Then there is sound which has output on the header. But since sound is not yet working that will have to wait.
All these overlays currently exist in the Zunlong image. After @Gunjan Gupta showed me how to build an overlay I am now able to reverse engineer the Zunlong dtbos and create dts/dtbo for Armbian.

@Gunjan Gupta, Would you be able move forward the following patch. I have been working on the zero3 overlays and with your help I have made some progress. But it all depends on having the overlay_prefix set.  It makes sense to point to the h616 overlays as the zero3 and zero2 are common for the items that would normally go into the overlays. I have been using the proposed change and it makes the fixup.scr work on boot and allows armbian-config > System > Hardware to work and load overlays on boot
 
diff --git a/config/boards/orangepizero3.wip b/config/boards/orangepizero3.wip
index 18bcae79d..642eb216f 100644
--- a/config/boards/orangepizero3.wip
+++ b/config/boards/orangepizero3.wip
@@ -3,6 +3,7 @@ BOARD_NAME="Orange Pi Zero3"
 BOARDFAMILY="sun50iw9"
 BOARD_MAINTAINER="viraniac"
 BOOTCONFIG="orangepi_zero3_defconfig"
+OVERLAY_PREFIX=sun50i-h616
 BOOT_LOGO="desktop"
 KERNEL_TARGET="current,edge"
 FORCE_BOOTSCRIPT_UPDATE="yes"
 

Just a quick update from a "test user" point of view running "Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.7.0-rc7.i2c3.test.tar.xz". i2c port and io stuff isn't very interesting for me personally..bear with me
I'm using SBC more or less as little servers.
 
Overall stability: Pretty good. No crashes reboots or so
Docker: Hardware device forwarding to container (zigbee usb stick) works fine. Giving containers separate interface in different VLAN (ipvlan) works well.
lmsensors gives reasonable information:
{ "cpu_thermal-virtual-0":{ "Adapter": "Virtual device", "temp1":{ "temp1_input": 37.079 } }, "gpu_thermal-virtual-0":{ "Adapter": "Virtual device", "temp1":{ "temp1_input": 37.970 } }, "ddr_thermal-virtual-0":{ "Adapter": "Virtual device", "temp1":{ "temp1_input": 37.727 } }, "ve_thermal-virtual-0":{ "Adapter": "Virtual device", "temp1":{ "temp1_input": 36.674 } } }  
mpstat is also working fine. Idle is little low because Unifi server is eating up lots or resources when starting 🫣:
{"sysstat": { "hosts": [ { "nodename": "orangepizero3", "sysname": "Linux", "release": "6.7.0-rc7-edge-sunxi64", "machine": "aarch64", "number-of-cpus": 4, "date": "08.01.2024", "statistics": [ { "timestamp": "22:15:23", "cpu-load": [ {"cpu": "all", "usr": 32.22, "nice": 0.00, "sys": 2.99, "iowait": 6.49, "irq": 0.00, "soft": 0.01, "steal": 0.00, "guest": 0.00, "gnice": 0.00, "idle": 58.29} ] } ] } ] }}  

I have only really known about overlays for 24 hours, but this sounds like a good plan to me.

My only question is (as I don't play in this space much), what's the issue with having these enabled by default? and what benefit are you getting by making this disabled with a toggle? From a user experience perspective, there is then an additional step (armbian-config) to make this 'work', but I assume there is a benefit such a memory or power efficiency perspective for having these off if they aren't in use?

I would really like the overlays to be named h61x if they apply to both 616 and 618.. but I haven't thought too deeply about that. As long as we are happy with h618 always matching the h616 due to the fact that they are pin compatible as @Gunjan Gupta says, I guess we stay with h616 to avoid changing thing unnecessarily.
 
@Stephen Graf I am happy to take up your offer of you figuring it out, as you seem well versed in this part of the board. If you would like me to do a rebuild where those components are removed from the base configuration (so you can move them to overlays), I can do that on my i2c3 branch in github if you like, based on the list you have provided, just let me know.. as I am keen to assist where I can.

As always, thanks to the assistance and feedback everyone, it's been an excellent help in gaining understanding of the board and Armbian and I am sure others following along will also get value out of this information.

As h616 and h618 are suppose to be pin compatible, same overlays should work between the same

I just finished testing with the build you supplied and it worked as expected.  I have a temperature & pressure sensor on an 12c device that I connect to the zero3 header and then read it with rust code.
There are i2c tools installed on the image that you can use to interrogate the i2c system:
 
root@orangepizero3:~# i2cdetect -l
i2c-0   i2c             mv64xxx_i2c adapter                     I2C adapter
i2c-1   i2c             DesignWare HDMI                         I2C adapter
i2c-2   i2c             mv64xxx_i2c adapter                     I2C adapter
root@orangepizero3:~# i2cdetect 2
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-2.
I will probe address range 0x08-0x77.
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- 38 -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
root@orangepizero3:~#
 
I think there are 2 i2c systems used internally by the zero3.  The i2c3 that we are working on became i2c-2 as enumerated by linux. My device shows up as address 38 on the scan.
 
Thank you for your work adding the patch.

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.

I'm using Orange Pi Zero 3 1GB.
XFCE version works just fine. There are some glitches as you stated before, it happened to mouse cursor.
Video test
 

Glad to hear that my feedback was useful. Let me know if there is anything certainly interesting I could test. I'll maybe play around with more network stuff like vlan (docker ipvlan) but not sure If this is something where you would expect to see issues.
 
So thanks again for all your effort and happy new year to all of you.

Yeah I see what you mean. But then orangepi zero is a 32-bit device, so the developer might have thought that it would be obvious that a dtsi in arm64 directory will not be applicable to the same.

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.