ag123

@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
@vtech,
you may like to try the same for orange pi zero 2

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 93D6889F9F0E78D5 observed 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 size
 
repeat 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 93D6889F9F0E78D5 observed 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 size
 
repeat apt update etc should have resolved the error

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://github.com/dell/dkms
https://wiki.gentoo.org/wiki/DKMS
https://www.collabora.com/news-and-blog/blog/2021/05/05/quick-hack-patching-kernel-module-using-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.

@Igor
I have been using uboot V2025.04(2025-snuxi) on orangepi zero2w since 19 April and everything is works as it should no problems.
 
https://github.com/ZjemCiKolege/build/commit/b3eaeb7d2059c3429951da7e6022c9528237c0e7
 
 

@av4625 
there is one experiment that I did not try which is to play with wpa_supplicant with its own /etc/wpa_supplicant.conf 
if it works, it'd likely point to a problem in network manager itself, possibly that network manager is sending the 'wrong' commands.
 
However, as I couldn't figure out how to work that with network manager, possibly conflicts since network manager is intended to control it via the unix socket?
redoing the 'whole' thing by having network manager unmanage the wifi interface is another test, but I did not try that due to the effort involved.
 

@av4625 
here are some of my thoughts, as discussed prior, wpa_supplicant and / or hostapd is The 'library' that does *all* of WPA/WPA2/WPA3
https://w1.fi/wpa_supplicant/devel/
The design goal for wpa_supplicant was to use hardware, driver, and OS independent, portable C code for all WPA functionality The design goal for hostapd was to use hardware, driver, and OS independent, portable C code for all WPA functionality.  
That means selecting either wpa_supplicant or hostapd would provide the wifi AP functionality specifically for WPA / WPA2 and authentication.
Using hostapd apparently has 'better' logging as the access attempt is logged 
journalctl -u hostapd there are some messages, some abstracts from my logs
STA mac_addr IEEE 802.11: associated STA mac_addr RADIUS: starting accounting session 63AA93B230BE083E STA mac_addr WPA: pairwise key handshake completed (RSN) STA mac_addr WPA: group key handshake completed (RSN) STA mac_addr IEEE 802.11: disassociated this helps ascertain that the connection / WPA / WPA2 is established and authentication is successful
 
From prior discussions, it seemed NetworkManager uses wpa_supplicant. In my case, I find the lack of logs 'opaque' and lacks info for adequate troubleshooting.
I'm also unsure if I can adequately separate the concerns with Network Manager with an AP, i.e. hostapd itself (for WPA/WPA2 and authentication), then dhcp to provide (to connecting clients) ip address and dns address, ipv6 router advertisements etc and in addition to setup a bridge separate from the wifi interface itself.
And in part, hostapd apparently provides significantly more detailed configuration, in particular for the various features supported by wifi itself.
https://web.mit.edu/freebsd/head/contrib/wpa/hostapd/hostapd.conf
Hence, I choose to use hostapd instead.
However, given those documentations, https://w1.fi/wpa_supplicant/devel/, it'd seem that hostapd and wpa_supplicant are likely equivalent. just that i'm more familiar with hostapd currently.
 
Hence, in my setup. I've Network Manager omit setting up the wifi interface.
 /etc/NetworkManager/conf.d/99-unmanaged-devices.conf
[keyfile] unmanaged-devices=interface-name:wlan0  
Network manager, however, is used to setup the bridge and manage the ethernet interface, configured using nmcli.
Then hostapd is configured to patch the wifi interface into the bridge after hostapd is running.
/etc/hostapd/hostapd.conf
bridge=br0  
Networkmanager configuration of the bridge looks like this
> nmcli c NAME UUID TYPE DEVICE bridge d0fc7d8a-51ea-4c5d-a297-943e2a037cff bridge br0 lo 59201f46-2fff-4f67-9822-7019cea62cf5 loopback lo br-eth 29c02c5c-4d75-4e03-bb71-8a761e076562 ethernet end0 > sudo brctl show bridge name bridge id STP enabled interfaces br0 8000.xxyy yes end0 wlan0 Here, wlan0 is patched into the bridge by hostapd. Note the race condition issue discussed 3 comments prior.
 
The ethernet connection should be visible in NetworkManager in the default configuration e.g. as "Wired connection 1"
 
Then to setup the bridge I used a bunch of nmcli commands
https://gist.github.com/ag88/de02933ba65500376d1ff48e504b1bf3
nmcli con down "Wired connection 1" nmcli con del "Wired connection 1" nmcli con add connection.id bridge type bridge ifname br0 nmcli con add connection.id br-eth type bridge-slave ifname end0 master br0 #this is for dynamic (dhcp IP address) #nmcli c modify bridge ipv4.method auto #this is for fixed ip address, and assume that your gateway router is at 192.168.1.1 nmcli c modify bridge ipv4.method manual ipv4.addresses 192.168.1.10/24 ipv4.gateway 192.168.1.1 In the above I removed the default Ethernet connection and replaced that with a bridge setup.
The above can only be done via a 'usb-uart serial debug' bridge/dongle on the 3 serial pins for the serial console. i.e. you can't work from ssh into the ethernet connection and change the network configs.
 
This is for the bridged setup. For a routed setup, my thoughts are that the 'missing' things are 
configure ip address and routing for the wifi (wlan0) interface (this would need to be done outside NetworkManager if it isn't managing it) run a dhcp server to provide connecting clients with ip address and dns address (this can be provided by dnsmasq or a dhcp server (e.g. isc-dhcp-server). 
(other services to run can included ipv6 router advertisements (radvd or dnsmasq does that), avahi (multi-cast DNS) etc) configure 'upstream' routing / forwarding through the ethernet (end0) Those are covered to some extent in the prior discussions.
 
If you managed to run a succcessful setup say with hostapd, my guess is that you could likely migrate/convert that into a completely NetworkManager setup which uses wpa_supplicant internally.
It could possibly be 'less verbose' as compared to these setups which requires a lot of additional manual configuration as like above.
 

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

it seemed possible that WPA is used after all (even with hostapd)
wlan0: STA mac_add IEEE 802.11: associated wlan0: STA mac_add RADIUS: starting accounting session EC98EEE1B63146E8 wlan0: STA mac_add WPA: pairwise key handshake completed (RSN) wlan0: STA mac_add IEEE 802.11: disassociated  
I'm using
wifi-sec.key-mgmt wpa-psk as well
 
the documentation shown with "describe" command in your run literally says "wpa2 + wpa3 personal", but it seemed wpa is used instead
 
in my hostapd.conf
# 1=wpa, 2=wep, 3=both auth_algs=1 # WPA2 only wpa=2 wpa_key_mgmt=WPA-PSK rsn_pairwise=CCMP  
it is uncertain here if that message literally means wpa or that actually wpa2 is used. 
https://wireless.wiki.kernel.org/en/users/documentation/hostapd
 
apparently RSN is probably WPA2
-----
apparently there is one more configuration option in Networkmanager
https://people.freedesktop.org/~lkundrak/nm-dbus-api/nm-settings.html
Table 30. 802-11-wireless-security setting
pairwise array of string [] A list of pairwise encryption algorithms which prevents connections to Wi-Fi networks that do not utilize one of the algorithms in the list. For maximum compatibility leave this property empty. Each list element may be one of "tkip" or "ccmp". proto array of string [] List of strings specifying the allowed WPA protocol versions to use. Each element may be one "wpa" (allow WPA) or "rsn" (allow WPA2/RSN). If not specified, both WPA and RSN connections are allowed.  
based on these descriptions it is likely that if "proto" is not specified both wpa and wpa2 (RSN) is allowed.
 
my guess is the connecting device (e.g. phone)  would choose the preferable more secure protocol e.g. wpa2
 
nevertheless, you may like to tweak them to see if that helps

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
 

@voapilro @bjorn @Long-Johnny, all
psst some fun stuff
https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/
ok that's the 2nd attempt to create a custom u-boot to boot Armbian on 1.5 GB OPi Zero 3 boards, do visit the repository for more info.
 
first you can try that with the 'official' image
https://www.armbian.com/orange-pi-zero-3/
but that this u-boot is build from mainline u-boot at the 2024.04 release
https://gitlab.com/u-boot/u-boot
and that it requires a working /boot/boot.scr or /boot/boot.cmd to boot linux. /boot/boot.scr or /boot/boot.cmd are the boot scripts that actually has u-boot commands which loads the kernel and dependencies and boot linux.
if the boot drops you into a command shell, it could mean either that the /boot/boot.scr or /boot/boot.cmd is invalid or that it is using a *custom* u-boot and the /boot/boot.cmd, /boot/boot.scr uses or is expecting some variables that is not there in 'standard' mainline u-boot.
I managed to boot to the Linux command prompt this time !
 
I'd just like to say that I took the Armbian Bookworm minimal image from the Armbian release web for Orange Pi Zero 3
Armbian_community 24.5.0-trunk.474 6.6.28 
https://www.armbian.com/orange-pi-zero-3/
did my u-boot patch, run it on my 1.5 GB Orange Pi Zero 3 and it booted to the prompt! and just right now
 
Here is a screenshot running from Orange Pi Zero 3 - 1.5 GB board tethered from usb-uart to debug console, I ran the command 'free' which shows that the total memory is 1.5GB
how about that for a proof-of-concept 
without this u-boot 'patch' u'd get 'stuck' at the boot reporting 2GB seen on the usb-uart debug console for the 1.5GB board.
 

 
men I feel like celebrating, now Armbian runs on 'all variants' of Orange Pi Zero 3 - 1 GB / 1.5 GB (with this hack) / 2 GB / 4GB 

in a normal case, files in your home directory should belong to you except ..

@ag123 I have been doing a lot of tests using official Orange Pi Zero 3 SDK following instructions here, and I think a got a way to detect the right memory size. I was not able to fix random memory size detection yet, so it would be next.
 
Anyway, what I saw is that current memory size detection is based on top address wap around to base address. It works well for 1GB, 2GB and 4GB, but not for 1.5GB, as it is not even tried by this method. So I tried to write something to 1.5GB memory address and looking around memory to find a match, and I did not find anything. Instead what I got is that address maps to nowhere, because writing something and then reading once an again, what I got was a kind of random values. And based on that I coded a memory size fix.
 
First of all I need a funcion to check top memory:
bool mctl_mem_matches_top(ulong offset) { static const unsigned value= 0xaa55aa55; /* Take last usable memory address */ offset -= sizeof(unsigned); dsb(); /* Set zero at last usable memory address */ writel(0, (ulong)CONFIG_SYS_SDRAM_BASE + offset); dsb(); /* Set other value at last usable memory address */ writel(value, (ulong)CONFIG_SYS_SDRAM_BASE + offset); dsb(); /* Check if the same value is actually observed when reading back */ return readl((ulong)CONFIG_SYS_SDRAM_BASE + offset) == value; }  
And then just use it to fix memory size:
static unsigned long mctl_calc_size(struct dram_para *para) { u8 width = para->bus_full_width ? 4 : 2; unsigned long size; /* 8 banks */ size = (1ULL << (para->cols + para->rows + 3)) * width * para->ranks; /* Fix size if last usable memory address is not valid */ if (!mctl_mem_matches_top(size)) size = (size * 3) / 4; return size; }  

I kinda remember that in the original image, u-boot can be extracted from there the same way posted a few comments earlier, that with the u-boot SPL bin file and instructions.
 
I looked at the /boot/boot.cmd from the some-files-from-boot-folder archive
 
thoughts are that things could have changed between u-boot versions as new u-boot versions 'advanced' till today, 
though I'm not sure if Orange Pi could have made some customizations in u-boot (the actual core u-boot code itself) so that the /boot/boot.cmd works the way they wanted it.
e.g. that some of the 'environment variables' may not be there in the 'standard' u-boot. that could cause the boot script to fail and hence what you saw.
to get things back on track, I'd guess restoring the old u-boot could be a simplest resort, but the 'old' 1.5g issue stays with that u-boot.
 
to be upfront, I'm learning all these new as well, u-boot basically run a bunch of scripts within the 'environment (with variables)', u-boot's own (specialized) shell commands / scripts.
there is a bunch of scripts (environment (variables)) in the 'standard' core, then along the way core u-boot scripts evaluates/calls the scripts in /boot/boot.scr (if it exists), if not /boot/boot.cmd directly, that enables u-boot to 'pass' 'environment variables' between the core u-boot to the scripts in /boot/boot.cmd in the linux root partition. this will more than likely break things (e.g. script fail) when u-boot tries to run a /boot/boot.cmd that use 'environment variables' not there in the 'standard'. of course, this technique is 'powerful', everything is 'black magic' - undocumented, can vary with every different implementation of /boot/boot.cmd in infinite number of permutations (e.g. you can always add a variable in core u-boot for your hardware, then reference it in the /boot/boot.cmd (or /boot/boot.scr), then a 'standard' implementation would simply throw error once it reach there.
not that it is 'wrong', but that that is the state of the art, 'bleeding edge' if you'd like to call it. that is the state of the art of the embedded world infinite permutations of permutations and no 2 of them are 'standard'.
raspberry pi uses u-boot as well, so do a 'thousand' other soc and boards and no 2 u-boot implementation is 'the same', among all of all of them.
 

@voapilro @bjorn @Long-Johnny, all
psst some fun stuff
https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/
ok that's the 2nd attempt to create a custom u-boot to boot Armbian on 1.5 GB OPi Zero 3 boards, do visit the repository for more info.
 
first you can try that with the 'official' image
https://www.armbian.com/orange-pi-zero-3/
but that this u-boot is build from mainline u-boot at the 2024.04 release
https://gitlab.com/u-boot/u-boot
and that it requires a working /boot/boot.scr or /boot/boot.cmd to boot linux. /boot/boot.scr or /boot/boot.cmd are the boot scripts that actually has u-boot commands which loads the kernel and dependencies and boot linux.
if the boot drops you into a command shell, it could mean either that the /boot/boot.scr or /boot/boot.cmd is invalid or that it is using a *custom* u-boot and the /boot/boot.cmd, /boot/boot.scr uses or is expecting some variables that is not there in 'standard' mainline u-boot.
I managed to boot to the Linux command prompt this time !
 
I'd just like to say that I took the Armbian Bookworm minimal image from the Armbian release web for Orange Pi Zero 3
Armbian_community 24.5.0-trunk.474 6.6.28 
https://www.armbian.com/orange-pi-zero-3/
did my u-boot patch, run it on my 1.5 GB Orange Pi Zero 3 and it booted to the prompt! and just right now
 
Here is a screenshot running from Orange Pi Zero 3 - 1.5 GB board tethered from usb-uart to debug console, I ran the command 'free' which shows that the total memory is 1.5GB
how about that for a proof-of-concept 
without this u-boot 'patch' u'd get 'stuck' at the boot reporting 2GB seen on the usb-uart debug console for the 1.5GB board.
 

 
men I feel like celebrating, now Armbian runs on 'all variants' of Orange Pi Zero 3 - 1 GB / 1.5 GB (with this hack) / 2 GB / 4GB 

@voapilro @bjorn @Long-Johnny, all
psst some fun stuff
https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/
ok that's the 2nd attempt to create a custom u-boot to boot Armbian on 1.5 GB OPi Zero 3 boards, do visit the repository for more info.
 
first you can try that with the 'official' image
https://www.armbian.com/orange-pi-zero-3/
but that this u-boot is build from mainline u-boot at the 2024.04 release
https://gitlab.com/u-boot/u-boot
and that it requires a working /boot/boot.scr or /boot/boot.cmd to boot linux. /boot/boot.scr or /boot/boot.cmd are the boot scripts that actually has u-boot commands which loads the kernel and dependencies and boot linux.
if the boot drops you into a command shell, it could mean either that the /boot/boot.scr or /boot/boot.cmd is invalid or that it is using a *custom* u-boot and the /boot/boot.cmd, /boot/boot.scr uses or is expecting some variables that is not there in 'standard' mainline u-boot.
I managed to boot to the Linux command prompt this time !
 
I'd just like to say that I took the Armbian Bookworm minimal image from the Armbian release web for Orange Pi Zero 3
Armbian_community 24.5.0-trunk.474 6.6.28 
https://www.armbian.com/orange-pi-zero-3/
did my u-boot patch, run it on my 1.5 GB Orange Pi Zero 3 and it booted to the prompt! and just right now
 
Here is a screenshot running from Orange Pi Zero 3 - 1.5 GB board tethered from usb-uart to debug console, I ran the command 'free' which shows that the total memory is 1.5GB
how about that for a proof-of-concept 
without this u-boot 'patch' u'd get 'stuck' at the boot reporting 2GB seen on the usb-uart debug console for the 1.5GB board.
 

 
men I feel like celebrating, now Armbian runs on 'all variants' of Orange Pi Zero 3 - 1 GB / 1.5 GB (with this hack) / 2 GB / 4GB 

@voapilro orange pi's suffer from a few things, in particular poor software support and if you have an issue and goto their forums
http://www.orangepi.org/orangepibbsen/
you can see a lot of no responses, spams etc. and that for the 'official' images you have obtained, those are the relevant support forums as they are different from Armbian today.
The images released from Orange Pi are linux kernel versions 6.1 which has yet been updated, nothing 'wrong' about it, but that linux version progress is relentless.
in fact Orange Pi Zero 3 (and a little later Zero 2W) is supported out of mainline linux from kernel release 6.6, i.e. the DTS (device tree configuration) is released open sourced.
And that the implementation from mainline is completely developed open sourced (by various talented individuals outside here in linux-sunxi i think, and subsequently the few of us here siezed on the opportunity and tried to make Armbian run on it, browse the earlier part of this thread and you see @Gunjan Gupta, @pixdrift, @Stephen Graf et.al working this, we also found that a lot of things are undocumented and it is a *miracle* that it is after all running (well) today.
try getting a 1G / 2G / 4G board and run Armbian on it.
https://www.armbian.com/orange-pi-zero-3/
And I'd like to add that Armbian itself @Igor and team contributes in no small measure that makes this project possible (just consider catching up with the linux versions with so many platforms to carry), considering that there is no 'big company' (e.g. Intel, Rpi etc) behind this. it is all little contributors whom you see here.
 
In this sense, the users of Armbian are the contributors and maintainers as well, a co-operative, practically the spirit of open source, if after all that economic model works.
A good thing is that you can literally build ths whole thing (the images for your board from *source*)
https://github.com/armbian/build
you can configure all the kernel parameters for all you want for the build, edit the source codes, fix bugs, add features etc, there are many 'upstream' projects which include the linux kernel itself, u-boot, the distributions Debian / Ubuntu that contributes into the assembly, probably others as well, and the armbian build framework at this day is huge and complex considering the platforms (boards) that is supported.
This probably also matter to 'security conscious' people who want to know every nut that is in there. But that it is up to you to make the effort to inspect that there are no 'holes' (e.g. trojans, backdoors, connecting to 'unauthorized' C2 (command and control) sites that you don't want etc). e.g. you can inspect and tweak all you want and afterwards run the build.
 
And not least being open sourced means that it is nearly / practically *bare metal*, the codes work the metal (transistors / silicion / registers) directly, no blobs in-between.
The trouble with blobs is your app is release to you as a binary, the driver is a binary (blob), then a new os (e.g. linux version, you can even consider windows) is released, now your binary app and or driver no longer works in the new os version (linux or windows), and you can use your device (e.g. mouse) as your new door stop. buy a new one and again more binaries , more device driver blobs.
 
 
 

@thuvasooriya wrote
 
hi if you review this thread, the earlier comments, you would notice that there are quite varous discussions about DTS overlays for the gpio headers. noticably discussions from / between
@Gunjan Gupta @pixdrift @Stephen Graf. Unfortunately, it seemed for now not all the changes have made it into the trunk.
 
there are also various discussions about libgpiod and gpiod, hope those may help with access to the pins.
 
 
 
 
 
 

@thuvasooriya wrote
 
rather than to use HDMI and a monitor, I used a usb-uart (usb-serial) dongle
that lets me connect over the serial console with the debug pins and I'm literally able to boot up in a serial console and (even) configure networking, i.e. I didn't even need network and can change the network interface configurations. That would also be a way to troubleshoot boot up problems if there is. I used the serial debug pins/console to configure networking as more than often, the default setup of network isn't what I want, and playing with the network interfaces will lock me out of ssh.
 
After I've network configured over usb-uart, I can then ssh remotely into the device over the network.
And that if you use dynamic IP, it may help to install and use avahi-daemon and avahi-tools (i.e. multicast DNS), I installed avahi-daemon on the OPi Z3 Armbian board so that I can find it from my main linux box using avahi-browse -a , and that ssh into there could be simply ssh orangepizero3.local  
 
that's a way to practically use it headless , in fact, after I've setup things, it is now my  WiFi AP on the desk.
 
 

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

the 'community' one is here, scroll right to the bottom
https://www.armbian.com/orange-pi-zero-3/
and the kernel version is at least 6.6 and above
 
apparently someone has seen the same , so it isn't 'new'
https://www.linux.org/threads/protocol-0000-is-buggy-dev-wlan0.42774/
 
if one google around the web one may stumble into this
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
 
it could mean a device you have is sending out goofy packets that are not regular IP packets. the normal protocols used are usually TCP, UDP and ICMP.
 

@Long-Johnny
Rather than to say 'never solved', we (as a community) need to learn about *uboot*
https://docs.u-boot.org/en/latest/
https://linux-sunxi.org/U-Boot
this is practically the *BIOS* for these little boards that we use and that u-boot boots Linux - it is the boot loader.
Once you / we find a way to pass that memory size to *uboot*, then it is a matter of learning to configure a file e.g. edit a DTS overlay to encode the memory size.
And there you have it, a fully supported board.
But that that step/procedure may have to be manually done by hand.
In that sense, once one figures this out, one can manually configure these boards for any arbitrary memory size.
 

@robertoj, all,
 
apparently, it may be possible to name the lines in the DTS
https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/gpio/gpiolib.c?h=v6.7.4#n456
 
Example: gpio-controller@00000000 { compatible = "foo"; reg = <0x00000000 0x1000>; gpio-controller; #gpio-cells = <2>; ngpios = <18>; gpio-reserved-ranges = <0 4>, <12 2>; gpio-line-names = "MMC-CD", "MMC-WP", "VDD eth", "RST eth", "LED R", "LED G", "LED B", "Col A", "Col B", "Col C", "Col D", "Row A", "Row B", "Row C", "Row D", "NMI button", "poweroff", "reset";  
I'm not sure though if the gpio-line-names assignment can be used in pin-control devices that is currently present in the existing DTS.
 
note also that the line/pin functions are actually defined in the source codes for the pin-control driver, just that this won't automatically appear as gpio-line-names.
 
you may want to start experimenting, post your findings and perhaps make a PR?
 
note that there is another source tree to commit though , which is in linux-sunxi - that would be directly mainlining / upstreaming the changes.
https://linux-sunxi.org/Main_Page
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/
they have a google groups here:
https://groups.google.com/g/linux-sunxi
https://linux-sunxi.org/Mailing_list
 
I'm not too sure about the procedure to commit changes in mainline though.