ag123
-
Posts
347 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by ag123
-
-
Quote
I don't even have a reference viewpoint what should I start comparing?
I read claims that Python3-numpy, python3-opencv are highly optimized, but I never researched HOW OPTIMIZED
I have also heard that DRM can help accelerate machine learning https://www.youtube.com/watch?v=NQz6VqvtehI&t=5m7s
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.432mcpu=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.892vs 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 cleanok, for your convenience it is in the attached zip file. to unzip you may need (as sudo):
apt install zip unzipfor 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]: qThis is single core benchmark, apparently gcc -o3 does Neon SIMD
-
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.
-
Quote
* mpv plays most mp4s VERY SMOOTHLY BUT WITH 100% CPU
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.
-
thread about video in case anyone is looking for it
and a recent 'success story'
-
sound is a gotcha on the opi z3, actually opi z3 has sound but output only. accordingly opi z2 has sound both input (mic) and output.
and i think for 'convenience' many would after all use a usb sound card instead, just that there is only one usb port and the other 2 is actually on the extension pins on opi z3 as do with the audio output on z3
http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-Zero-3.html
as for usb + audio extension, orangepi sells an extension board
but that accordingly without that it may be possible to hack those usb connectors
https://www.aliexpress.com/w/wholesale-usb-female-type-a-with-wire.htmll
if one is willing to go the distance with electronics,
for the microphone i did a little research and found that there are mems microphone modules around
small, compact and possibly can be easily paired with boards like z , z2 or z3
https://www.aliexpress.com/w/wholesale-mems-microphone.html
but that most of these are I2S interfaces and I'm not too sure if it is feasible
apparently it is there for output, but I'm not sure about input
-
I've some old boards too e.g.
https://www.armbian.com/orange-pi-one/
interestingly there is an updated image for it, but that things I remember there are lots of gotcha unlike the whole many generation of incremental improvements between boards that finally evolved into a opi z3.
among the gotchas on orangepi one and orangepi pc h3 is that it uses a proprietary openrisc chip for power off which back then, if you run poweroff, the cpu will instead become very hot rapidly and you have to pull the usb cable quickly.
today there is this thing crust which i've not yet tried which is deemed to be able to orderly shutdown the soc
https://github.com/crust-firmware/crust
opi z3 uses a PMIC with its own internal firmware and I think it is comms i2c etc that starts the shutdown process.
things are different between the generations (of boards and kernel)
---
my guess is to try a new u-boot, it may take doing a build
and the changes may be quite similar to this
https://github.com/armbian/build/pull/8334
https://github.com/armbian/build/pull/8334/commits/49ccbe88bc2ddf31b55ece850d28ef18c6ae8a1a
---
if you want to venture and experiment with just u-boot alone
here is how I once tried
https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3
https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/blob/main/build.md
-
just like to say that the recent images
works just well
_ _ _ _ _ /_\ _ _ _ __ | |__(_)__ _ _ _ __ ___ _ __ _ __ _ _ _ _ (_) |_ _ _ / _ \| '_| ' \| '_ \ / _` | ' \ / _/ _ \ ' \| ' \ || | ' \| | _| || | /_/ \_\_| |_|_|_|_.__/_\__,_|_||_|_\__\___/_|_|_|_|_|_\_,_|_||_|_|\__|\_, | |___| |__/ v25.8 rolling for Orange Pi Zero3 running Armbian Linux 6.12.35-current-sunxi64 Packages: Debian stable (bookworm) Support: for advanced users (rolling release) IPv4: (LAN) xxx.xxx.xxx.xxx (WAN) yyy.yyy.yyy.yyy IPv6: fd00:xxxx:xxxx::xxxx:xxxx (WAN) xxxx:xxxx::yyyy:yyyy WiFi AP: SSID: (ssid), Performance: Load: 2% Uptime: 3:50 Memory usage: 4% of 3.83G CPU temp: 41°C Usage of /: 3% of 58G RX today: 7 MiB Commands: Configuration : armbian-config Monitoring : htop
-
this is somewhat 'off-topic' but still relevant to 'orange pi zero 3'
If Orange Pi Zero 3 is operated in warm climates (e.g. room temperature 30 deg C etc) , it can at times run up to like 60 deg C.
this is in open still air
adding a fan blowing at it reduce that by some 20 deg C to 40 deg C !
And this is my ghetto fan setup, no fancy case, no heatsink nothing, just a single long machine screw that lifts it up
checking temperatures is easy
> armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq Tcpu C.St. 18:03:39 480 MHz 0.00 0% 0% 0% 0% 0% 0% 40.8 °C 0/7^C
strictly speaking, 60 deg C is 'nothing to scream about' , I've a Rpi 4 hitting up 80 deg C and it throttles.
similarly use a fan blowing at it + a heat sink over the cpu, drastically reduce running temperatures.for 'occasional' use, I don't think it is necessary to have a fan blowing at the Orange Pi Zero 3.
I think it is feasible to run at lower temperatures if I disable and unclock the GPU and HDMI, but for now I'm not sure how to go about doing that.
Initially, I'm thinking maybe the wifi is causing it, but now I don't think so, it is moderately likely the gpu is heating it up a bit.
And still air don't seem to dissipate heat very well.
-
apparently new images for OrangePi Zero 3 Debian minimal IOT are out on github and the boards page
thanks to @Igor, @TRay, et.al.
https://www.armbian.com/orange-pi-zero-3/
https://github.com/armbian/community/releases/tag/25.8.0-trunk.309
^ apparently a big release many images ( e.g. different variants and boards) are updated, but I checked only OrangePi Zero 3 Debian minimal IOT
the feature for OrangePi Zero 3 according to recent build release
https://github.com/armbian/build/releases/tag/v25.8.0-trunk.293
is
https://github.com/armbian/build/pull/8334
the use of u-boot tag:v2025.04 likely improves boot time ddr ram size detection.
-
-
one way is if you have tested that config and build to make a pull request on github
https://github.com/armbian/build
-
I'm, using one of those CH340 based usb-uart dongles
https://www.aliexpress.com/w/wholesale-usb-uart-ch340.html
but that normally most usb-uart dongles would work
https://www.aliexpress.com/w/wholesale-usb-uart.html
just make sure to check that it has / uses 3.3V io levels. Not 5V io levels as that may damage the processor (cpu / soc)
for the pins connection review the user manual
it is the 3 pins labelled Debug TTL UART on their board photo
http://www.orangepi.org/img/zero3/0627-zero3 (6).png
---
off-topic:
for these small boards, I've basically stopped running them with an LCD monitor and keyboard as I find it a hassle as I'm using a desktop PC and trying to share the monitor. I mostly use them 'headless' using the usb-uart port.
And in fact, after you setup the network appropriately e.g. set a static IP address or install avahi, the usb-uart console is no longer needed
for static (fixed) IP address it is covered in the networking guide
https://docs.armbian.com/User-Guide_Networking/
for avahi (MDNS)
> apt install avahi-daemon avahi-utils edit /etc/avahi/avahi-daemon.conf [publish] publish-workstation=yesyou can find the board on the ethernet over MDNS
e.g.
https://github.com/hrzlgnm/mdns-browser
and you can ssh into the board over the network, e.g. using putty
-
as I've not been running X11, I can't really help with this, but among the things, check the logs during X startup (normally /var/log/*), that could lead to the cause.
note also that more recently, the display systems are running wayland rather than X11. that could cause xfce etc to fail if it is expecting an X11 based setup
it is also recommended to bootup in the uart console (debug) port using a usb-uart dongle.
- the benefits are numerous, the boot messages are mostly presented
- it provides you with a console to login and check things while the system is running
e.g. to login and check dmesg and other logs
- essential especially when re-wiring network configuration
-
there are a few caveats that may need a bit of attention
It is documented somewhere that if you use channel 0, the driver would automatically select an appropriate channel / frequency.
However, it seemed that back then initially while I tested it, that didn't seem to work. (i'm not sure if it may have changed)
hence to list the channels one needs to run
iw listand you would get a list of channels like such
* 2412 MHz [1] (20.0 dBm) * 2417 MHz [2] (20.0 dBm) * 2422 MHz [3] (20.0 dBm) * 2427 MHz [4] (20.0 dBm) * 2432 MHz [5] (20.0 dBm) * 2437 MHz [6] (20.0 dBm) * 2442 MHz [7] (20.0 dBm) * 2447 MHz [8] (20.0 dBm) * 2452 MHz [9] (20.0 dBm) * 2457 MHz [10] (20.0 dBm) * 2462 MHz [11] (20.0 dBm) * 2467 MHz [12] (20.0 dBm) * 2472 MHz [13] (20.0 dBm) * 2484 MHz [14] (20.0 dBm) * 5170 MHz [34] (disabled) * 5180 MHz [36] (20.0 dBm) * 5200 MHz [40] (20.0 dBm) * 5220 MHz [44] (20.0 dBm) * 5240 MHz [48] (20.0 dBm) * 5260 MHz [52] (20.0 dBm) (radar detection) * 5280 MHz [56] (20.0 dBm) (radar detection) ... * 5720 MHz [144] (20.0 dBm) (radar detection) * 5745 MHz [149] (20.0 dBm) * 5765 MHz [153] (20.0 dBm) * 5785 MHz [157] (20.0 dBm) * 5805 MHz [161] (20.0 dBm) * 5825 MHz [165] (20.0 dBm)what I normally do is to do a scan and pick an unused / least used channel :
iw wlan0 scanpick an appropriate channel and specify it in hostapd.conf. 5ghz channels (hw_mode=a) delivers a max throughput of like 140 Mbps which is fast.
https://docs.armbian.com/WifiPerformance/#uwe-5622
accordingly there are some country specific requirements for 5ghz channel selections and one may like review
https://en.wikipedia.org/wiki/List_of_WLAN_channels
iw reg setetc
I did a google search and some of these resources may be useful
https://wiki.archlinux.org/title/NetworkManager
https://www.baeldung.com/linux/nmcli-wap-sharing-internet
in a same way you may need to set the channel if necessary
then that this repo is found in a google search which may be useful
https://github.com/pi-top/Wi-Fi-Access-Point-and-Station-Mode/tree/master
-
accordingly H618 do not have mic in hardware
hence, an option is to use a usb soundcard / dongle
https://www.aliexpress.com/w/wholesale-usb-sound-card.html
there are also those 'arduinoish' approaches
e.g. to use a ADC module board e.g.
https://www.ti.com/lit/ds/symlink/ads1110.pdf
https://www.aliexpress.com/w/wholesale-ads1110.html
https://www.instructables.com/Arduino-and-the-TI-ADS1110-16-bit-ADC/
but that you would need to hack the pin interfaces to use i2c etc.
note it seemed ads1110 is a bit too slow for sound.
alternatives are like stm32, which has built-in adc that can go to like 1-2.5 Msps, but you would need to hack the spi interface etc.
the 'easiest / cheapest' way seemed to be generic 'usb sound cards'
-
there are some 'old' stuff that may not be fully relevant but still useful
this gist likely helps:
https://gist.github.com/ag88/de02933ba65500376d1ff48e504b1bf3
an 'old' post:
Note that currently in the minimal image netplan is set to systemd-networkd
https://docs.armbian.com/User-Guide_Networking/#minimal-images
I'm less familiar with systemd-networkd, though it is possible to setup the network fully with it.
What i did currently, is to update netplan config as above to use NetworkManager
After that I use NetworkManger to setup a bridge adding the ethernet interface.
https://gist.github.com/ag88/de02933ba65500376d1ff48e504b1bf3
.
However, I actually make NetworkManager *unmanage* the Wifi interface, because i'm using hostapd.
I'm using hostapd mainly because in journalctl logs, there is an entry for every host/client that connects. I'm not sure about how to do the same with Network Manager. hostapd also supports elaborate RADIUS authentication if one wants to go the distance.
Then I install and configure hostapd as described in the gist, and during startup, hostapd actually patch the wifi interface into the bridge that is setup with NetworkManager.. The configuration for wifi AP is completely done in hostapd.conf as described in the gist.
I'm using a bridge as DHCP is managed from my gateway router, hence I did not run a separate DHCP server instance in Orange Pi Zero 3 itself.
An alternative setup is to setup NAT (network address translation) on the Orange Pi Zero 3 and to run a DHCP server on the Orange Pi Zero 3 itself.
I think NAT approach is 'more common'
I'm using hostapd, but I think without hostapd, it is also possible to setup an AP using NetworkManager alone. i.e. to let Network Manager manage the Wifi interface, and configure it as an AP. The benefit here is that Network manager woulld likely manage the DHCP and NAT as well all from Network Manager configurations.
As I'm doing everything from the command line, I used NetworkManager cli (nmcli) for all the network manager configuration tasks.
Note that while messing with networking, it is necessary to work in the serial debug console using a usb-uart dongle.
i.e. bootup and login as root using a usb-uart dongle to the 3 'debug' pins for the serial console.
-
just like to say that I installed
Armbian_community_25.8.0-trunk.228_Orangepizero3_bookworm_current_6.12.30_minimal.img
from the boards page
https://www.armbian.com/orange-pi-zero-3/
apt update works 'out of the box', no PUBKEY errors
I really liked the new MOTD on login
_ _ _ _ _ /_\ _ _ _ __ | |__(_)__ _ _ _ __ ___ _ __ _ __ _ _ _ _ (_) |_ _ _ / _ \| '_| ' \| '_ \ / _` | ' \ / _/ _ \ ' \| ' \ || | ' \| | _| || | /_/ \_\_| |_|_|_|_.__/_\__,_|_||_|_\__\___/_|_|_|_|_|_\_,_|_||_|_|\__|\_, | |___| |__/ v25.8 rolling for Orange Pi Zero3 running Armbian Linux 6.12.30-current-sunxi64 Packages: Debian stable (bookworm) Updates: Kernel upgrade enabled and 8 packages available for upgrade Support: for advanced users (rolling release) WiFi AP: SSID: (wifi_hotspot_name), Performance: Load: 12% Up time: 0 min Memory usage: 5% of 3.83G CPU temp: 54°C Usage of /: 3% of 58G RX today: 6 MiB Commands: Configuration : armbian-config Upgrade : armbian-upgrade Monitoring : htoprunning Armbian on Orangepizero 3 makes a good desktop wifi hotspot (AP)
it counts among the fastest Wifi with UWE5622 AP on 5 ghz on 'cheap' SBC (single board computers)
https://docs.armbian.com/WifiPerformance/#uwe-5622
if you see that updates message, what is more cool is if you run
apt list --upgradableit list the packages that is upgradable, and I tried
apt upgradeinstall quite a few things, then manually
rebootit becomes 25.8.0-trunk.230 ! this can be verified in /etc/armbian-release
-
@Igor, all
just like to say that I installed
Armbian_community_25.8.0-trunk.228_Orangepizero3_bookworm_current_6.12.30_minimal.imgArmbian_community_25.8.0-trunk.228_Orangepizero3_bookworm_current_6.12.30_minimal.img
from the boards page
https://www.armbian.com/orange-pi-zero-3/
apt update works 'out of the box', no PUBKEY errors
thanks for the the updates
you may like to try the same for orange pi zero 2
-
it seemed that the (minimal/iot) images linked on the boards page , have been updated, I just downloaded Armbian_community_25.8.0-trunk.228_Orangepizero3_bookworm_current_6.12.30_minimal.img.xz
for orangepi zero 3. note I only checked debian as that is what i'm using
https://www.armbian.com/orange-pi-zero-3/ -
it seemed that the (minimal/iot) images linked on the boards page , have been updated, I just downloaded Armbian_community_25.8.0-trunk.228_Orangepizero3_bookworm_current_6.12.30_minimal.img.xz
for orangepi zero 3. note I only checked debian as that is what i'm usingit seemed to be similar for orangepi zero 2
https://www.armbian.com/orange-pi-zero-2/
-
I think using the ubuntu keyserver is good as well
but that this is a 'small' issue, it is easy to miss a small thing in a project this huge consider the number of boards, kernels, and distributions (including the different releases).
if this little thing breaks, we can fix in our installed os using these methods.
-
NO_PUBKEY 93D6889F9F0E78D5 while using apt (e.g. apt update)
symptom:> apt update ... Err:8 https://github.armbian.com/configng stable InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 93D6889F9F0E78D5 ... W: Failed to fetch https://github.armbian.com/configng/dists/stable/InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 93D6889F9F0E78D5observed in Armbian image for Orange pi zero 3 Armbian_community_25.8.0-trunk.90_Orangepizero3_bookworm_current_6.12.30_minimal.img build date May 28, 2025
fix:
- run this as root
> su - ^ login as root > wget -O - https://apt.armbian.com/armbian.key | gpg --dearmor -o /usr/share/keyrings/armbian.gpg
you should find a file /usr/share/keyrings/armbian.gpg about 2 KB in sizerepeat apt update etc should have resolved the error
.png){kind=link}
Orange Pi Zero 3
in Allwinner sunxi
Posted
tried mining feathercoin,
git clone https://github.com/ghostlander/cpuminer-neoscryptlots of missing dependencies to build that
apt install automake autoconf-archive pkg-config libtool libcurl4-openssl-devbut 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=10Hash: 020E9F4B68201E05469CC87039286A9EEFAFB6525E9CDDAD40E4DCFC6D950000x0 Target: 0000000000000000000000000000000000000000000000000000000098990100x0 [2025-07-17 20:07:06] thread 2: 537 hashes, 1.097 KH/s [2025-07-17 20:07:06] accepted: 14/14 (100.000%), 4.398 KH/s (yay!!!) [2025-07-17 20:07:14] DEBUG (little endian): hash <= target Hash: FD8193D5659404573894CC22F8A37859A2347842E382CCF151747A0E34220100x0 Target: 0000000000000000000000000000000000000000000000000000000098990100x0 [2025-07-17 20:07:14] thread 1: 9481 hashes, 1.100 KH/s [2025-07-17 20:07:14] accepted: 15/15 (100.000%), 4.397 KH/s (yay!!!) [2025-07-17 20:07:18] DEBUG (little endian): hash <= target Hash: 9B92D3883EA6CE4BC66BE97CF9CDC6E8C51B0D28B8C3D7F2BA28B8C58D310100x0 Target: 0000000000000000000000000000000000000000000000000000000098990100x0 [2025-07-17 20:07:18] thread 2: 13983 hashes, 1.100 KH/s [2025-07-17 20:07:18] accepted: 16/16 (100.000%), 4.400 KH/s (yay!!!) [2025-07-17 20:07:32] DEBUG (little endian): hash <= target Hash: 3FC00FD320605941571915FC723A4CBB2C9E798552E309C980F333CA76B40000x0 Target: 0000000000000000000000000000000000000000000000000000000098990100x0 [2025-07-17 20:07:32] thread 1: 20346 hashes, 1.101 KH/s [2025-07-17 20:07:32] accepted: 17/17 (100.000%), 4.401 KH/s (yay!!!) [2025-07-17 20:07:34] thread 3: 66030 hashes, 1.100 KH/s [2025-07-17 20:07:36] DEBUG (little endian): hash <= target Hash: 787E9A8E6CF0D6293659419BA9963ED809F7D606A2AD8E879968A5B075620000x0 Target: 0000000000000000000000000000000000000000000000000000000098990100x0 [2025-07-17 20:07:36] thread 1: 4421 hashes, 1.100 KH/s [2025-07-17 20:07:36] accepted: 18/18 (100.000%), 4.400 KH/s (yay!!!) [2025-07-17 20:07:42] DEBUG (little endian): hash <= target Hash: 27163C9021EAE5D4D5D458F384751990AE336F19BD3AC8D980AA97C55A940000x0 Target: 0000000000000000000000000000000000000000000000000000000098990100x0 [2025-07-17 20:07:42] thread 3: 8654 hashes, 1.101 KH/s [2025-07-17 20:07:42] accepted: 19/19 (100.000%), 4.400 KH/s (yay!!!) [2025-07-17 20:08:00] thread 0: 65995 hashes, 1.100 KH/s [2025-07-17 20:08:18] thread 2: 65977 hashes, 1.100 KH/s [2025-07-17 20:08:36] thread 1: 65992 hashes, 1.100 KH/s [2025-07-17 20:08:37] DEBUG (little endian): hash <= target Hash: 037AD1DB8D7C7FAB0E022F8541BA34D67A7E9B3695B396FAF84C6D47AD950000x0 Target: 0000000000000000000000000000000000000000000000000000000098990100x0 [2025-07-17 20:08:37] thread 0: 40427 hashes, 1.100 KH/s [2025-07-17 20:08:37] accepted: 20/20 (100.000%), 4.401 KH/s (yay!!!) [2025-07-17 20:08:39] DEBUG (little endian): hash <= target Hash: 5FBB0159477A05E1324B6A3D240B89DAEDF34A83A8AA78FE155FA86DE3140100x0 Target: 0000000000000000000000000000000000000000000000000000000098990100x0 [2025-07-17 20:08:39] thread 3: 62568 hashes, 1.101 KH/s [2025-07-17 20:08:39] accepted: 21/21 (100.000%), 4.401 KH/s (yay!!!)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[2025-07-17 20:41:42] DEBUG (little endian): hash <= target Hash: 02D285CA9C499E30195BD3EC4F4DF544D03EDDC7A00DFC0D255EB1E7BA160000x0 Target: 0000000000000000000000000000000000000000000000000000008099190000x0 [2025-07-17 20:41:42] thread 1: 19364 hashes, 1.127 KH/s [2025-07-17 20:41:42] accepted: 1/1 (100.000%), 1.127 KH/s (yay!!!) [2025-07-17 20:41:54] thread 3: 32766 hashes, 1.128 KH/s [2025-07-17 20:41:54] thread 0: 32766 hashes, 1.127 KH/s [2025-07-17 20:41:54] thread 2: 32766 hashes, 1.124 KH/s [2025-07-17 20:42:42] thread 1: 67603 hashes, 1.127 KH/s [2025-07-17 20:42:53] thread 3: 67650 hashes, 1.128 KH/s [2025-07-17 20:42:54] thread 0: 67639 hashes, 1.127 KH/s [2025-07-17 20:42:54] thread 2: 67439 hashes, 1.124 KH/s [2025-07-17 20:43:42] thread 1: 67627 hashes, 1.128 KH/swell, 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.