ag123
-
Posts
340 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by ag123
-
-
I've some old boards too e.g.
https://www.armbian.com/orange-pi-one/
interestingly there is an updated image for it, but that things I remember there are lots of gotcha unlike the whole many generation of incremental improvements between boards that finally evolved into a opi z3.
among the gotchas on orangepi one and orangepi pc h3 is that it uses a proprietary openrisc chip for power off which back then, if you run poweroff, the cpu will instead become very hot rapidly and you have to pull the usb cable quickly.
today there is this thing crust which i've not yet tried which is deemed to be able to orderly shutdown the soc
https://github.com/crust-firmware/crust
opi z3 uses a PMIC with its own internal firmware and I think it is comms i2c etc that starts the shutdown process.
things are different between the generations (of boards and kernel)
---
my guess is to try a new u-boot, it may take doing a build
and the changes may be quite similar to this
https://github.com/armbian/build/pull/8334
https://github.com/armbian/build/pull/8334/commits/49ccbe88bc2ddf31b55ece850d28ef18c6ae8a1a
---
if you want to venture and experiment with just u-boot alone
here is how I once tried
https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3
https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/blob/main/build.md
-
just like to say that the recent images
works just well
_ _ _ _ _ /_\ _ _ _ __ | |__(_)__ _ _ _ __ ___ _ __ _ __ _ _ _ _ (_) |_ _ _ / _ \| '_| ' \| '_ \ / _` | ' \ / _/ _ \ ' \| ' \ || | ' \| | _| || | /_/ \_\_| |_|_|_|_.__/_\__,_|_||_|_\__\___/_|_|_|_|_|_\_,_|_||_|_|\__|\_, | |___| |__/ v25.8 rolling for Orange Pi Zero3 running Armbian Linux 6.12.35-current-sunxi64 Packages: Debian stable (bookworm) Support: for advanced users (rolling release) IPv4: (LAN) xxx.xxx.xxx.xxx (WAN) yyy.yyy.yyy.yyy IPv6: fd00:xxxx:xxxx::xxxx:xxxx (WAN) xxxx:xxxx::yyyy:yyyy WiFi AP: SSID: (ssid), Performance: Load: 2% Uptime: 3:50 Memory usage: 4% of 3.83G CPU temp: 41°C Usage of /: 3% of 58G RX today: 7 MiB Commands: Configuration : armbian-config Monitoring : htop
-
this is somewhat 'off-topic' but still relevant to 'orange pi zero 3'
If Orange Pi Zero 3 is operated in warm climates (e.g. room temperature 30 deg C etc) , it can at times run up to like 60 deg C.
this is in open still air
adding a fan blowing at it reduce that by some 20 deg C to 40 deg C !
And this is my ghetto fan setup, no fancy case, no heatsink nothing, just a single long machine screw that lifts it up
checking temperatures is easy
> armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq Tcpu C.St. 18:03:39 480 MHz 0.00 0% 0% 0% 0% 0% 0% 40.8 °C 0/7^C
strictly speaking, 60 deg C is 'nothing to scream about' , I've a Rpi 4 hitting up 80 deg C and it throttles.
similarly use a fan blowing at it + a heat sink over the cpu, drastically reduce running temperatures.for 'occasional' use, I don't think it is necessary to have a fan blowing at the Orange Pi Zero 3.
I think it is feasible to run at lower temperatures if I disable and unclock the GPU and HDMI, but for now I'm not sure how to go about doing that.
Initially, I'm thinking maybe the wifi is causing it, but now I don't think so, it is moderately likely the gpu is heating it up a bit.
And still air don't seem to dissipate heat very well.
-
apparently new images for OrangePi Zero 3 Debian minimal IOT are out on github and the boards page
thanks to @Igor, @TRay, et.al.
https://www.armbian.com/orange-pi-zero-3/
https://github.com/armbian/community/releases/tag/25.8.0-trunk.309
^ apparently a big release many images ( e.g. different variants and boards) are updated, but I checked only OrangePi Zero 3 Debian minimal IOT
the feature for OrangePi Zero 3 according to recent build release
https://github.com/armbian/build/releases/tag/v25.8.0-trunk.293
is
https://github.com/armbian/build/pull/8334
the use of u-boot tag:v2025.04 likely improves boot time ddr ram size detection.
-
-
one way is if you have tested that config and build to make a pull request on github
https://github.com/armbian/build
-
I'm, using one of those CH340 based usb-uart dongles
https://www.aliexpress.com/w/wholesale-usb-uart-ch340.html
but that normally most usb-uart dongles would work
https://www.aliexpress.com/w/wholesale-usb-uart.html
just make sure to check that it has / uses 3.3V io levels. Not 5V io levels as that may damage the processor (cpu / soc)
for the pins connection review the user manual
it is the 3 pins labelled Debug TTL UART on their board photo
http://www.orangepi.org/img/zero3/0627-zero3 (6).png
---
off-topic:
for these small boards, I've basically stopped running them with an LCD monitor and keyboard as I find it a hassle as I'm using a desktop PC and trying to share the monitor. I mostly use them 'headless' using the usb-uart port.
And in fact, after you setup the network appropriately e.g. set a static IP address or install avahi, the usb-uart console is no longer needed
for static (fixed) IP address it is covered in the networking guide
https://docs.armbian.com/User-Guide_Networking/
for avahi (MDNS)
> apt install avahi-daemon avahi-utils edit /etc/avahi/avahi-daemon.conf [publish] publish-workstation=yesyou can find the board on the ethernet over MDNS
e.g.
https://github.com/hrzlgnm/mdns-browser
and you can ssh into the board over the network, e.g. using putty
-
as I've not been running X11, I can't really help with this, but among the things, check the logs during X startup (normally /var/log/*), that could lead to the cause.
note also that more recently, the display systems are running wayland rather than X11. that could cause xfce etc to fail if it is expecting an X11 based setup
it is also recommended to bootup in the uart console (debug) port using a usb-uart dongle.
- the benefits are numerous, the boot messages are mostly presented
- it provides you with a console to login and check things while the system is running
e.g. to login and check dmesg and other logs
- essential especially when re-wiring network configuration
-
there are a few caveats that may need a bit of attention
It is documented somewhere that if you use channel 0, the driver would automatically select an appropriate channel / frequency.
However, it seemed that back then initially while I tested it, that didn't seem to work. (i'm not sure if it may have changed)
hence to list the channels one needs to run
iw listand you would get a list of channels like such
* 2412 MHz [1] (20.0 dBm) * 2417 MHz [2] (20.0 dBm) * 2422 MHz [3] (20.0 dBm) * 2427 MHz [4] (20.0 dBm) * 2432 MHz [5] (20.0 dBm) * 2437 MHz [6] (20.0 dBm) * 2442 MHz [7] (20.0 dBm) * 2447 MHz [8] (20.0 dBm) * 2452 MHz [9] (20.0 dBm) * 2457 MHz [10] (20.0 dBm) * 2462 MHz [11] (20.0 dBm) * 2467 MHz [12] (20.0 dBm) * 2472 MHz [13] (20.0 dBm) * 2484 MHz [14] (20.0 dBm) * 5170 MHz [34] (disabled) * 5180 MHz [36] (20.0 dBm) * 5200 MHz [40] (20.0 dBm) * 5220 MHz [44] (20.0 dBm) * 5240 MHz [48] (20.0 dBm) * 5260 MHz [52] (20.0 dBm) (radar detection) * 5280 MHz [56] (20.0 dBm) (radar detection) ... * 5720 MHz [144] (20.0 dBm) (radar detection) * 5745 MHz [149] (20.0 dBm) * 5765 MHz [153] (20.0 dBm) * 5785 MHz [157] (20.0 dBm) * 5805 MHz [161] (20.0 dBm) * 5825 MHz [165] (20.0 dBm)what I normally do is to do a scan and pick an unused / least used channel :
iw wlan0 scanpick an appropriate channel and specify it in hostapd.conf. 5ghz channels (hw_mode=a) delivers a max throughput of like 140 Mbps which is fast.
https://docs.armbian.com/WifiPerformance/#uwe-5622
accordingly there are some country specific requirements for 5ghz channel selections and one may like review
https://en.wikipedia.org/wiki/List_of_WLAN_channels
iw reg setetc
I did a google search and some of these resources may be useful
https://wiki.archlinux.org/title/NetworkManager
https://www.baeldung.com/linux/nmcli-wap-sharing-internet
in a same way you may need to set the channel if necessary
then that this repo is found in a google search which may be useful
https://github.com/pi-top/Wi-Fi-Access-Point-and-Station-Mode/tree/master
-
accordingly H618 do not have mic in hardware
hence, an option is to use a usb soundcard / dongle
https://www.aliexpress.com/w/wholesale-usb-sound-card.html
there are also those 'arduinoish' approaches
e.g. to use a ADC module board e.g.
https://www.ti.com/lit/ds/symlink/ads1110.pdf
https://www.aliexpress.com/w/wholesale-ads1110.html
https://www.instructables.com/Arduino-and-the-TI-ADS1110-16-bit-ADC/
but that you would need to hack the pin interfaces to use i2c etc.
note it seemed ads1110 is a bit too slow for sound.
alternatives are like stm32, which has built-in adc that can go to like 1-2.5 Msps, but you would need to hack the spi interface etc.
the 'easiest / cheapest' way seemed to be generic 'usb sound cards'
-
there are some 'old' stuff that may not be fully relevant but still useful
this gist likely helps:
https://gist.github.com/ag88/de02933ba65500376d1ff48e504b1bf3
an 'old' post:
Note that currently in the minimal image netplan is set to systemd-networkd
https://docs.armbian.com/User-Guide_Networking/#minimal-images
I'm less familiar with systemd-networkd, though it is possible to setup the network fully with it.
What i did currently, is to update netplan config as above to use NetworkManager
After that I use NetworkManger to setup a bridge adding the ethernet interface.
https://gist.github.com/ag88/de02933ba65500376d1ff48e504b1bf3
.
However, I actually make NetworkManager *unmanage* the Wifi interface, because i'm using hostapd.
I'm using hostapd mainly because in journalctl logs, there is an entry for every host/client that connects. I'm not sure about how to do the same with Network Manager. hostapd also supports elaborate RADIUS authentication if one wants to go the distance.
Then I install and configure hostapd as described in the gist, and during startup, hostapd actually patch the wifi interface into the bridge that is setup with NetworkManager.. The configuration for wifi AP is completely done in hostapd.conf as described in the gist.
I'm using a bridge as DHCP is managed from my gateway router, hence I did not run a separate DHCP server instance in Orange Pi Zero 3 itself.
An alternative setup is to setup NAT (network address translation) on the Orange Pi Zero 3 and to run a DHCP server on the Orange Pi Zero 3 itself.
I think NAT approach is 'more common'
I'm using hostapd, but I think without hostapd, it is also possible to setup an AP using NetworkManager alone. i.e. to let Network Manager manage the Wifi interface, and configure it as an AP. The benefit here is that Network manager woulld likely manage the DHCP and NAT as well all from Network Manager configurations.
As I'm doing everything from the command line, I used NetworkManager cli (nmcli) for all the network manager configuration tasks.
Note that while messing with networking, it is necessary to work in the serial debug console using a usb-uart dongle.
i.e. bootup and login as root using a usb-uart dongle to the 3 'debug' pins for the serial console.
-
just like to say that I installed
Armbian_community_25.8.0-trunk.228_Orangepizero3_bookworm_current_6.12.30_minimal.img
from the boards page
https://www.armbian.com/orange-pi-zero-3/
apt update works 'out of the box', no PUBKEY errors
I really liked the new MOTD on login
_ _ _ _ _ /_\ _ _ _ __ | |__(_)__ _ _ _ __ ___ _ __ _ __ _ _ _ _ (_) |_ _ _ / _ \| '_| ' \| '_ \ / _` | ' \ / _/ _ \ ' \| ' \ || | ' \| | _| || | /_/ \_\_| |_|_|_|_.__/_\__,_|_||_|_\__\___/_|_|_|_|_|_\_,_|_||_|_|\__|\_, | |___| |__/ v25.8 rolling for Orange Pi Zero3 running Armbian Linux 6.12.30-current-sunxi64 Packages: Debian stable (bookworm) Updates: Kernel upgrade enabled and 8 packages available for upgrade Support: for advanced users (rolling release) WiFi AP: SSID: (wifi_hotspot_name), Performance: Load: 12% Up time: 0 min Memory usage: 5% of 3.83G CPU temp: 54°C Usage of /: 3% of 58G RX today: 6 MiB Commands: Configuration : armbian-config Upgrade : armbian-upgrade Monitoring : htoprunning Armbian on Orangepizero 3 makes a good desktop wifi hotspot (AP)
it counts among the fastest Wifi with UWE5622 AP on 5 ghz on 'cheap' SBC (single board computers)
https://docs.armbian.com/WifiPerformance/#uwe-5622
if you see that updates message, what is more cool is if you run
apt list --upgradableit list the packages that is upgradable, and I tried
apt upgradeinstall quite a few things, then manually
rebootit becomes 25.8.0-trunk.230 ! this can be verified in /etc/armbian-release
-
@Igor, all
just like to say that I installed
Armbian_community_25.8.0-trunk.228_Orangepizero3_bookworm_current_6.12.30_minimal.imgArmbian_community_25.8.0-trunk.228_Orangepizero3_bookworm_current_6.12.30_minimal.img
from the boards page
https://www.armbian.com/orange-pi-zero-3/
apt update works 'out of the box', no PUBKEY errors
thanks for the the updates
you may like to try the same for orange pi zero 2
-
it seemed that the (minimal/iot) images linked on the boards page , have been updated, I just downloaded Armbian_community_25.8.0-trunk.228_Orangepizero3_bookworm_current_6.12.30_minimal.img.xz
for orangepi zero 3. note I only checked debian as that is what i'm using
https://www.armbian.com/orange-pi-zero-3/ -
it seemed that the (minimal/iot) images linked on the boards page , have been updated, I just downloaded Armbian_community_25.8.0-trunk.228_Orangepizero3_bookworm_current_6.12.30_minimal.img.xz
for orangepi zero 3. note I only checked debian as that is what i'm usingit seemed to be similar for orangepi zero 2
https://www.armbian.com/orange-pi-zero-2/
-
I think using the ubuntu keyserver is good as well
but that this is a 'small' issue, it is easy to miss a small thing in a project this huge consider the number of boards, kernels, and distributions (including the different releases).
if this little thing breaks, we can fix in our installed os using these methods.
-
NO_PUBKEY 93D6889F9F0E78D5 while using apt (e.g. apt update)
symptom:> apt update ... Err:8 https://github.armbian.com/configng stable InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 93D6889F9F0E78D5 ... W: Failed to fetch https://github.armbian.com/configng/dists/stable/InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 93D6889F9F0E78D5observed in Armbian image for Orange pi zero 3 Armbian_community_25.8.0-trunk.90_Orangepizero3_bookworm_current_6.12.30_minimal.img build date May 28, 2025
fix:
- run this as root
> su - ^ login as root > wget -O - https://apt.armbian.com/armbian.key | gpg --dearmor -o /usr/share/keyrings/armbian.gpg
you should find a file /usr/share/keyrings/armbian.gpg about 2 KB in sizerepeat apt update etc should have resolved the error
-
NO_PUBKEY 93D6889F9F0E78D5 while using apt (e.g. apt update)
symptom:> apt update ... Err:8 https://github.armbian.com/configng stable InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 93D6889F9F0E78D5 ... W: Failed to fetch https://github.armbian.com/configng/dists/stable/InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 93D6889F9F0E78D5observed in Armbian image for Orange pi zero 3 Armbian_community_25.8.0-trunk.90_Orangepizero3_bookworm_current_6.12.30_minimal.img build date May 28, 2025
fix:
- run this as root
> su - ^ login as root > wget -O - https://apt.armbian.com/armbian.key | gpg --dearmor -o /usr/share/keyrings/armbian.gpg
you should find a file /usr/share/keyrings/armbian.gpg about 2 KB in sizerepeat apt update etc should have resolved the error
-
symptom:
> apt update ... Err:8 https://github.armbian.com/configng stable InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 93D6889F9F0E78D5 ... W: Failed to fetch https://github.armbian.com/configng/dists/stable/InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 93D6889F9F0E78D5observed in Armbian image for Orange pi zero 3 Armbian_community_25.8.0-trunk.90_Orangepizero3_bookworm_current_6.12.30_minimal.img build date May 28, 2025
fix:
- run this as root
> su - ^ login as root > wget -O - https://apt.armbian.com/armbian.key | gpg --dearmor -o /usr/share/keyrings/armbian.gpgyou should find a file /usr/share/keyrings/armbian.gpg about 2 KB in size
repeat apt update etc should have resolved the error
-
Quote
Just FYI why images are delayed. GitHub, which we rely our build infrastructure on, is having many troubles and builds does not start due to out of (their) resources (probably). 30 out 30 tries, I am getting
Error: Error 504: We couldn't respond to your request in time. Sorry about that. Please try resubmitting your request and contact us if the problem persists.
Perhaps this is a limitation of free tier, dunno.
no worries about the delay, I'm just adding a feedback that symptoms are observed in the orangepi zero 3 miminal images as well, I've not tried other images hence can't comment about it.
I'd likely try to reproduce the error and post my solution in this thread as well as in the orange pi zero 3 thread, possibly in the tutorials section of the forum as well
i found the solution via some google searches then, and I'd try to reproduce that.
-
Quote
Unable to reproduce. Probably date and time is out of sync.
Edit: aha, this is / was the problem:
https://github.com/armbian/build/commit/aa5526a9189097b87ada0784cff61bda85e46609Which means next week community build will have this auto-fixed.
apparently I run into a similar/same issue while using minimal / IOT images for Orange Pi Zero 3 25.8.0 Build Date: May 28, 2025 just downloaded yesterday 12 Jun 25
https://www.armbian.com/orange-pi-zero-3/
do update the links if the images are updated as well with the gpg keys files
-
DKMS is 'quite complicated' , in an attempt to understand all that 'cryptic' stuff, I went googling around
https://wiki.archlinux.org/title/Dynamic_Kernel_Module_Support
https://www.linuxjournal.com/article/6896
https://wiki.gentoo.org/wiki/DKMS
https://www.baeldung.com/linux/dynamic-kernel-module-support
https://nilrt-docs.ni.com/opkg/dkms_opkg.html
^ surprisingly I found this guide/tutorial from national instruments 'quite intuitive'
and I dug further into how to make a kernel module, well at least a 'hello world'
https://tldp.org/LDP/lkmpg/2.6/html/
https://tldp.org/LDP/lkmpg/2.6/lkmpg.pdf
The Linux Kernel Module Programming Guide
Peter Jay Salzman
Michael Burian
Ori Pomerantz
Copyright © 2001 Peter Jay Salzman---
ok I actually tried building that 'hello world' kernel module and *it works*, for practically 'ancient' 2001 instructions.
so it turns out that to compile a kernel module, you do not need to build it in the kernel source tree itself
and that is *without* DKMS, read that last 2 tldp guides: The Linux Kernel Module Programming Guide
you can try building and inserting the 'hello world' module into your kernel, no DKMS, whatever, after you build your module !
in short is it not necessary to build a kernel module within the kernel source tree itself, but that there are some procedures as spelled out
in that 2 tldp docs.
(but fast forward to today, this same instruction may not work if you are using secure boot, then a lot more complicated things like module signing gets involved, review that dkms link from dell)
-------
now back to DKMS , where does that fit in?
so it turns out that DKMS is a utility / tool / system / automation tool, to help you *rebuild the kernel module* - out of linux kernel source tree (i.e. as like the hello world module above), *without building the kernel from source itself* !
but that you need to ***rebuild the kernel module from source***(e.g. using DKMS), then all the other links above are guides that may be relevant
----
now add more complications / complexities, normally what you wanted is a *driver* , not simply a kernel module
the driver often has several parts - the kernel module itself (this is the 'easy' part, you need to build it - from source), and that does not mean having to build the kernel itself from source, but you need to build the *kernel *** module *** *.
after you build the kernel module successfully, say, then there are more blows and pitfall
these days wifi and many network hardware requires *firmware files* , these *firmware files* can consist of 'bin' (firmware binary) and configuration (some of them text files) some of these firmware stuff lives in /lib/firmware.
then that you need your kernel module, you can deem that the 'driver core' that interface the OS and interface those firmware. those firmware do not necessary run on the (host) cpu (i.e. your pc) but instead in the wifi chip itself.
this is the part that is *highly opaque*, there are so many wifi chips that are *undocumented*, the firmware is *undocumented* and if you do not have any source for your kernel module which interface the firmware to the os, you are out-of-luck.
-----
to summarise - normally, one cannot hope to take a binary kernel module install it in your current kernel and hope it 'just works'.
if that works, a lot of things such as module versions and various constraints imposed by the kernel matches that in the kernel module itself, i.e. that module is compiled specifically for that specific kernel itself !
DKMS do not solve this, DKMS only *helps you rebuild the (kernel) module *** from source *** *, (and install it optionally).
the idea is this, you have the *source* to your out of kernel source *kernel modules*, when you upgrade the kernel, e.g. such as an apt-upgrade etc, DKMS can be triggered to *rebuild the kernel module from source* (and install it) in the new kernel (binary) tree e.g. copy that into /lib/modules/{kernel version}/xxx
---
if the kernel module is part of the kernel source tree itself, it actually do not need DKMS. But that if the errors occurs after building that *kernel module* (i.e. driver) , then congrats - you found a 'bug' in the *kernel module (driver)*, and that is true even if it is out of kernel source as a DKMS build. i.e. the driver sources need to be patched to work in the new kernel.
-
Armbian_25.5.1_Orangepizero3_bookworm_current_6.12.23_mi
nimal.img.xz
below is transcript from the 'debug uart (serial)' console, via a usb-uart dongle, it is the only way to boot up with a console , if network etc is not available.U-Boot 2024.01-armbian-2024.01-S866c-P4a40-H8869-V3d5b-Bb703-R448a (May 28 2025 - 02:53:19 +0000) Allwinner Technology CPU: Allwinner H616 (SUN50I) Model: OrangePi Zero3 DRAM: 1.5 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... .... _ _ _ /_\ _ _ _ __ | |__(_)__ _ _ _ / _ \| '_| ' \| '_ \ / _` | ' \ /_/ \_\_| |_|_|_|_.__/_\__,_|_||_| v25.5.1 for Orange Pi Zero3 running Armbian Linux 6.12.23-current-sunxi64 Packages: Debian stable (bookworm) Updates: Kernel upgrade enabled and 23 packages available for upgrade Support: DIY (community maintained) IPv4: (LAN) 192.168.xxx.xxx (WAN) xxx.xxx.xxx.xxx IPv6: fd00:xxxx:xxxxx, xxxxx (WAN) xxxx Performance: Load: 18% Up time: 2 min Memory usage: 9% of 1.44G CPU temp: 50°C Usage of /: 9% of 15G Commands: Configuration : armbian-config Upgrade : armbian-upgrade Monitoring : htop root@orangepizero3:~# ping google.com PING google.com (142.250.4.138) 56(84) bytes of data. 64 bytes from sm-in-f138.1e100.net (142.250.4.138): icmp_seq=1 ttl=100 time=2.77 ms 64 bytes from sm-in-f138.1e100.net (142.250.4.138): icmp_seq=2 ttl=100 time=2.79 ms ^ ethernet works root@orangepizero3:~# ip link set wlan0 up root@orangepizero3:~# iw dev wlan0 scan BSS xxxxx freq: 24xx signal: -77 dBm ^ wifi works, at least for scanning for stations, connect and AP not yet tested^ the above is booted up on a 'rare' 1.5GB board.
repeat using the same uSD card on a 4 GB board, initially the debug usb-uart console is garbled, it seemed to be a baud rate mismatch, I'm not sure why, but after a few retry it works. Perhaps it is due to bad wires.
U-Boot 2024.01-armbian-2024.01-S866c-P4a40-H8869-V3d5b-Bb703-R448a (May 28 2025 - 02:53:19 +0000) Allwinner Technology CPU: Allwinner H616 (SUN50I) Model: OrangePi Zero3 DRAM: 4 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... ... _ _ _ /_\ _ _ _ __ | |__(_)__ _ _ _ / _ \| '_| ' \| '_ \ / _` | ' \ /_/ \_\_| |_|_|_|_.__/_\__,_|_||_| v25.5.1 for Orange Pi Zero3 running Armbian Linux 6.12.23-current-sunxi64 Packages: Debian stable (bookworm) Updates: Kernel upgrade enabled and 23 packages available for upgrade Support: DIY (community maintained) IPv4: (LAN) 192.168.xxx.xxx (WAN) xxx.xxx.xxx.xxx IPv6: fd00:xxxx:xxxxx, xxxxxxxx (WAN) xxxxxxxx Performance: Load: 12% Up time: 1 min Memory usage: 3% of 3.83G CPU temp: 46°C Usage of /: 9% of 15G Commands: Configuration : armbian-config Upgrade : armbian-upgrade Monitoring : htop root@orangepizero3:~# ping google.com PING google.com (142.251.12.139) 56(84) bytes of data. 64 bytes from se-in-f139.1e100.net (142.251.12.139): icmp_seq=1 ttl=103 time=2.69 ms 64 bytes from se-in-f139.1e100.net (142.251.12.139): icmp_seq=2 ttl=103 time=2.99 ms ^ ethernet works root@orangepizero3:~# ip link set wlan0 up root@orangepizero3:~# iw dev wlan0 scan BSS xxxxxx(on wlan0) freq: 24xx signal: -78.00 dBm ^ wifi works for scan, connect and AP not testedI'm not too sure what is the difference between v25.5.1 vs that on the boards page?
https://www.armbian.com/orange-pi-zero-3/
from those links 'current' seemed to be linked to: as of current 28 May 2025
Armbian_community_25.8.0-trunk.8_Orangepizero3_bookworm_current_6.12.23_minimal.img.xz
btw thanks much (to all contributors) for updating Armbian to 25.x for OrangePi Zero 3 (and likely means works for Zero 2W) as well.
oh frequency scaling works as well, this is on the 4GB board
root@orangepizero3:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq Tcpu C.St. 01:43:36 1416 MHz 0.00 1% 0% 0% 0% 0% 0% 47.2 °C 0/7 01:43:41 480 MHz 0.00 0% 0% 0% 0% 0% 0% 47.2 °C 0/7 01:43:46 480 MHz 0.00 0% 0% 0% 0% 0% 0% 47.4 °C 0/7 01:43:51 480 MHz 0.00 0% 0% 0% 0% 0% 0% 47.0 °C 0/7'everyone' should just get the 4GB board, make it a 'standard' lol
It is a good idea to try U-Boot v2025.04
I've got a python script which can patch u-boot binary into an Armbian .img or practically any other image file (though i've only tested this in *unofficial* armbian builds)
https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/tree/main/tools
https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3
i created it back then while researching solutions for the '1.5GB' problem back then.
Do you have the 'bin' file for u-boot that you could share say in a zip file attached here?
you can extract that 'bin' file using the 'backup' procedure documented here:
https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3?tab=readme-ov-file#how-to-use
sudo dd if=/dev/sdX of=u-boot-backup.bin bs=1024 skip=8 count=1024But that the appropriate way would be to build the full armbian image from source including u-boot etc.
Nevertheless, having the 'patched' u-boot binary would enable most here to test that by patching a distributed image file e.g. from the boards page, or from the 'test images' link as Igor has provided.
-
apparently it needs libheif
https://github.com/libvips/libvips
try
apt-cache search heif apt install libheif1
alternatively, there is libavifhttps://github.com/AOMediaCodec/libavif
I'm using libavif, built that from source, but you can nevertheless try
sudo apt install libavif15 libavif-bin libavif-dev
.png){kind=link}
Orange Pi Zero V1 and U-boot v2025.04
in Allwinner sunxi
Posted
sound is a gotcha on the opi z3, actually opi z3 has sound but output only. accordingly opi z2 has sound both input (mic) and output.
and i think for 'convenience' many would after all use a usb sound card instead, just that there is only one usb port and the other 2 is actually on the extension pins on opi z3 as do with the audio output on z3
http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-Zero-3.html
as for usb + audio extension, orangepi sells an extension board
but that accordingly without that it may be possible to hack those usb connectors
https://www.aliexpress.com/w/wholesale-usb-female-type-a-with-wire.htmll
if one is willing to go the distance with electronics,
for the microphone i did a little research and found that there are mems microphone modules around
small, compact and possibly can be easily paired with boards like z , z2 or z3
https://www.aliexpress.com/w/wholesale-mems-microphone.html
but that most of these are I2S interfaces and I'm not too sure if it is feasible
apparently it is there for output, but I'm not sure about input
https://github.com/elkoni/Opi_Zero_3_I2S3_5.4