ag123

@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.

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

The most recent CI job got failed in the stage that updates the website. Hence the image got missing from the web page. It will be back in few hours. Until then you can download them from the link that @ag123shared above.
 
The CI jobs finds what board images need to be rebuilt based on the changes made in the build repository. As there are no changes merged for zero3 in last two days, no new Images were generated for the same.

There is actually no need to build the image yourself. You can just download the latest nightly release from https://github.com/armbian/os/releases/latest

here is some 2 cents comments, if you are meaning NPUs like these:
 
https://github.com/rockchip-linux/rknpu2
 
- hardware interfaces are kept as trade secrets and not published anywhere
 
1st the hardware interfaces are practically undocumented, what they provide is mostly an 'sdk' with some binary blobs
it practically means there is *no way* to use the NPU as those binary blobs in turn depend on device drivers which again are binary blobs (no source)
and there is no hardware documentation any where about the technical details, registers etc. 
if that at least those are published, one could possibly start coding something to test things on the NPU.
 
then that for things like ethos-n78
https://www.arm.com/products/silicon-ip-cpu/ethos/ethos-n78
you can find some info here
https://developer.arm.com/Processors/Ethos-N78
but that it seemed the real SOCs with that chip is no where to be seen let alone any boards found with them.
 
- IO / cpu scheduling 
 
cpu frequency scaling / governors are well documented
https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt
https://docs.kernel.org/scheduler/schedutil.html
https://www.kernel.org/doc/html/latest/scheduler/
and for 'simple' ARM (or RISC V) chips, any sort of 'elaborate' scheduling are probably going to just burn more cpu cycles with little to gain.
but that nevertheless the source codes and the documentations are there so that one can try to develop your own governor if you prefer.
and that the elaborate 'advanced' schedutil governor is already there in the kernel, likely in Armbian as well.
Hence, one can proceed to improve that if one deem that the state-of-the-art currently isn't adequate.
 
and if one wants to do some manual scheduling there is the plain old "nice" command
https://www.scaler.com/topics/linux-nice/
 
----
well my thoughts, scheduling and NPU are 2 unrelated issues, it is possible to handle 'elaborate' scheduling without an NPU, this is currently the state-of-the-art from the 'lowly' ARM boards that we are running, to top tier high core count Intel Xeon / AMD Epyc processors and running all that loads ranging from amazon, google, chatgpt etc, no issues.
 
The other thing being the NPUs itself, currently many SOC IP owners, held their hardware interfaces as *trade secrets* and refused to release them.
You would need to jump that hoop to even use the NPU without any documentation, or else use their proprietary binary blob software, which won't work outside their proprietary binary blob distributions.
 
This withheld *trade secret* about the NPU is the biggest pitfall / trap to those buying those boards with those SOCs and wanting to use the NPU. you get *no support*, *no help*, *no nothing* after you buy the board which purportedly has the NPU. practically *useless*. don't even bother to try it for any 'test' 'AI' stuff, you may at best get a *binary blob demo* and that's it (and it is not anywhere close to even using it for any practical purpose, let alone scheduling).
 
And much more than that, using an NPU practically means that your neural network model must be *quantized*, if you know what that means. All those small NPU hardware normally handles like 8 bit integers, 16 bit integers or at best 16 bit floats. This practically means that you would need to spend a lot of effort to *convert* even ordinary neural networks into the *quantized* form that can be processed by the NPU, if you can't convert that it is  unusable. Even if you managed to convert that there is a risk of lost of precision, e.g. if you convert a 32 bit float down to an 8 bit int, you may practically be quantizing a number space of 4 billion numbers (actually more) to 256 quantized levels. that is the extreme of the information loss, and at the end of the day, if it even works, you may simply get *wrong* results, and again it is practically *useless*.
 

here is some 2 cents comments, if you are meaning NPUs like these:
 
https://github.com/rockchip-linux/rknpu2
 
- hardware interfaces are kept as trade secrets and not published anywhere
 
1st the hardware interfaces are practically undocumented, what they provide is mostly an 'sdk' with some binary blobs
it practically means there is *no way* to use the NPU as those binary blobs in turn depend on device drivers which again are binary blobs (no source)
and there is no hardware documentation any where about the technical details, registers etc. 
if that at least those are published, one could possibly start coding something to test things on the NPU.
 
then that for things like ethos-n78
https://www.arm.com/products/silicon-ip-cpu/ethos/ethos-n78
you can find some info here
https://developer.arm.com/Processors/Ethos-N78
but that it seemed the real SOCs with that chip is no where to be seen let alone any boards found with them.
 
- IO / cpu scheduling 
 
cpu frequency scaling / governors are well documented
https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt
https://docs.kernel.org/scheduler/schedutil.html
https://www.kernel.org/doc/html/latest/scheduler/
and for 'simple' ARM (or RISC V) chips, any sort of 'elaborate' scheduling are probably going to just burn more cpu cycles with little to gain.
but that nevertheless the source codes and the documentations are there so that one can try to develop your own governor if you prefer.
and that the elaborate 'advanced' schedutil governor is already there in the kernel, likely in Armbian as well.
Hence, one can proceed to improve that if one deem that the state-of-the-art currently isn't adequate.
 
and if one wants to do some manual scheduling there is the plain old "nice" command
https://www.scaler.com/topics/linux-nice/
 
----
well my thoughts, scheduling and NPU are 2 unrelated issues, it is possible to handle 'elaborate' scheduling without an NPU, this is currently the state-of-the-art from the 'lowly' ARM boards that we are running, to top tier high core count Intel Xeon / AMD Epyc processors and running all that loads ranging from amazon, google, chatgpt etc, no issues.
 
The other thing being the NPUs itself, currently many SOC IP owners, held their hardware interfaces as *trade secrets* and refused to release them.
You would need to jump that hoop to even use the NPU without any documentation, or else use their proprietary binary blob software, which won't work outside their proprietary binary blob distributions.
 
This withheld *trade secret* about the NPU is the biggest pitfall / trap to those buying those boards with those SOCs and wanting to use the NPU. you get *no support*, *no help*, *no nothing* after you buy the board which purportedly has the NPU. practically *useless*. don't even bother to try it for any 'test' 'AI' stuff, you may at best get a *binary blob demo* and that's it (and it is not anywhere close to even using it for any practical purpose, let alone scheduling).
 
And much more than that, using an NPU practically means that your neural network model must be *quantized*, if you know what that means. All those small NPU hardware normally handles like 8 bit integers, 16 bit integers or at best 16 bit floats. This practically means that you would need to spend a lot of effort to *convert* even ordinary neural networks into the *quantized* form that can be processed by the NPU, if you can't convert that it is  unusable. Even if you managed to convert that there is a risk of lost of precision, e.g. if you convert a 32 bit float down to an 8 bit int, you may practically be quantizing a number space of 4 billion numbers (actually more) to 256 quantized levels. that is the extreme of the information loss, and at the end of the day, if it even works, you may simply get *wrong* results, and again it is practically *useless*.