ag123

@Igor Armbian_25.5.1_Orangepizero3_bookworm_current_6.12.23_mi nimal.img.xz below is transcript from the 'debug uart (serial)' console, via a usb-uart dongle, it is the only way to boot up with a console , if network etc is not available. U-Boot 2024.01-armbian-2024.01-S866c-P4a40-H8869-V3d5b-Bb703-R448a (May 28 2025 - 02:53:19 +0000) Allwinner Technology CPU: Allwinner H616 (SUN50I) Model: OrangePi Zero3 DRAM: 1.5 GiB Core: 57 devices, 25 uclasses, devicetree: separate WDT: Not starting watchdog@30090a0 MMC: mmc@4020000: 0 Loading Environment from FAT... Unable to use mmc 0:1... .... _ _ _ /_\ _ _ _ __ | |__(_)__ _ _ _ / _ \| '_| ' \| '_ \ / _` | ' \ /_/ \_\_| |_|_|_|_.__/_\__,_|_||_| v25.5.1 for Orange Pi Zero3 running Armbian Linux 6.12.23-current-sunxi64 Packages: Debian stable (bookworm) Updates: Kernel upgrade enabled and 23 packages available for upgrade Support: DIY (community maintained) IPv4: (LAN) 192.168.xxx.xxx (WAN) xxx.xxx.xxx.xxx IPv6: fd00:xxxx:xxxxx, xxxxx (WAN) xxxx Performance: Load: 18% Up time: 2 min Memory usage: 9% of 1.44G CPU temp: 50°C Usage of /: 9% of 15G Commands: Configuration : armbian-config Upgrade : armbian-upgrade Monitoring : htop root@orangepizero3:~# ping google.com PING google.com (142.250.4.138) 56(84) bytes of data. 64 bytes from sm-in-f138.1e100.net (142.250.4.138): icmp_seq=1 ttl=100 time=2.77 ms 64 bytes from sm-in-f138.1e100.net (142.250.4.138): icmp_seq=2 ttl=100 time=2.79 ms ^ ethernet works root@orangepizero3:~# ip link set wlan0 up root@orangepizero3:~# iw dev wlan0 scan BSS xxxxx freq: 24xx signal: -77 dBm ^ wifi works, at least for scanning for stations, connect and AP not yet tested ^ the above is booted up on a 'rare' 1.5GB board. repeat using the same uSD card on a 4 GB board, initially the debug usb-uart console is garbled, it seemed to be a baud rate mismatch, I'm not sure why, but after a few retry it works. Perhaps it is due to bad wires. U-Boot 2024.01-armbian-2024.01-S866c-P4a40-H8869-V3d5b-Bb703-R448a (May 28 2025 - 02:53:19 +0000) Allwinner Technology CPU: Allwinner H616 (SUN50I) Model: OrangePi Zero3 DRAM: 4 GiB Core: 57 devices, 25 uclasses, devicetree: separate WDT: Not starting watchdog@30090a0 MMC: mmc@4020000: 0 Loading Environment from FAT... Unable to use mmc 0:1... ... _ _ _ /_\ _ _ _ __ | |__(_)__ _ _ _ / _ \| '_| ' \| '_ \ / _` | ' \ /_/ \_\_| |_|_|_|_.__/_\__,_|_||_| v25.5.1 for Orange Pi Zero3 running Armbian Linux 6.12.23-current-sunxi64 Packages: Debian stable (bookworm) Updates: Kernel upgrade enabled and 23 packages available for upgrade Support: DIY (community maintained) IPv4: (LAN) 192.168.xxx.xxx (WAN) xxx.xxx.xxx.xxx IPv6: fd00:xxxx:xxxxx, xxxxxxxx (WAN) xxxxxxxx Performance: Load: 12% Up time: 1 min Memory usage: 3% of 3.83G CPU temp: 46°C Usage of /: 9% of 15G Commands: Configuration : armbian-config Upgrade : armbian-upgrade Monitoring : htop root@orangepizero3:~# ping google.com PING google.com (142.251.12.139) 56(84) bytes of data. 64 bytes from se-in-f139.1e100.net (142.251.12.139): icmp_seq=1 ttl=103 time=2.69 ms 64 bytes from se-in-f139.1e100.net (142.251.12.139): icmp_seq=2 ttl=103 time=2.99 ms ^ ethernet works root@orangepizero3:~# ip link set wlan0 up root@orangepizero3:~# iw dev wlan0 scan BSS xxxxxx(on wlan0) freq: 24xx signal: -78.00 dBm ^ wifi works for scan, connect and AP not tested I'm not too sure what is the difference between v25.5.1 vs that on the boards page? https://www.armbian.com/orange-pi-zero-3/ from those links 'current' seemed to be linked to: as of current 28 May 2025 Armbian_community_25.8.0-trunk.8_Orangepizero3_bookworm_current_6.12.23_minimal.img.xz btw thanks much (to all contributors) for updating Armbian to 25.x for OrangePi Zero 3 (and likely means works for Zero 2W) as well. oh frequency scaling works as well, this is on the 4GB board root@orangepizero3:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq Tcpu C.St. 01:43:36 1416 MHz 0.00 1% 0% 0% 0% 0% 0% 47.2 °C 0/7 01:43:41 480 MHz 0.00 0% 0% 0% 0% 0% 0% 47.2 °C 0/7 01:43:46 480 MHz 0.00 0% 0% 0% 0% 0% 0% 47.4 °C 0/7 01:43:51 480 MHz 0.00 0% 0% 0% 0% 0% 0% 47.0 °C 0/7 'everyone' should just get the 4GB board, make it a 'standard' lol @TRay It is a good idea to try U-Boot v2025.04 I've got a python script which can patch u-boot binary into an Armbian .img or practically any other image file (though i've only tested this in *unofficial* armbian builds) https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/tree/main/tools https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3 i created it back then while researching solutions for the '1.5GB' problem back then. Do you have the 'bin' file for u-boot that you could share say in a zip file attached here? you can extract that 'bin' file using the 'backup' procedure documented here: https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3?tab=readme-ov-file#how-to-use sudo dd if=/dev/sdX of=u-boot-backup.bin bs=1024 skip=8 count=1024 But that the appropriate way would be to build the full armbian image from source including u-boot etc. Nevertheless, having the 'patched' u-boot binary would enable most here to test that by patching a distributed image file e.g. from the boards page, or from the 'test images' link as Igor has provided.

apparently it needs libheif https://github.com/libvips/libvips try apt-cache search heif apt install libheif1 alternatively, there is libavif https://github.com/AOMediaCodec/libavif I'm using libavif, built that from source, but you can nevertheless try sudo apt install libavif15 libavif-bin libavif-dev

I've not used a board which use EMMC (yet). They are more convenient, sometimes faster. While I'm not always against EMMC, some of the EMMC support is occasionally not very well documented / implemented, in particular by the vendors (e.g. how their boot rom selects booting from EMMC or SD). And that occasionally led to gotchas such as a boot fail in EMMC but it seem there isn't a way to recover from that etc. EMMC add a bit more complexity to the boot process, in particular by the boot rom (on PCs used to be called BIOS) and it is necessary to see that all the different boot permutations are well supported, boot from SD, boot from EMMC, override from SD (e.g. if EMMC install fails) etc, reflash EMMC from SD etc.

I remember seeing somewhere that ALSA may be *muted*, so turn on the volume, sometimes simple things matter. I'm not sure if it helps but hope it helps.

I'm using OrangePi Zero 3 as a basic desktop WIfi AP hotspot. it isn't practically 'high performance' certainly no WiFi 6 etc. But basic single channel 5 ghz wifi is there with throughput about 130 Mbps across both ethernet and the Wifi interface. It is ok as a 'desktop Wifi AP' (satelite), but probably underpowered as a router to the internet. https://www.armbian.com/orange-pi-zero-3/ these works if what you need is wifi 'repeaters' to alleviate wifi blindspots say due to walls etc. but that likely means ethernet cabling as well. i.e. ethernet to upstream, wifi is the hotspot. I actually liked these (OrangePi Zero 3 running Armbian as Wi-Fi hotspot) vs proprietary 'mesh' cubes as you have full control in the OS layer wifi / bridging etc, less blackboxes, less propietary limitations etc. The hellhole about WiFi and sometimes ethernet is that a lot of those drivers are propietary some without any open sourced driver interface on the linux side, let alone the chip firmware. There are a lot of good boards, cpu e.g. RK3588 and you have a Wifi chip that has *zero* (open sourced) drivers. e.g. Orange Pi 5 Ultra.

cross posting this thread, as this seemed to be a related 'bleeding edge' thread one can probably ignore the 'don't use' remarks as apparently, efforts are underway to make the recent kernel work (on zero3, zero2w)

if you want to play with the NPU, you would likely need to resort to the reversed engineered open source NPU driver https://www.hackster.io/news/tomeu-vizoso-s-open-source-npu-driver-project-does-away-with-the-rockchip-rk3588-s-binary-blob-0153cf723d44 https://www.cnx-software.com/2024/04/21/rockchip-rk3588-npu-open-source-driver-object-detection30-fps/ https://blog.tomeuvizoso.net/search/label/rk3588 this is not from rockchip nor orange pi, probably no documentation and you would need to find your way around yourself, you are on your own. but that the open source driver is absolutely bleeding edge, i.e. it is in mainline linux and the one and only one. as for wifi I didn't seem to see explicit support for the chip AP6611 in the wild, may be I didn't find it in the 'right' places. did anyone chanced upon a driver for ap6611 on github, etc?

@Dual Stack I think it has to do with DRAM timings and detection and that possibly Orange Pi used different dram chips even though the board is sold as Orange Pi Zero 3 DRAM initialization is in the embedded boot loader u-boot and the problem mainly occurs during a cold startup reboot. https://github.com/u-boot/u-boot/blob/master/arch/arm/mach-sunxi/dram_helpers.c#L28-L64 There used to be a '1.5 GB' problem and other associated problem detecting memory sizes, those has been resolved to some extent. Among the solutions, without resorting to fixing codes: make sure your Wifi antenna is not lying on the board near any of the chips (cpu, dram etc), bring the antenna outside the board so that it don't lie over any electronic components. There has been reports that the Wifi interference has caused some problems with memory / cpu etc. as for myself, after booting successfully, I practically simply leave the board on, that is ok as I used it as a WiFi AP. Otherwise the 'solution' is to simply reboot taking note of the Wifi antenna issue above. That said, Armbian on Orange Pi Zero 3 should be running pretty well except for some of these hiccups https://www.armbian.com/orange-pi-zero-3/ it is one of the distributions/images that has considerable volunteered effort to make Armbian run on Orange Pi Zero 3. you can review this long thread for the history. The difference between Armbian vs the vendors images is that the vendor's images is to some extent proprietary. While Armbian is literally / actually build from source and you can rebuilt an image if you are willing to go the distance. https://docs.armbian.com/Developer-Guide_Build-Preparation/ It is also different in this sense in that Armbian can be updated to a recent kernel and supporting codes (e.g. u-boot) (which indeed it is) and often the kernel in the vendors images tend to be 'left behind' with an old kernel version, which may not get updated. It'd be good to support the Armbian project via donations etc as this is probably about the only way to keep the project sustainable and supported. Strictly speaking, those donations are subscriptions as would be for commercial os and distributions. --- There is an old *unsupported* image that I rebuilt from source based on 6.7 kernel back then. I won't be providing any support for this image, and it may not necessarily fix this problem and may have other issues e.g. the 1.5GB issue. But if you'd like to try it it is here: ----- It is quite possible to hard code memory configuration in u-boot, but that it requires re-building an armbian image from source. It is probably not recommended currently, but that if you are curious to look at an early fix back then about the 1.5 GB issue a similar tactic can be used to hardcode say 4GB for your board, but requires re-building the at least u-boot and patching it into the image, or rebuilding armbian image from source. That can 'work around' those memory detection issues since all that configurations is hard coded.

I think rotation is managed by some LCD commands, see MADCTL in the datasheet. https://www.hpinfotech.ro/ILI9488.pdf so the driver probably needs to implement it to have rotation

well, the SOC is the same, 'in theory', that image e.g. for pi5-plus should work. The trouble is the dram and all + on board emmc, and i'm not sure what else (ethernet/wifi ?) etc may be different. I think i'd go with a Rpi 5 firsthand as I've yet to get a board and maybe add a rk3588 (perhaps much) later. and well in mainline there seemed to be a dts already there for opi 5 plus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts?h=v6.13 but it'd seem there is no 'specifics' for opi 5 ultra https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip?h=v6.13 if it is true, one'd need to go on the notion of 'may work' e.g. to use the opi 5+ image for a start. and of course the other 'hidden' (and very important) thing is uboot https://www.denx.de/project/u-boot/

hdmirx aside, Would Armbian run on Orange Pi 5 ultra? a closer image I'd guess is this? https://www.armbian.com/orange-pi-5-plus/ there is also some 'rumors' about rk3588 mainlining efforts, I'd guess it could be 'lost in translation' / misintepreted I've weighed between a Rpi 5 vs rk3588, rk3588 seemed to be higher performing and has a built-in NPU. But that for sure Rpi 5 have more 'popular' support, at least from Rpi itself. A thing about Armbian and/'or mainline based linux running on these boards is, they tend to be 'beyond rpi', hacks like HDMI RX is feasible. Rpi is more for 'lazy' tinkerers who wants boards that 'just works', but that sometimes that helps.

oh and get a usb-uart cable and work from the 'debug' (3 pin serial) port, that is an absolute necessity to mess with network configs https://www.aliexpress.com/w/wholesale-usb-uart-3.3v.html https://www.aliexpress.com/w/wholesale-usb%25252duart.html https://www.aliexpress.com/w/wholesale-usb-uart-ch340.html get those that is 3.3v or with a switch or jumper that you can toggle to 3.3v outputs, 5v is probably unsafe to put on the allwinner chip. I configured my that way from the serial console so that WiFi and ethernet sits on a bridge practically as my little desktop WiFi AP. --- but that HDMI patch is truly valuable

it may be in one/some of the patches, there is a huge thread about it where development originally started. probably to look in there to see if the patch can be found and applied to edge, at least locally the search box on top of forum probably could help

I'd think WSL is Microsoft's version of Virtualbox, so if you have Ubuntu or Debian running in it, it is Linux, which is a reason it is surprising it didn't work 😛 When I tried building Armbian in a systemd-nspawn container running Ubuntu Jammy. it has issues with loop devices and I worked around them as discussed in this thread. Missing the loop devices will cause writing the image to fail and abort at the last stage. I don't think the loop devices problem is identical, but that the problems may be similar. Fixing the loop devices issue may require editing the build scripts in particular the image creation parts, I did that once and managed a successful build. However, in a subsequent update, a git merge 'messed up' my changes and I'd need to figure out how I did it again which I had forgotten.

it seemed strange for it to need qemu-arm, but a google search for binfmts qemu-arm return this as one of the results https://wiki.debian.org/QemuUserEmulation