ag123

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

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

"legacy" is a term that thas been established years ago when there wasn't much confusion about it. However things have changed and now it is, depending on board family, either an old-LTS just for historical purpose or a vendor kernel which may or may not significantly outdated but working.
Anyway there are discussion about renaming that into "vendor" or something, however the impact would be huge if not done carefully.
 
If anyone steps up doing, testing and maintaining this, why not? We won't simply due to lack of human resources.

Thats becuase loading overlays from configfs is something that was viewed as not a recommended way and hence was not merged into the kernel. If you still wants to do the same, I believe our Allwinner kernels do have a patch that adds that functionality. Not sure if the same can be said for every soc family supported by Armbian. Also I am not sure if loading overlay via configfs is ever tested and hence cant say how well that works.

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

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

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

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