ag123

made an attempt to extract /etc/apt/sources.list from the pulled image ghcr.io/armbian/docker-armbian-build, armbian-ubuntu-jammy-latest. replaced that in the Ubuntu Jammy build container /etc/apt/sources.list # See http://help.ubuntu.com/community/UpgradeNotes for how to upgrade to # newer versions of the distribution. deb http://archive.ubuntu.com/ubuntu/ jammy main restricted # deb-src http://archive.ubuntu.com/ubuntu/ jammy main restricted ## Major bug fix updates produced after the final release of the ## distribution. deb http://archive.ubuntu.com/ubuntu/ jammy-updates main restricted # deb-src http://archive.ubuntu.com/ubuntu/ jammy-updates main restricted ## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu ## team. Also, please note that software in universe WILL NOT receive any ## review or updates from the Ubuntu security team. deb http://archive.ubuntu.com/ubuntu/ jammy universe # deb-src http://archive.ubuntu.com/ubuntu/ jammy universe deb http://archive.ubuntu.com/ubuntu/ jammy-updates universe # deb-src http://archive.ubuntu.com/ubuntu/ jammy-updates universe ## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu ## team, and may not be under a free licence. Please satisfy yourself as to ## your rights to use the software. Also, please note that software in ## multiverse WILL NOT receive any review or updates from the Ubuntu ## security team. deb http://archive.ubuntu.com/ubuntu/ jammy multiverse # deb-src http://archive.ubuntu.com/ubuntu/ jammy multiverse deb http://archive.ubuntu.com/ubuntu/ jammy-updates multiverse # deb-src http://archive.ubuntu.com/ubuntu/ jammy-updates multiverse ## N.B. software from this repository may not have been tested as ## extensively as that contained in the main release, although it includes ## newer versions of some applications which may provide useful features. ## Also, please note that software in backports WILL NOT receive any review ## or updates from the Ubuntu security team. deb http://archive.ubuntu.com/ubuntu/ jammy-backports main restricted universe multiverse # deb-src http://archive.ubuntu.com/ubuntu/ jammy-backports main restricted universe multiverse deb http://security.ubuntu.com/ubuntu/ jammy-security main restricted # deb-src http://security.ubuntu.com/ubuntu/ jammy-security main restricted deb http://security.ubuntu.com/ubuntu/ jammy-security universe # deb-src http://security.ubuntu.com/ubuntu/ jammy-security universe deb http://security.ubuntu.com/ubuntu/ jammy-security multiverse # deb-src http://security.ubuntu.com/ubuntu/ jammy-security multiverse then sudo apt-get update but that did not resolve the issue, the errors seemed to be always the same hosts and seemingly same specific packages.

For the curious the build is run from within Ubuntu Jammy Jellyfish (22.04) release, running in a systemd-nspwan container, the docker engine is 'outside' the container in the host os. There are lots of issues attempting to run docker engine from within a container. That helps avoid dependency problems for the build as the build environment Ubuntu Jammy 22.04.x amd64 is stated. https://docs.armbian.com/Developer-Guide_Build-Preparation/ The trick is the 'simple' docker.sock method https://devopscube.com/run-docker-in-docker/ i.e. docker client (e.g. compile.sh) runs from within the Ubuntu Jammy Jellyfish container, but setup /var/run/docker.sock so that it can be accessed from within the container by docker client. And outside the container - the host os can run the docker engine (e.g. dockerd, containerd), but sharing out /var/run/docker.sock so that it is the same unix socket accessed by docker client inside the container. Jumped over many hoops, problems to get to this, but the 'network', 'dns resolver' issues remains a bummer. i'm thinking this 'docker in docker' trick may even make it possible to build from within a docker container. e.g. from one docker container use a Ubuntu Jammy Jellyfish (22.04) and run compile.sh . But that pror to that you need to 'remap' the docker.sock so that it can be accessed from the container. e.g. https://devopscube.com/run-docker-in-docker/

While doing the build, I initially ran into various NO_PUBKEY ... error messages accessing security.ubuntu.com, archive.ubuntu.com repositories. e.g. [🔨] 3.570 W: http://archive.ubuntu.com/ubuntu/dists/jammy-backports/InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/ubuntu-keyring-2018-archive.gpg are ignored as the file is not readable by user '_apt' executing apt-key. [🔨] 3.570 W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://archive.ubuntu.com/ubuntu jammy-backports InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 871920D1991BC93C [🔨] 3.570 W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/jammy/InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 871920D1991BC93C [🔨] 3.570 W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/jammy-updates/InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 871920D1991BC93C [🔨] 3.570 W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/jammy-backports/InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 871920D1991BC93C [🔨] 3.570 W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/jammy-security/InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 871920D1991BC93C it turns out the reply in this post resolves the issue https://askubuntu.com/questions/13065/how-do-i-fix-the-gpg-error-no-pubkey Those using a system installed from the most recent Ubuntu DVD images probably wouldn't hit the issue. But that if you are using an older distribution or that you are trying a build from a distribution other than Ubuntu, this may fix the issue and help 'jump the hoop'.

after quite a few frustrating attempts to setup a built environment, fixing some issues, jumping over some hoops for the build, I managed to get to the 'starting point' of a build ./compile.sh [🌱] uuidgen not found [ uuidgen not installed yet ] [🌱] Using prebuilt Armbian image as base for 'ubuntu-jammy' [ DOCKER_ARMBIAN_BASE_IMAGE: ghcr.io/armbian/docker-armbian-build:armbian-ubuntu-jammy-latest ] [🌿] Docker info [ Docker 19.03.11 Kernel:4.12.14-lp151.28.91-default RAM:31.28GiB CPUs:8 OS:'openSUSE Leap 15.1' hostname 'snoopy1.internal' under 'Linux' - buildx:yes - loop-hacks:yes static-loops:no ] [🌱] Creating [ .dockerignore ] [🌱] Docker launcher [ enabling all extensions looking for Docker dependencies ] [🌱] Extension manager [ processed 27 Extension Methods calls and 82 Extension Method implementations ] [🌱] Adding rootfs encryption related packages [ cryptsetup cryptsetup-initramfs ] [🌱] Preparing rkdevflash host-side dependencies [ rkdevflash ] [🌱] Creating [ Dockerfile; FROM ghcr.io/armbian/docker-armbian-build:armbian-ubuntu-jammy-latest ] [🌱] Armbian docker image [ already exists: ghcr.io/armbian/docker-armbian-build:armbian-ubuntu-jammy-latest ] [🌱] Building [ Dockerfile via 'buildx build --progress=plain --load' ] [🔨] #0 building with "default" instance using docker driver [🔨] [🔨] #1 [internal] load build definition from Dockerfile [🔨] #1 transferring dockerfile: 2.12kB done ... [🔨] #6 [2/6] RUN echo "--> CACHE MISS IN DOCKERFILE: apt packages." && DEBIAN_FRONTEND=noninteractive apt-get -y update && DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends bash git psmisc uuid-runtime bc binfmt-support bison libc6-dev make dpkg-dev gcc ca-certificates ccache cpio debootstrap device-tree-compiler dialog dirmngr dosfstools dwarves flex gawk gnupg gpg imagemagick jq kmod libbison-dev libelf-dev libfdt-dev libfile-fcntllock-perl libmpc-dev libfl-dev liblz4-tool libncurses-dev libssl-dev libusb-1.0-0-dev linux-base locales lsof ncurses-base ncurses-term ntpdate patchutils pkg-config pv qemu-user-static rsync swig u-boot-tools udev uuid-dev zlib1g-dev file tree expect colorized-logs unzip zip pigz xz-utils pbzip2 lzop zstd parted gdisk fdisk aria2 curl wget axel parallel python3-dev python3-distutils python3-setuptools python3-pip python2 python2-dev gcc-x86-64-linux-gnu gcc-aarch64-linux-gnu gcc-arm-linux-gnueabihf gcc-arm-linux-gnueabi gcc-riscv64-linux-gnu debian-archive-keyring libc6-amd64-cross g++-aarch64-linux-gnu g++ btrfs-progs cryptsetup openssh-client f2fs-tools nilfs-tools xfsprogs zerofree qemu-utils qemu-utils libudev-dev libusb-1.0-0-dev dh-autoreconf build-essential gcc-arm-linux-gnueabi gcc-or1k-elf qemu-utils [🔨] #6 0.958 --> CACHE MISS IN DOCKERFILE: apt packages. [🔨] #6 49.04 Ign:1 http://archive.ubuntu.com/ubuntu jammy InRelease [🔨] #6 49.04 Ign:2 http://security.ubuntu.com/ubuntu jammy-security InRelease [🔨] #6 97.09 Ign:3 http://archive.ubuntu.com/ubuntu jammy-updates InRelease ... [🔨] #6 200.2 Err:2 http://security.ubuntu.com/ubuntu jammy-security InRelease [🔨] #6 200.2 Temporary failure resolving 'security.ubuntu.com' ... [🔨] #6 481.5 Err:1 http://archive.ubuntu.com/ubuntu jammy InRelease [🔨] #6 481.5 Temporary failure resolving 'archive.ubuntu.com' [🔨] #6 529.5 Err:3 http://archive.ubuntu.com/ubuntu jammy-updates InRelease [🔨] #6 529.5 Temporary failure resolving 'archive.ubuntu.com' Is anyone else encountering a similar issue? The builds seemed to be failing repeatedly at DNS resolution to the repositories. Didn't manage to get past this point as the builds failed repeatedly here many minutes to like 1/2 hour and abort, many times with no successes so far. They also seem to be the same few accesses and possibly packages. [🔨] #6 481.4 Err:1 http://archive.ubuntu.com/ubuntu jammy InRelease [🔨] #6 481.4 Temporary failure resolving 'archive.ubuntu.com' [🔨] #6 529.4 Err:3 http://archive.ubuntu.com/ubuntu jammy-updates InRelease [🔨] #6 529.4 Temporary failure resolving 'archive.ubuntu.com' [🔨] #6 577.5 Err:4 http://archive.ubuntu.com/ubuntu jammy-backports InRelease [🔨] #6 577.5 Temporary failure resolving 'archive.ubuntu.com' [🔨] #6 577.5 Reading package lists... [🔨] #6 578.1 W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/jammy/InRelease Temporary failure resolving 'archive.ubuntu.com' [🔨] #6 578.1 W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/jammy-updates/InRelease Temporary failure resolving 'archive.ubuntu.com' [🔨] #6 578.1 W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/jammy-backports/InRelease Temporary failure resolving 'archive.ubuntu.com' [🔨] #6 578.1 W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/jammy-security/InRelease Temporary failure resolving 'security.ubuntu.com' [🔨] #6 578.1 W: Some index files failed to download. They have been ignored, or old ones used instead.

linux-sunxi has a page on Orange Pi zero 3 https://linux-sunxi.org/Xunlong_Orange_Pi_Zero3 quite an informative page about the board

check in this thread there are some *unofficial* images created by others and placed elsewhere (not sure if they are still valid), there are various issues e.g. with wifi not working, issues with boot loader etc discussed in the thread to support the new board would take quite a lot of effort off *everyone* who wants to use the board (development and tests, and contnuous maintenance over long term, kernel updates, distribution updates etc, perpetual) and possibly needs to be funded here. but that orange-pi-zero-3 is an important board first of all that it has up to 4GB memory which is much more than orange-pi-zero-2 so it still matters (a lot) there are some efforts at the "bleeding edge" in the mainline kernels, those are very much 'in development' at the "bleeding edge" and those changes have not been back ported in any way into the existing armbian kernels. https://linux-sunxi.org/Xunlong_Orange_Pi_Zero3

a uwe5622 Wifi problem seem to afflict the Orange Pi Zero 3 as well thoughts are it may take using newer drivers and uwe5622 firmware codes https://github.com/orangepi-xunlong/linux-orangepi/tree/orange-pi-6.1-sun50iw9/drivers/net/wireless/uwe5622 i read somewhere that various works on uwe5622 drivers has been done in the 'upstreamed' recent kernels > 6.5 ? There has been complaints that different vendor's uwe5622 drivers creates a problem as they possibly conflict. Hence, it may help to try find the 'upstreamed' uwe5622 driver implementations and perhaps 'backport' it into the current kernels used in armbian e.g. 6.1.31

for ARM based SOCs, a problem is that there is no 'generic' kernel that can support the specific in chip and on board hardware components e.g. the HDMI graphics drivers, all the various components wifi, ethernet, even on chip interfaces such as usb, memory flash, mmc support and even power management, powering on and off and all that are *distinct* and most of that *undocumented* across ARM SOCs, this is true be they 32 bits or 64 bits. which practically means that searching for an 'OS' that is 'compatible' is going to either simply draw a blank or that you are going to get an 'OS' in which many parts are broken, e.g. no HDMI, no graphics drivers, no usb, no wifi, no ethernet, no nothing etc. you simply have to research the challenges supporting all the different boards here. bitness is a different challenge, for one, using 64 bits vs 32 bits may mean gigabytes of gigabytes / billions of all the apps, shared libraries, kernel, drivers etc would need to be recompiled into 64 or 32 bit binaries. effectively needing 2 universes of binaries to support the whole suite of apps

moderators/admins, I'm thinking it could help to put Orange Pi Zero 3 in its own unmaintained boards sub section, it is likely there'd be more threads related to this and to move this thread and the other thread into the new orange pi zero 3 board section

I'd just like to put a note that for wifi, even the propietary drivers seemed 'unstable', I'm not sure if it is just the drivers itself or something else

hi, just like to join this discussion in a 'development' sense it seemed there are some works in the head Linux v6.5-rc1 https://groups.google.com/g/linux-sunxi/c/p64EM9m9inY https://linux-sunxi.org/Xunlong_Orange_Pi_Zero3 https://linux-sunxi.org/Linux_mainlining_effort they seemed to be continued works on H616 mainlining efforts, but that those are working on H618 e.g. Orange Pi zero 3 etc it could be good to look at the head revisions e.g. v6.5 when we 'backport' codes into e.g. v6.1.31 that is used with armbian. that could save a lot of rework if at some point we (armbian) decide to move on and use a new kernel e.g. v6.5 and accordingly, i read a post that say things like the wifi drivers as different vendors tried to implement their own drivers, it creates a 'problem' for the mainlining efforts to attempt to reconcile 2 different versions of the 'same driver'. Hence, it may be good to look at head revisions e.g. v6.5 while 'porting' them back into v6.1.31. it would likely allow us to have 1 version of drivers e.g. from mainline that possibly works on different boards using the same wifi chips etc.

I've been trying the vendor images (non-armbian, but likely an armbian derivative) https://drive.google.com/drive/folders/1CJYrhHyyje9dEY4-t7JhcZBJfdAFBJro https://drive.google.com/drive/folders/10zlO-0mMz-fqRQOKAOWX-mQA_UbN_C1n and the wifi malfunctioned after running for some 1+ days, things got worse as initially i've been able to manually restart the wifi. then some other corruption creep in on the microsd card and I'm not sure the cause of it. note, non-armbian. for armbian, i think wifi etc is still 'work in progress', wifi isn't quite working yet as of last try, as noted in some earlier comments above.

i think orange pi zero 3 is after all gaining popularity as it is an 'upgraded' orange pi zero 2, 2+ with more dram, e.g. like up to 4 GB, that will make a lot of difference for some apps http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-Zero-3.html

there is a new thread open on orange pi zero 3

I'd guess you can try some of the unsupported , user build images a couple of posts back https://github.com/leeboby/armbian-images I've tried the Debian 'server' images on a 2GB board, and the findings are in the comments above. I've also tried the Orange Pi released images, those work better. But that among the surprises, it seemed there are some hardware problems even with those images released by Orange Pi. Ethernet is not working after a while and after a few reboots, things are totally jammed even on the serial console. But that to work with these boards, use a serial console with a usb-uart dongle, as you may not be able to access it over ethernet and/or wifi. quite some details is covered with the comments above.

those look quite interesting, I'm thinking if it may be good to backport those changes back into 6.1.x used with Armbian currently. However, I'd think similarly, it is going to take a lot of work to do the same, including testing etc. another idea which may be quite interesting could be to try the new v6.5 kernel, compile from source, but thinking it through, the steps would likely to be quite similar with tests etc. e.g. that it is less likely to be a 'just works' setup and requires quite a bit of work to have all the peripherals working.

for some reasons I didn't find related docs in the company's web site https://www.marvell.com/products/infrastructure-processors/armada-38x.html those docs links are apparently not accessible but instead stumbled into a copy elsewhere in a web search https://ulli-kroll.de/Downloads/NAS326/A38x-Functional-Spec-PU0A.pdf the interesting section is chapter 26 Real time clock pages 303 accordingly, the real time clock runs on a 32khz crystal, so check your board to see if it is there. if it isn't there, maybe it isn't using the real time clock after all. And that if it is there, find in the source codes for the real time clock implementation, apparently some details about the RTC registers are documented, so those should after all match the func spec. And perhaps you may find your way around the code to 'tweak' the register settings etc. if it is a 'pseudo RTC' i.e. didn't exist, then it is probably a 'simulated' h/w clock which may be written in s/w, it'd take reading the codes to find out that curious facts hope that helps

1 sec every 60 sec? that's a pretty big drift. oh and btw hwclock seemed to have some ways to adjust for drift, but that'd probably means you need to sync your time to NTP

get a phone charging power bank to power the board, charge the battery and power the board, those are the modern UPS otherwise, if it is occasional data, to have it flushed to the disk, the command is usually sync and that does the trick

alternatively, create a swap file or swap partition like Igor mentioned. I'd prefer a swap partition as it is probably a smaller overhead

tried the Debian bookworm image from OrangePi dmesg [ 2282.163357] device wlan0 entered promiscuous mode [ 2282.229125] unisoc_wifi unisoc_wifi wlan0: sprdwl_change_beacon failed [ 2282.229151] unisoc_wifi unisoc_wifi wlan0: sprdwl_cfg80211_start_ap failed to start AP! [ 2282.242846] device wlan0 left promiscuous mode didn't work as well, so it has more to do with the wifi driver code, however, the errors are different. it'd seem there is also some conflicts with wpa_supplicant etc edit: I managed to get hostapd up on OrangePi Z3 using OrangePi's Debian bookworm image after all. apparently, 'limited' options are supported, 802.11g apparently seemed possible. # hostapd.conf # the interface used by the AP interface=wlan0 # bridge, this probably isn't necessary if you are not bridging bridge=br0 # "g" simply means 2.4GHz band hw_mode=g # the channel to use channel=5 # limit the frequencies used to those allowed in the country #ieee80211d=1 # the country code #country_code=US # 802.11n support #ieee80211n=1 # QoS support, also required for full speed on 802.11n/ac/ax #wmm_enabled=1 # the name of the AP ssid=orangepi # 1=wpa, 2=wep, 3=both auth_algs=1 # WPA2 only wpa=2 wpa_key_mgmt=WPA-PSK rsn_pairwise=CCMP wpa_passphrase=somepassword - NetworkManager has to be set as unmanaged for wlan0, nmcli dev set wlan0 managed no this is temporary there is a way to make the confit permanent as well https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/sec-configuring_ip_networking_with_nmcli#configuring-networkmanager-to-ignore-certain-devices disable bluetooth and wpa_supplicant service to avoid conflicts systemctl stop bluetooth.service systemctl disable bluetooth.service systemctl stop wpa_supplicant.service systemctl disable wpa_supplicant.service it would normally be necessary to configure a dhcp server if there is no other on the network or configure a bridge and place wlan0 and the ethernet interface on it. Note that when you are playing with bridging etc, it is advisable to use the uart interface. it is super easy to hose the connected ethernet interface e.g. using nmcli network manager commands and after that there is 'no way' to access the board other than using uart (and perhaps usb gadget) interface. on the OrangePi images, connecting to AP seemed possible wlan0: connected to wifi "wlan0" wifi (unisoc_wifi), 80:A0:53:73:A3:89, hw, mtu 1500 inet4 192.168.2.158/24 route4 192.168.2.0/24 metric 600 route4 default via 192.168.2.1 metric 600

much ado about serial terminal /dev/ttyS0 I've got a weird problem on the OPi Z3, thus far I've seen all the boot messages on the serial console, it turns out it is /dev/ttyS0. However, it doesn't 'accept/receive any inputs'. Hence, I can't login over serial tty. tried > systemctl stop serial-getty@ttyS0.service > echo hello > /dev/ttyS0 -- ok I saw that in the serial terminal :) > cat /dev/ttyS0 -- type something from the other end, nothing > systemctl start serial-getty@ttyS0.service -- ok login prompt appears in the serial terminal, but can't login I got so confused, I tried a 'loop back' test on my serial dongle, i.e. I took out the wire connected to RX pin on the Opi board, and connect it to TX on my usb-uart dongle. type something, ok i saw what i typed 'perfect' take out the wire, nothing, as expected next I plug that wire back to the RX pin on Opi board, oops something jerked on the connection, all gibberish, ok reboot, unplug power replug. Oops, now even ethernet goes out dark oh but suddenly I see the login prompt on my serial console again, type something, username, password voila logged in then to fix ethernet power down from serial console 'systemctl poweroff', unplug, replug again, retried a few times. finally, ... now I've got ethernet and serial tty console back it seemed to be a 'hardware' problem, a pin stuck 'low' or 'high'? well, I'd never know the mystery, but in case a usb-uart dongle is 'not working' try disconnect and reconnect the TX, RX, GND wires oh and about gibberish, like these 1st check your *baud rates*, it'd need to be 115200 bps and 8N1, thereafter it seemed to work 'quite perfect' my USB-uart dongle is actually an stm32f103 'blue pill' board https://stm32-base.org/boards/STM32F103C8T6-Blue-Pill.html running a stm32duino sketch https://github.com/rogerclarkmelbourne/Arduino_STM32/tree/master/STM32F1/libraries/A_STM32_Examples/examples/Communication/USB-uart-w-signals this sketch has got some bugs, hence I'd not recommend it. But in case anyone decides to use that post the questions in https://www.stm32duino.com/ and if i chanced upon it, i'd try to answer it there. but that there are 'cheap and good' usb-uart dongles, e.g. the (original, as in the chip) FT232 dongles and a search for "usb uart" in the usual online marketplaces Amazon, Ebay, Aliexpress etc would turn them up. https://www.amazon.com/s/ref=nb_sb_noss?field-keywords=usb+uart get 3.3v ones

I tried messing with hostapd, running the uwe5622 wifi in AP mode, trying to setup as a WiFi hotspot. used the 'generic' WPA passphrase based configs as like the 'simple' entries https://wiki.gentoo.org/wiki/Hostapd not much success, in dmesg [ 229.654023] (NULL net_device): sprdwl_uninit_fw failed! [ 229.654158] ieee80211 phy0: sprdwl_cfg80211_del_iface driver removing! [ 229.713879] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 229.717841] ieee80211 phy0: sprdwl_cfg80211_del_iface driver removing! [ 240.180745] ieee80211 phy0: sprdwl_cfg80211_del_iface driver removing! [ 240.217512] (NULL net_device): sprdwl_init_fw failed! [ 240.217801] ieee80211 phy0: sprdwl_cfg80211_del_iface driver removing! [ 339.310954] unisoc_wifi unisoc_wifi wlan0: sprdwl_uninit_fw failed! [ 339.311346] unisoc_wifi unisoc_wifi wlan0: sprdwl_uninit_fw failed! [ 341.419621] unisoc_wifi unisoc_wifi wlan0: sprdwl_uninit_fw failed! [ 341.420389] unisoc_wifi unisoc_wifi wlan0: sprdwl_uninit_fw failed! [ 343.663494] unisoc_wifi unisoc_wifi wlan0: sprdwl_uninit_fw failed! then in /var/log/syslog 2023-08-08T21:56:25.386610+08:00 orangepizero3 wpa_supplicant[910]: wlan0: CTRL-EVENT-SCAN-FAILED ret =-5 retry=1 2023-08-08T21:56:26.389340+08:00 orangepizero3 wpa_supplicant[910]: wlan0: CTRL-EVENT-SCAN-FAILED ret =-5 retry=1 2023-08-08T21:56:27.391984+08:00 orangepizero3 wpa_supplicant[910]: wlan0: CTRL-EVENT-SCAN-FAILED ret =-5 retry=1 2023-08-08T21:56:27.958806+08:00 orangepizero3 wpa_supplicant[910]: p2p-dev-wlan0: CTRL-EVENT-DSCP-PO LICY clear_all 2023-08-08T21:56:27.960039+08:00 orangepizero3 systemd[1]: Stopping wpa_supplicant.service - WPA supp licant... ^ those are consistent with nmcli d wifi list returning an empty list further down on hostapd 2023-08-08T21:58:17.537085+08:00 orangepizero3 systemd[1]: Starting hostapd.service - Access point and authentication server for Wi-Fi and Ethernet... 2023-08-08T21:58:17.637276+08:00 orangepizero3 hostapd[1775]: nl80211: Could not configure driver mode 2023-08-08T21:58:17.637497+08:00 orangepizero3 hostapd[1775]: nl80211: deinit ifname=wlan0 disabled_11b_rates=0 2023-08-08T21:58:17.637649+08:00 orangepizero3 hostapd[1775]: nl80211 driver initialization failed. 2023-08-08T21:58:17.637735+08:00 orangepizero3 hostapd[1775]: wlan0: interface state UNINITIALIZED->DISABLED 2023-08-08T21:58:17.637818+08:00 orangepizero3 hostapd[1775]: wlan0: AP-DISABLED 2023-08-08T21:58:17.637925+08:00 orangepizero3 hostapd[1775]: wlan0: CTRL-EVENT-TERMINATING 2023-08-08T21:58:17.638017+08:00 orangepizero3 hostapd[1775]: hostapd_free_hapd_data: Interface wlan0 wasn't started 2023-08-08T21:58:17.639465+08:00 orangepizero3 kernel: [ 339.310954] unisoc_wifi unisoc_wifi wlan0: sprdwl_uninit_fw failed! 2023-08-08T21:58:17.639480+08:00 orangepizero3 kernel: [ 339.311346] unisoc_wifi unisoc_wifi wlan0: sprdwl_uninit_fw failed! 2023-08-08T21:58:17.641144+08:00 orangepizero3 systemd[1]: hostapd.service: Control process exited, code=exited, status=1/FAILURE 2023-08-08T21:58:17.641602+08:00 orangepizero3 systemd[1]: hostapd.service: Failed with result 'exit-code'.

USB works, managed to mount a sd card in a usb card reader and examine some files. [ 890.861713] usb 1-1: new high-speed USB device number 4 using ehci-platform [ 891.021896] usb 1-1: New USB device found, idVendor=8564, idProduct=4000, bcdDevice= 0.04 [ 891.021926] usb 1-1: New USB device strings: Mfr=3, Product=4, SerialNumber=2 [ 891.021944] usb 1-1: Product: Transcend [ 891.021957] usb 1-1: Manufacturer: TS-RDF5A [ 891.021971] usb 1-1: SerialNumber: 000000000004 [ 891.023086] usb-storage 1-1:1.0: USB Mass Storage device detected [ 891.023810] scsi host0: usb-storage 1-1:1.0 [ 891.066751] usbcore: registered new interface driver uas [ 892.041439] scsi 0:0:0:0: Direct-Access TS-RDF5A Transcend 0004 PQ: 0 ANSI: 6 [ 892.042515] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 892.413021] sd 0:0:0:0: [sda] 62552064 512-byte logical blocks: (32.0 GB/29.8 GiB) [ 892.414640] sd 0:0:0:0: [sda] Write Protect is off [ 892.414655] sd 0:0:0:0: [sda] Mode Sense: 21 00 00 00 [ 892.416125] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 892.424143] sda: sda1

cool, congrats the uwe5622 wifi apparently have issues, while wifi scan using nmcli d wifi list initially works, attempts to connect to a station results in a dump recorded in dmesg, some abstracts: [ 6.931488] wifi ini path = /lib/firmware/wifi_2355b001_1ant.ini [ 6.957269] sprdwl:sprdwl_get_fw_info length mismatch: len_count=83, r_len=89 [ 6.957278] sprdwl:sprdwl_get_fw_info, drv_version=1, fw_version=2, compat_ver=0 [ 6.957282] sprdwl:chip_model:0x2355, chip_ver:0x0 [ 6.957286] sprdwl:fw_ver:35940, fw_std:0x7f, fw_capa:0x120fff [ 6.957290] sprdwl:mac_addr:24:b7:2a:46:13:f7 [ 6.957296] sprdwl:credit_capa:TX_WITH_CREDIT [ 6.957298] sprdwl:ott support:0 ... lots of verbose stuff like [ 146.832213] sdiohal:chn8 tx push old, cmdid=25, mstime=146361, record_time=146361 [ 146.832222] chn8 tx push old: 00 00 00 00 .........;...... [ 146.832273] WCN_ERR: mdbg_dump_data dump memory error:-110 [ 146.832280] WCN: mdbg dump bt modem 0 ok! [ 146.832284] WCN_ERR: read HCI_ARM_WR_RD_MODE reg error:-1 [ 146.832291] WCN_ERR: mdbg_dump_data dump memory error:-1 [ 146.832295] WCN: mdbg dump bt_cmd buf 0 ok! [ 146.832298] WCN_ERR: mdbg_dump_data dump memory error:-1 [ 146.832302] WCN: mdbg dump btevent buf 0 ok! [ 146.832306] WCN_ERR: mdbg_dump_data dump memory error:-1 ... [ 165.825379] NETDEV WATCHDOG: wlan0 (unisoc_wifi): transmit queue 0 timed out [ 165.825509] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:525 dev_watchdog+0x230/0x240 [ 165.825554] Modules linked in: algif_hash algif_skcipher af_alg bnep hci_uart btqca btrtl btbcm btintel bluetooth ecdh_generic ecc sunrpc lz4hc lz4 zram binfmt_misc polyval_ce polyval_generic sunxi_cir rc_core sunxi_cedrus(C) videobuf2_dma_contig v4l2_mem2mem videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc sprdwl_ng sunxi_addr cfg80211 sprdbt_tty rfkill uwe5622_bsp_sdio fuse dm_mod motorcomm dw_hdmi_cec dwmac_sun8i mdio_mux display_connector [ 165.825855] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G C 6.1.31-sunxi64 #1 [ 165.825874] Hardware name: OrangePi Zero3 (DT) [ 165.825885] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) so connect failed thereafter nmcli d wifi list returns an empty list I'm not sure how to recover from that, disable and enable the IF did not help sudo ip link set wlan0 down sudo ip link set wlan0 up nmcli d wifi list still returns an empty list lsmod ... uwe5622_bsp_sdio 204800 2 sprdbt_tty,sprdwl_ng uwe5622_bsp_sdio is linked to sprdbt_tty,sprdwl_ng, which in turns is linked to other stuff, hence it can't be simply 'rmmod'ed, reboot works, recovers the wifi scanning, but not connecting. (witnessed another dmesg dump after reboot, but initially "nmcli d wifi list" still works, it stops after a while and return an empty list