ag123

I'd do it in a 'simplier' way, just use a new uSD card, that is partly a benefit of SBCs running on uSD cards.

https://www.phoronix.com/news/Debian-13.0-Released Debian 13 trixie released https://www.debian.org/News/2025/20250809

I just tested shutting down hostapd and restarting, it works systemctl stop hostapd.service systemctl start hostapd.service system process like hostapd should normally be properly started up and shutdown using systemd, killing the process etc may leave the kernel in inconsistent state. And maybe that's why you observe the issue. this is how I set it up https://gist.github.com/ag88/de02933ba65500376d1ff48e504b1bf3 accordingly, hostapd may require the interface to be on a bridge, I'm not sure about this, but that I'm using a (software) bridge so that the wifi interface is on it. > uname -a Linux orangepizero3a3 6.12.35-current-sunxi64 #1 SMP Fri Jun 27 10:11:46 UTC 2025 aarch64 GNU/Linux > nmcli c NAME UUID TYPE DEVICE bridge a6aa1bb8-c47e-400e-8de1-7faf96489c7a bridge br0 lo 084c74b2-0638-48be-b4c9-364f854ecabd loopback lo br-eth 6bab09b0-e16c-438b-a1bf-e0d82ca5141b ethernet end0 > sudo bridge link 2: end0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 100 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 100 I put both ethernet and wifi on the bridge, wifi is not managed by network manager, hostapd patch that into the bridge. it is possible to just let hostapd setup the bridge in hostapd.conf, and normally that's all needed. this isn't the earliest armbian I'm running hostapd in, i've done it since linux 6.6.x kernel an earlier release some 1 year back or so, no issues.

anything 'interesting' in dmesg? and what is the Armbian / kernel version? e.g. uname -a btw 'real' armbian is currently at linux version 6.12.x https://www.armbian.com/orange-pi-zero-3/ btw I disabled wpa_supplicant when I run hostapd, I'm not sure if it'd affect anything, normally hostapd should work with wpa_supplicant running should be 'no problem'. wpa_supplicant is 'connecting out', while hostapd is an AP hotspot.

try ip link set wlan0 up

Installing rpi-monitor in Armbian for Orange Pi Zero 3 https://gist.github.com/ag88/65db5434158683e43d1cc77c337ebdb5

this is posted to Gist: https://gist.github.com/ag88/65db5434158683e43d1cc77c337ebdb5 Introduction Rpi-monitor https://github.com/XavierBerger/RPi-Monitor is a very nice app for monitoring sbc (single board computers/ actually bigger computers as well) like RPi on a web. it gives you a quick look at various system metrics cpu load, uptime, temperatures etc and more on a nice web page. and on top, makes nice time series graphs for the same, practically a dashboard. Installing in Armbian 25.8 for Orange Pi Zero 3 Rpi-monitor is normally not found in the common Apt repositories and actually the binary is a little old. I tried installing it based on the 'formal' docs but hit some invalid public keys errors, possibly expired certs. https://xavierberger.github.io/RPi-Monitor-docs/11_installation.html so here is a 'workaround' Deb packages for rpi-monitor you can find the packages in this repository (note that this may not be permanant and may change) https://github.com/XavierBerger/RPi-Monitor-deb use the **rpimonitor_latest.deb** file https://github.com/XavierBerger/RPi-Monitor-deb/tree/develop/packages install rpimonitor_latest.deb in Armbian use apt to install *rpimonitor_latest.deb* as it has varous package dependencies. e.g. download it to a folder and from there run sudo apt install ./rpimonitor_latest.deb the prior step should install rpimonitor, and check that the service is running by going to http://your_sbc_ip_address:8888 checking the setup rpi-monitor is runa as a systemd (unit) service if it is not running you can try systemctl status rpimonitor.service or journalctl -u rpimonitor.service to check what went wrong. to start / stop rpi-monitor it is as per basic systemd services e.g. systemctl start rpimonitor.service temperature 'not displaying' apparently, it is affected by this issue: https://github.com/XavierBerger/RPi-Monitor/issues/374 accordingly the fix/'workaround' is edit /etc/rpimonitor/template/temperature.conf replace #dynamic.1.postprocess=sprintf("%.2f", $1/1000) dynamic.1.postprocess=$1/1000

@ABhomeuser the board page is a bit out of date https://www.armbian.com/orange-pi-zero-3/ Debian 12 (Bookworm) Minimal / IOT SHA ASC 241.1 MB Debian 12 (Bookworm) Minimal / IOT SHA ASC 230.3 MB @Igor ^ how do we update that on the boards page? are actually the same file. proof: download the sha file for each of them and look at the content, you can see that both the filename and hash is identical in both sha texts. this means that both files are in fact identical and actually the same size, despite the incorrect file size indication on the front page. in fact that is currently linked to this release on github https://github.com/armbian/community/releases/tag/25.8.0-trunk.375 ^ this is released last week there are in fact 'earlier' releases, I'm running an image from this release https://github.com/armbian/community/releases/tag/25.8.0-trunk.309 I'd suggest going with the 'latest and greatest' (trunk 375) (which is that on the boards page currently) and if there are issues, then try that a little earlier e.g. in the latter link (trunk 309). armbian community images are rolling releases, they are 'fast moving' and perhaps come back in a few weeks, and it could be another trunk release number. but simply take an image 'as of now' and normally it 'just works' e.g. from the boards page.

all those things are wow give kodi a try? https://kodi.tv/

tried mining feathercoin, git clone https://github.com/ghostlander/cpuminer-neoscrypt lots of missing dependencies to build that apt install automake autoconf-archive pkg-config libtool libcurl4-openssl-dev but once done it is autogen.sh, configure, make next register on https://www.mining-dutch.nl/ then run ./minerd -D --algo=neoscrypt --url=stratum+tcp://mining-dutch.nl:9993 -u username.worker1 -p d=10 a whopping 1.1 k hash/s on each core, well not very impressivve, but it mines i think this is no Neon SIMD Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq Tcpu C.St. 20:22:02 1416 MHz 3.90 100% 0% 0% 99% 0% 0% 53.2 °C 0/7 20:22:07 1416 MHz 3.91 100% 0% 0% 99% 0% 0% 53.2 °C 0/7 20:22:12 1416 MHz 3.92 100% 0% 0% 99% 0% 0% 53.4 °C 0/7 ^ this is with the fan on optimise it a little in makefile #CFLAGS = -g -O2 CFLAGS = minerd_CPPFLAGS = -O3 -mcpu=cortex-a53 -march=armv8-a -ftree-vectorize -funsafe-math-optimizations well, just a very minor 0.025 k hash/s improvement per core. perhaps it already has Neon SIMD or that it needs 'hand optimization', that is hard.

@robertoj well, Neon SIMD isn't just useful for that matrix math, it is useful e.g. as a video decoder/encoder in place of specialized on chip video hardware. it could partially explain the 'better performance' of mpv (https://mpv.io/) e.g. if mpv is after all built with -o3 or that mpv uses a library that is optimised iwth Neon SIMD, it could likely practically see a performance as the on-chip proprietary video hardware which is not publicly documented. with an apparent 100% cpu usage if all 4 cpu cores are used with Neon SIMD. I think I once chanced upon an Rpi forum comment about shifting the codes to Neon SIMD instead instead of using propietary video hardware, partly as these 'small' chips has 'limited' capabilities for on chip video processing etc. it isn;'t really a bad thing if after all we'd use say an Opi Z3 as a 'dedicated' video streamer. A thing is at 100% cpu, non compute threads may struggle to get a slot to run at times, it may take setting 'nice' levels so that some threads get a higher priority. I've been thinking about running a (crypto coin) miner on it, probably would do that some time. They certainly don't get close to say even a Haswell, or Ryzen or even a 'low end gpu' but that they are faster than the 'older' 'smaller' chips for a comparison, the quoted 'old' figures https://linux-sunxi.org/Benchmarks#Linpack -mcpu=cortex-a8 -march=armv7-a -mfpu=neon -mfloat-abi=hard -funsafe-math-optimizations -fno-fast-math Memory required: 315K. LINPACK benchmark, Double precision. Machine precision: 15 digits. Array size 200 X 200. Average rolled and unrolled performance: Reps Time(s) DGEFA DGESL OVERHEAD KFLOPS ---------------------------------------------------- 16 0.61 88.52% 6.56% 4.92% 37885.057 32 1.21 85.12% 2.48% 12.40% 41459.119 64 2.43 93.83% 2.47% 3.70% 37561.254 128 4.86 91.77% 2.47% 5.76% 38381.368 256 9.70 92.06% 2.89% 5.05% 38173.000 512 19.41 91.29% 2.47% 6.23% 38634.432 mcpu=cortex-a8 -mtune=cortex-a8 -march=armv7-a -mfpu=neon -mfloat-abi=hard -funsafe-math-optimizations -fomit-frame-pointer -ffast-math -funroll-loops -funsafe-loop-optimizations Memory required: 315K. LINPACK benchmark, Double precision. Machine precision: 15 digits. Array size 200 X 200. Average rolled and unrolled performance: Reps Time(s) DGEFA DGESL OVERHEAD KFLOPS ---------------------------------------------------- 16 0.53 90.57% 1.89% 7.55% 44843.537 32 1.05 90.48% 3.81% 5.71% 44390.572 64 2.13 90.14% 2.35% 7.51% 44615.905 128 4.23 90.54% 3.07% 6.38% 44390.572 256 8.46 90.19% 2.84% 6.97% 44672.596 512 17.03 90.55% 2.76% 6.69% 44250.892 vs that above is like 8x - 10x improvements on a single core

ok we have a cheap SBC Z3 H618, but we'd still want to run it as like a supercomputer https://linux-sunxi.org/Benchmarks#Linpack download https://www.netlib.org/benchmark/linpackc.new save as linpack.c makefiile all: linpack-noopt linpack-o3 linpack-noopt: linpack.c gcc -o $@ $^ linpack-o3: linpack.c gcc -O3 -o $@ $^ -lm -mcpu=cortex-a53 -march=armv8-a -ftree-vectorize -funsafe-math-optimizations clean: linpack-noopt linpack-o3 rm $^ .PHONY: all clean ok, for your convenience it is in the attached zip file. to unzip you may need (as sudo): apt install zip unzip for the compilers you may need apt install build-essential $ make gcc -o linpack-noopt linpack.c gcc -O3 -o linpack-o3 linpack.c -lm -mcpu=cortex-a53 -march=armv8-a -ftree-vectorize -funsafe-math-optimizations $ ./linpack-noopt Enter array size (q to quit) [200]: Memory required: 315K. LINPACK benchmark, Double precision. Machine precision: 15 digits. Array size 200 X 200. Average rolled and unrolled performance: Reps Time(s) DGEFA DGESL OVERHEAD KFLOPS ---------------------------------------------------- 32 0.68 88.14% 2.66% 9.20% 71117.671 64 1.36 88.13% 2.66% 9.21% 71103.230 128 2.72 88.14% 2.66% 9.20% 71118.447 256 5.44 88.14% 2.66% 9.20% 71117.368 512 10.89 88.14% 2.66% 9.20% 71118.505 Enter array size (q to quit) [200]: q $ ./linpack-o3 Enter array size (q to quit) [200]: Memory required: 315K. LINPACK benchmark, Double precision. Machine precision: 15 digits. Array size 200 X 200. Average rolled and unrolled performance: Reps Time(s) DGEFA DGESL OVERHEAD KFLOPS ---------------------------------------------------- 128 0.53 86.33% 2.89% 10.78% 374433.231 256 1.05 86.33% 2.88% 10.79% 374573.654 512 2.10 86.34% 2.88% 10.79% 374443.201 1024 4.21 86.32% 2.88% 10.80% 374574.751 2048 8.42 86.32% 2.88% 10.80% 374612.768 4096 16.83 86.33% 2.88% 10.79% 374574.926 Enter array size (q to quit) [200]: q This is single core benchmark, apparently gcc -o3 does Neon SIMD linpack.zip

Arm Neon is quite a thing, SIMD https://developer.arm.com/documentation/102159/latest/ https://github.com/thenifty/neon-guide and accordingly aarch64 (e.g. Cortex A53, A55, A72, A75, A76 etc etc i.e. arm V8a onwards have them) https://developer.arm.com/documentation/102474/0100/Fundamentals-of-Armv8-Neon-technology the H618 is an A53 and hence should have it. it is a good 'replacement' for proprietary hardware etc as this like Intel's sse, avx , simd are defiined and standardized by Arm. Hence, they'd work if programs are coded and compiled to use them. Accordiingly, the pripietary video hardware is still undocumented (at least not publicly accessible), and most of that works are reverse engineered and incomplete. apps written to use Neon SIMD would however 'just works' and accelerated by virtue that it is SIMD.

oops, I missed reading that 100% cpu, but it is ok it is a a53 after all 😅 videos I'd guess is still 'difficult' on z3, accordingly there is some support for gpu vector graphics but I'd guess mostly just triangles. video decoding can be done with just neon (vector computation) , but i'd guess there is still limited access to video decoding hardware. using neon is likely to give that 100% cpu reading as the cpu is busy literally, using real video hardware would be 'invisible' in a sense, the cpu usage may look low but that one won't see that the video hardware itself may after all be reading 100%.

run dmesg, after you plug that uart into the port it should show the usb dongle connected and the port then a few more thiings, bad wires ensure that no matter what you do no data pass over the wires (I've seen this, especially those dupont pin connections) wrong connections ensure that no matter what you do no data pass over the wires. Are you sure you are talking to the correct *pins* and *port* on the host side? lousy dongles ensure that no matter what you do no data pass over the wires, get 'better' ones. oh well, this depends a little on luck, but I used ch340 usb-uart bridges, and they worked just well https://www.aliexpress.com/w/wholesale-ch340-uart.html searching usb uart normally returns a lot of entries https://www.aliexpress.com/w/wholesale-usb-uart.html if one doesn't work, try another oh then there is DTS overlay etc, sometimes that fix is needed bad / no drivers etc (dmesg should show it, on windows your mileage may vary) etc etc the rationale is, if you did it once successfully, either remember how you did it or document it sometimes, alternatives include, connect hdmi to monitor, usb keyboard and mouse and use as alternative console, mileage may vary.