Image | Orange Pi Zero 3

[dirkhh]

Creating an image request

Formal device information

• Device name | Orange Pi Zero 3
• Official product URL | OrangePi.org
• GitHub resource URL (if available) | not GitHub, but a seemingly useful Wiki
• Image download URL | Debian for 1G RAM image... it's odd that there are three different images, though, depending on the amount of RAM installed

Is the SBC officially supported by the Debian installer?

• no

If not, is a reliable 3rd party Debian image available for this SBC?

• from the Wiki it appears that there are images (see link above). How reliable...? no idea.

If not, are there install instructions for Debian available?

Google Drive link

• ...

[dirkhh]

so... how does one go about working towards adding a new image? This is such a cool board (great price point and more capable than anything else at that price point - wired and wireless network, 1GB (up to 4GB) - decent availability and under $25 / €30)

[MichaIng]

Will be added with next release. We have samples already.

[MichaIng]

There is a mainline kernel device tree in upcoming Linux 6.6: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero3.dts

Ethernet seems to be not 100% stable yet: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f1b3ddb3ecc2eec1f912383e01156c226daacfab
And likely other features are missing. The commit message indicates that basically only the onboard features defined in the device tree are what is functional, i.e. no WiFi, no HDMI. Will test it regardless, but I think for now we should use the vendor kernel sources, which are Linux 6.1 at least: https://github.com/orangepi-xunlong/linux-orangepi/tree/orange-pi-6.1-sun50iw9

Why does the device tree from Orange Pi kernel sources define it as Allwinner H616, while it is actually an H618, correctly defined in mainline Linux? This guarantees havoc when switching between kernels, respectively makes the vendor U-Boot default non-functional with mainline kernel as of the necessarily false device tree name. There are always these little annoying inconsistencies which cause distributors a lot of problems when dealing with vendor kernel and bootloader sources ... I'll never understand the reason for this:

• https://github.com/orangepi-xunlong/linux-orangepi/blob/orange-pi-6.1-sun50iw9/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero3.dts
• http://www.orangepi.org/orangepiwiki/index.php/Orange_Pi_Zero_3#Hardware_Features_of_Orange_Pi_Zero_3

[dirkhh]

I have been playing with the vendor kernel (well, with their Debian distro) to assess how useful this board is - and there wifi seems to work, I haven't seen ethernet issue (but then, I haven't exactly put a lot of load on it).
The vendor kernel refers to sun50iw9 as the board identifier. But then it does indeed claim to be an h616... I didn't even notice that. UGH.

[MichaIng]

Ah yes, the limitations I listed are with mainline kernel, as the device tree was just added very recently there. Hence for now we should stay with vendor kernel.

[bigross8]

Any progress on making the image? This board is excellent for the price and I'm planning to replace my NanoPi NEO with it. A DietPi image on OPi Zero 3 would be sweet. Thanks.

[daniel-mller-87]

I ordered the same board today. Would be excellent to have a dietpi image ready for use.

[dirkhh]

I used mine on and off with their factory build. The board is great - I'm really impressed at the price point (at least from AliExpress). But their image sucks :)

[MichaIng]

First step done: 5c20bbc
So far more dummy entries, but it allows us to generate images with stable branch during next development cycle, as only the build tools and in case linux branches need to be further extended.

[daniel-mller-87]

First step done: 5c20bbc So far more dummy entries, but it allows us to generate images with stable branch during next development cycle, as only the build tools and in case linux branches need to be further extended.

Thx.

[daniel-mller-87]

any news? Got my hardware today but the standard image isn't the best. Will you support 4GB Ram as well?

[bigross8]

any news? Got my hardware today but the standard image isn't the best. Will you support 4GB Ram as well?

I tried the DietPi installation script (https://dietpi.com/docs/hardware/#make-your-own-distribution), but unfortunately the board can't seem to connect to my network after a reboot. I tried both Wi-Fi and Ethernet, setting AUTO_SETUP_AUTOMATED flag to 1 in /boot/dietpi.txt, beta and dev branch of the installer, and different versions of the official Orange Pi Debian image (both 1.0.0 and 1.0.2). I don't have a Micro HDMI cable or an UART reader so I don't know if there's even any output.

[MichaIng]

I guess some firmware is missing. I'll start working on it this week.

[daniel-mller-87]

I'm looking forward to. I also tried to make an image. It's possible to do so from the 4GB Bullseye Image. And then upgrade to Bookworm during the dietpi Script. It's not stable however. The only solution to get ethernet working ist do unplug power cable and then plug back in. If I try to reboot via terminal it just says: Failed to connect to bus: No such file or directory. Afterwards it becomes unreachable.

[bigross8]

I guess some firmware is missing. I'll start working on it this week.

I borrowed a Micro HDMI cable, and the board boots up fine. In dietpi-config however, the Ethernet and WiFi adapters are not found. So you're right about this, there's definitely firmware missing.

[daniel-mller-87]

When will the next Dietpi released?

[Joulinar]

#6704

[daniel-mller-87]

Thx a lot. Does it mean orange pi zero 3 will be supported with the upcoming release? Doesn't seem to be that easy.

[MichaIng]

Images are ready for testing: https://dietpi.com/downloads/images/testing/

They currently use the unmodified kernel, dtb, bootloader and firmware packages from Orange Pi. I'll do own builds, but use the same build system, since it is an older fork of Armbian (the build system, not the package sources), which allows some consistency and potentially a simple migration if Armbian themselves add support in the future.

[MichaIng]

The code to support it as an own hardware ID has been added with last release already. Now it has been added to our build script. So yes, initial support is there, now I want to enhance the kernel build and testing is needed.

[daniel-mller-87]

Alright thx a lot. I just tried the image. Booted fine. So far I still see two major problems

1. reboot over ssh doesn't work:
   I'm receiving: Failed to connect to bus: No such file or directory
   only unplugging from power helps

2. if I let it run for some time. Top will always show utilisation of 1.0 So something unnecessary is running. When tried to create an image on my own I had this same issue but just deleted user orange pi to "solve" it. Maybe this is resolved when you do your own build.

[MichaIng]

Failed to connect to bus: No such file or directory

Why the hack do others still see this while we added a workaround already which works perfectly fine on all my systems. Can you paste the output of the following command:

declare -f reboot
ls -l /etc/systemd/system/systemd-logind.service

And you do use the reboot command or some other, like shutdown -r or systemctl reboot?
And in case you use reboot and the above commands only tell that no such file exists: Can you repeat the exact setup steps you did after flashing the image?

However, this is a visual error only and does not actually prevent reboot. I guess it does actually reboot but does not come online anymore since the Ethernet device is lost. At least this is what I am facing: On a reboot, the Ethernet adapter is detected for a short time, and the interface generated, but removed quickly again. I need to check back with Orange Pi. After cold boot (power cycle), this does not happen. Also no such issue with WiFi.

[daniel-mller-87]

Shure here's the output. I'm using reboot now. I don't care if it's only a message. But as you say only cold boot reenables ethernet functionality.

root@DietPi:~# declare -f reboot
ls -l /etc/systemd/system/systemd-logind.service
reboot () 
{ 
    local command='reboot';
    for i in "$@";
    do
        case $i in 
            '-p' | '--poweroff')
                command='poweroff'
            ;;
            '--reboot' | '--no-wall')
                :
            ;;
            '--halt')
                command='halt'
            ;;
            *)
                /sbin/reboot "$@";
                return $?
            ;;
        esac;
    done;
    systemctl start "$command.target"
}
lrwxrwxrwx 1 root root 9 Nov 10 00:35 /etc/systemd/system/systemd-logind.service -> /dev/null

[ag88]

perhaps try 6.7?
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/commit/?h=sunxi/for-next&id=b9622937d95809ef89904583191571a9fa326402

arm64: dts: allwinner: h616: update emac for Orange Pi Zero 3[sunxi-fixes-for-6.7-1]
(https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/tag/?h=sunxi-fixes-for-6.7-1)[sunxi/fixes-for-6.7]
(https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/log/?h=sunxi/fixes-for-6.7)
The current emac setting is not suitable for Orange Pi Zero 3,
move it back to Orange Pi Zero 2 DT. Also update phy mode and
delay values for emac on Orange Pi Zero 3.
With these changes, Ethernet now looks stable.
Fixes: 322bf103204b ("arm64: dts: allwinner: h616: Split Orange Pi Zero 2 DT")
Signed-off-by: Chukun Pan amadeus@jmu.edu.cn
Reviewed-by: Jernej Skrabec jernej.skrabec@gmail.com
Link: https://lore.kernel.org/r/20231029074009.7820-2-amadeus@jmu.edu.cn
Signed-off-by: Jernej Skrabec jernej.skrabec@gmail.com

a thing though is it mentions 6.7-1, I'm not sure the current edge is just 6.7 or the latest in 6.7.x.

[MichaIng]

This commit has been applied to Linux 6.6 as well: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit?h=linux-6.6.y&id=b352ebe
Note that bug fixes are commonly applied to older Linux versions, especially LTS. So for commits older than a week, usually no need to go with edge kernel, at least worth to check back whether they have really not been applied to LTS yet.

@johndo100 @bigross8 @daniel-mller-87 @dirkhh
Does it work well in your case with the new kernel/images, i.e. does the Ethernet adapter survive reboots? And does someone else have a 1.5G variant to verify whether this really somehow behaves differently?

[StaticReverb]

And does someone else have a 1.5G variant to verify whether this really somehow behaves differently?

Hi @MichaIng -- I've got a 1.5G variant here I can test if needed.

Is this the version you are trying to see if eth0 survives sudo reboot?

DietPi_OrangePiZero3-1.5G-ARMv8-Bookworm.img.xz 2024-01-26 00:01 175M

[MichaIng]

Is this the version you are trying to see if eth0 survives sudo reboot?

Yes, exactly, many thanks 🙂!

[StaticReverb]

So clean etch of that version, booted to 1.5G -- Setup finished, IP allocated and assigned to eth0.

sudo reboot

eth0 and Wi-Fi disappear.

Cold boot and of course they come back and function fine.

[dirkhh]

@johndo100 @bigross8 @daniel-mller-87 @dirkhh Does it work well in your case with the new kernel/images, i.e. does the Ethernet adapter survive reboots?

Mine doesn't boot with this image:
https://dietpi.com/downloads/images/testing/DietPi_OrangePiZero3-ARMv8-Bookworm.img.xz

Let me rephrase: this is headless - I'll need to hunt around for cables to connect it to a screen... The green LED is solid, the red LED blinks twice then pauses, repeat. And it never powers up the ethernet port.

[Joulinar]

Do you have a serial adapter?

[MichaIng]

eth0 and Wi-Fi disappear.

WiFi as well? Does this happen to anyone else or did happen before with the Orange Pi kernel as well? 🤔

Mine doesn't boot with this image:
https://dietpi.com/downloads/images/testing/DietPi_OrangePiZero3-ARMv8-Bookworm.img.xz

Let me rephrase: this is headless - I'll need to hunt around for cables to connect it to a screen... The green LED is solid, the red > LED blinks twice then pauses, repeat. And it never powers up the ethernet port.

Hmm, looks like a kernel crash: In bootloader stage, the red LED is solid. When the kernel loads, it switches so the green LED becomes solid, and the red LED instead switches to heartbeat. If it blinks twice only, it seems to have crashed after the first heartbeat, in early kernel loading/boot stage. A screen could be helpful to see the kernel error/last log, which hopefully gives a hint.

Uff, I wonder whether we get this stable any soon. I was so optimistic since everything works perfectly find with my Zero 3 with the Armbian kernel + bootloader, and with the Orange Pi bootloader as well, aside of flaky SSH I/O when using WiFi. But each individual board seems to behave differently, starting with the significantly different temperature (+-5-10 °C idle is crazy), how disappearing Ethernet is fixed for 1/2/4 GB, but not for 1.5G, WiFi disappearing for some as well, kernel errors for others. With such significant issues, no way to publish images on our website 😞.

[dirkhh]

Do you have a serial adapter?

I should have the right HDMI cable... Somewhere.
Not sure what serial adapter would work here.

[MichaIng]

Btw @dirkhh, how much RAM does your's have?

Not sure what serial adapter would work here.

Serial console output would be best, indeed, which can be scrolled compared to HDMI. Any 3-cable UART adapter will work, using the debug UART at the 3 dedicated pins.

I'm also flashing the image again, just to assure I did not mess up something with it.

[dirkhh]

Btw @dirkhh, how much RAM does your's have?

2G Edited to correct: 1G -- I thought I had a 2G but when I just checked again, it claims 1.

Not sure what serial adapter would work here.

Serial console output would be best, indeed, which can be scrolled compared to HDMI. Any 3-cable UART adapter will work, using the debug UART at the 3 dedicated pins.

More searching in my ginormous pile of cables 🤣

Good / strange news in the meantime.
Moved the OPiZero3 to a different bench where I was able to connect it to a monitor. Here it booted and is now on the network, doing its thing.
This is a different power supply, so maybe the other one doesn't like the OPiZero3? Not sure. but hey, this is progress.

I'm also flashing the image again, just to assure I did not mess up something with it.

Nah, that was all on my side, it seems.

Now comes the moment we have all been waiting for...

reboot

🎉🎉🎉

Ethernet comes back.

Any output you would like to see from this baby?

And: WELLDONE @MichaIng

[StaticReverb]

eth0 and Wi-Fi disappear.

WiFi as well? Does this happen to anyone else or did happen before with the Orange Pi kernel as well? 🤔

@MichaIng Forgive me... Bonehead move on my end. Wi-fi does not disappear on sudo reboot. I simply had never turned it on. So it was not present even on cold boot. Sigh.

OK. So I fixed that to see what it really did and as expected the wi-fi does survive a simple reboot.

In other words, eth0 is pulling an IP from my vlan1 and wifi pulling from vlan30 all works on cold boot.

Sudo reboot and wi-fi remains and pulls IP from VLAN30 - eth0 has checked out, with double red flash from board LED.

Cold boot it and both adapters come back with IPs as expected.

Let me know what info or logging you'd like and I'll pull it for you. Image is just sitting on a spare SD card so I can do whatever you need with it.

[MichaIng]

Ah great, many thanks for retesting. Okay at least the 1/2/4 GB variants seem to be fine now, 1.5G still loses Ethernet.

@StaticReverb I also messed something up regarding WiFi: When using it for firstrun setup, the kernel module needs to be loaded, of course, and I removed that part form the installer, once I added it to the dietpi-config toggle. That runs within the installer as well, but there the module is not enabled, since images are built within a container, and we check for the WiFi module via modprobe -n sprdwl_ng before actually enabling it, which of course cannot work in a container. New images are currently building, with the WiFi module enabled OOTB.

[johndo100]

Hi, I've just tried with zero3 1GB.
The second boot still lost network but after that it is ok.

dietpi@DietPi:~$ uname -a
Linux DietPi 6.6.13-current-sunxi64 #3 SMP Sat Jan 20 10:51:49 UTC 2024 aarch64 GNU/Linux

opi-zero3-dietpi.log

eth0 is no longer use as default network interface name from Debian 12, they changed it to end0 btw.

[deg011]

Orange Pi Zero 3 1gb second boot ok
ethernet and wifi connect ok

[PJVervoorn]

Found and tested a new test image (build date 27/01) in the testing directory.
The ethernet softboot issue persists, but with this image wifi doesn't work anymore (at all).
Dietpi config reports:

Ethernet : Available | [On] | Connected 
WiFi     : Not Found | [On] | Disconnected

[  OK  ] DietPi-WiFiDB | mv /boot/dietpi-wifi.txt /var/lib/dietpi/dietpi-wifi.db
[  OK  ] DietPi-WiFiDB | mkdir -p /etc/wpa_supplicant
[  OK  ] DietPi-WiFiDB | eval > /var/lib/dietpi/dietpi-wifi.db
[ INFO ] DietPi-WiFiDB | Applied WiFi DB slot 0 with SSID ""
[ INFO ] DietPi-WiFiDB | Applied WiFi DB slot 1 with SSID ""
[ INFO ] DietPi-WiFiDB | Applied WiFi DB slot 2 with SSID ""
[ INFO ] DietPi-WiFiDB | Applied WiFi DB slot 3 with SSID ""
[ INFO ] DietPi-WiFiDB | Applied WiFi DB slot 4 with SSID ""
[  OK  ] DietPi-WiFiDB | chown root:root /var/lib/dietpi/dietpi-wifi.db /etc/wpa_supplicant/wpa_supplicant.conf
[  OK  ] DietPi-WiFiDB | chmod 600 /var/lib/dietpi/dietpi-wifi.db /etc/wpa_supplicant/wpa_supplicant.conf
[ SUB2 ] DietPi-Set_hardware > wifimodules (enable)
[  OK  ] DietPi-Set_hardware | eval echo 'sprdwl_ng' > /etc/modules-load.d/dietpi-enable_wifi.conf
[  OK  ] DietPi-Set_hardware | rm /etc/modprobe.d/dietpi-disable_wifi.conf
[ INFO ] DietPi-Set_hardware | Please wait, enabling WiFi modules...
[  OK  ] DietPi-Set_hardware | modprobe cfg80211
[  OK  ] DietPi-Set_hardware | modprobe sprdwl_ng
[ INFO ] DietPi-Set_hardware | Checking for required APT packages: iw wireless-tools wpasupplicant wireless-regdb
[  OK  ] wifimodules enable | Completed

Probably unrelated: UBoot probes for an AXP305, but the Zero3 has an AXP313.
UBoot:

U-Boot SPL 2021.07-orangepi (Sep 28 2023 - 09:16:39 +0800)
...
INFO:    PMIC: Probing AXP305 on RSB
ERROR:   RSB: set run-time address: 0x10003
INFO:    Could not init RSB: -65539

Kernel:

[    1.227534] axp20x-i2c 0-0036: AXP20x variant AXP313a found
[    1.227722] axp20x-regulator axp20x-regulator: DCDC frequency on AXP313a is fixed to 3 MHz.
[    1.227741] axp20x-regulator axp20x-regulator: Error setting dcdc frequency: -22
[    1.237903] axp20x-i2c 0-0036: AXP20X driver loaded

[bigross8]

I have the 1GB version, Ethernet works after every restart with the testing image from January 27th. Tried the same image on Orange Pi Zero 2W 1GB too, also works great, but I can't turn off the red LED through dietpi-config.

[Joulinar]

did you tried dietpi-led_control. At least I can turn off the red blinking LED

[bigross8]

Yes, I tried to change the LEDs through dietpi-led_control, haven't tried to do it manually. Both LEDs can be turned off on Zero 3, but on Zero 2W the red LED stays on no matter which option I choose. The green LED works though.

[MichaIng]

Please keep this topic for Zero 3 only. It is totally expected that the same image without modification does not work on Zero 2, especially when it is about such hardware device nodes.

For Zero 2, see the other topic, especially this post about switching to the correct device tree: #6827 (comment)
But a simple better solution is to use the correct bootloader which picks the correct device tree automatically.

@johndo100

eth0 is no longer use as default network interface name from Debian 12, they changed it to end0 btw.

Not sure what you are referring to. Linux assigns ethN and wlanN, this never changed. What did change (and is changing since years) is that systemd overrides these names to apply so called "predictable" interface names, like enp0s1 or enp1s3f0 or wlp1s0 for WiFi, or wlx800e1319c734. There are in fact a ton of different approaches/schemes, and they change by times, hence are assured to be individual and persistent on reboot, but can change on distro upgrades, and are not intuitive/handy to remember. The endN name is a new naming scheme added by systemd recently, for network interfaces defined via device tree, hence onboard ARM/SBC interfaces. Having this change again, just shows how volatile these names are, hence we intentionally tell systemd to not change the names but keep what Linux (the kernel) assigns via net.ifnames=0 kernel command-line parameter. Otherwise you would have seen a lot different longer interfaces names, and broken network on distro upgrades etc. We will probably lift this, and have systemd apply its thing in the future, but we need to first rework our network config tool(s) for this.

@PJVervoorn

but with this image wifi doesn't work anymore (at all).

Was this the same when you upgraded the kernel on the old image? Can you check whether the kernel module was loaded?

lsmod | grep sprdwl_ng

And are there any kernel errors shown regarding this?

dmesg -l 0,1,2,3

The WiFi chip should be AW859A on all Zero 3 variants, so no idea why it would behave differently between 1.5 and 1/2/4 GB RAM variants.

[PJVervoorn]

...
@PJVervoorn

but with this image wifi doesn't work anymore (at all).

Was this the same when you upgraded the kernel on the old image? Can you check whether the kernel module was loaded?

lsmod | grep sprdwl_ng

And are there any kernel errors shown regarding this?

dmesg -l 0,1,2,3

The WiFi chip should be AW859A on all Zero 3 variants, so no idea why it would behave differently between 1.5 and 1/2/4 GB RAM variants.

Sorry, I already deleted the previous test images.
The current one fails: Linux DietPi 6.6.13-current-sunxi64 #3 SMP Sat Jan 20 10:51:49 UTC 2024 aarch64 GNU/Linux

lsmod | grep sprdwl_ng

sprdwl_ng             344064  0
uwe5622_bsp_sdio      204800  1 sprdwl_ng
sunxi_addr             16384  1 sprdwl_ng
cfg80211              385024  1 sprdwl_ng

dmesg -l 0,1,2,3

[    1.229358] sun50i-h616-pinctrl 300b000.pinctrl: request() failed for pin 224
[    1.229376] sun50i-h616-pinctrl 300b000.pinctrl: pin-224 (5000000.serial) status -517
[    1.229393] sun50i-h616-pinctrl 300b000.pinctrl: could not request pin 224 (PH0) from group PH0  on device 300b000.pinctrl
[    1.229412] dw-apb-uart 5000000.serial: Error applying setting, reverse things back
[    1.230151] debugfs: Directory '1100000.mixer' with parent 'regmap' already present!
[    1.230187] debugfs: Directory '1100000.mixer' with parent 'regmap' already present!
[    1.248293] sun50i-h616-pinctrl 300b000.pinctrl: request() failed for pin 64
[    1.248311] sun50i-h616-pinctrl 300b000.pinctrl: pin-64 (5010000.spi) status -517
[    1.248328] sun50i-h616-pinctrl 300b000.pinctrl: could not request pin 64 (PC0) from group PC0  on device 300b000.pinctrl
[    1.248347] sun6i-spi 5010000.spi: Error applying setting, reverse things back
[    1.254588] sun50i-h616-pinctrl 300b000.pinctrl: request() failed for pin 210
[    1.254606] sun50i-h616-pinctrl 300b000.pinctrl: pin-210 (300b000.pinctrl:210) status -517
[    1.255462] sun50i-h616-pinctrl 300b000.pinctrl: request() failed for pin 160
[    1.255480] sun50i-h616-pinctrl 300b000.pinctrl: pin-160 (4020000.mmc) status -517
[    1.255502] sun50i-h616-pinctrl 300b000.pinctrl: could not request pin 160 (PF0) from group PF0  on device 300b000.pinctrl
[    1.255523] sunxi-mmc 4020000.mmc: Error applying setting, reverse things back
[    1.255550] sun50i-h616-pinctrl 300b000.pinctrl: request() failed for pin 76
[    1.255567] sun50i-h616-pinctrl 300b000.pinctrl: pin-76 (300b000.pinctrl:76) status -517
[    7.125521] WCN_ERR: dts node for bt_wake not found
[    9.113866] wifi ini path = /lib/firmware/wifi_2355b001_1ant.ini
[    9.561706] sprdwl:sprdwl_get_fw_info length mismatch: len_count=83, r_len=89
[    9.568957] sprdwl:sprdwl_get_fw_info, drv_version=1, fw_version=2, compat_ver=0
[    9.576365] sprdwl:chip_model:0x2355, chip_ver:0x0
[    9.581173] sprdwl:fw_ver:0, fw_std:0x7f, fw_capa:0x120f7f
[    9.586672] sprdwl:mac_addr:e0:51:d8:b9:ca:07
[    9.591041] sprdwl:credit_capa:TX_WITH_CREDIT
[    9.595416] sprdwl:ott support:0
[  371.442375] WCN_ERR: dts node for bt_wake not found
[  371.588648] Error: Driver 'sdiohal' is already registered, aborting...
[  371.595227] sdiohal err:sdio_register_driver error :-16
[  374.756624] WCN_ERR: wait SDIO rescan card time out
[  374.761553] WCN_ERR: chip power on fail
[  374.765417] sdiohal err:sdiohal_runtime_put line 1755 not have card
[  374.788879] sdiohal err:sdiohal_tx_thread line 152 not have card
[  377.828612] sprdwl:[WIFI_CMD_SYNC_VERSION]timeout
[  377.833386] sprdwl:ctx_id:0 cmd: WIFI_CMD_SYNC_VERSION[9] rsp timeout (mstime = 374784), num=1
[  377.842050] sprdwl:SYNC CMD ERROR!!
[  377.845654] sprdwl:sprdwl_tx_deinit cmd not yet transmited, cmd_send:1, cmd_poped:0
[  387.078523] sprdwl:sprdwl_msg_deinit ref not ok! wait for pop!

[PJVervoorn]

Tested this morning's image.

On the first try, the boot didn't complete, the ethernet lights were off and no dhcp address is requested.
Maybe it's waiting for an ip address?
The heartbeat led kept flashing.

The second try completed and I could ssh to the device.
WiFi still doesn't work, but I see some traces via uart.
I have atached both the uart and ssh logs.
SSH.txt
UART.txt

dmesg -l 0,1,2,3

[    1.229619] sun50i-h616-pinctrl 300b000.pinctrl: request() failed for pin 224
[    1.229636] sun50i-h616-pinctrl 300b000.pinctrl: pin-224 (5000000.serial) status -517
[    1.229654] sun50i-h616-pinctrl 300b000.pinctrl: could not request pin 224 (PH0) from group PH0  on device 300b000.pinctrl
[    1.229673] dw-apb-uart 5000000.serial: Error applying setting, reverse things back
[    1.230418] debugfs: Directory '1100000.mixer' with parent 'regmap' already present!
[    1.230455] debugfs: Directory '1100000.mixer' with parent 'regmap' already present!
[    1.248529] sun50i-h616-pinctrl 300b000.pinctrl: request() failed for pin 64
[    1.248546] sun50i-h616-pinctrl 300b000.pinctrl: pin-64 (5010000.spi) status -517
[    1.248563] sun50i-h616-pinctrl 300b000.pinctrl: could not request pin 64 (PC0) from group PC0  on device 300b000.pinctrl
[    1.248583] sun6i-spi 5010000.spi: Error applying setting, reverse things back
[    1.254964] sun50i-h616-pinctrl 300b000.pinctrl: request() failed for pin 210
[    1.254981] sun50i-h616-pinctrl 300b000.pinctrl: pin-210 (300b000.pinctrl:210) status -517
[    1.255848] sun50i-h616-pinctrl 300b000.pinctrl: request() failed for pin 160
[    1.255866] sun50i-h616-pinctrl 300b000.pinctrl: pin-160 (4020000.mmc) status -517
[    1.255884] sun50i-h616-pinctrl 300b000.pinctrl: could not request pin 160 (PF0) from group PF0  on device 300b000.pinctrl
[    1.255903] sunxi-mmc 4020000.mmc: Error applying setting, reverse things back
[    1.256017] sun50i-h616-pinctrl 300b000.pinctrl: request() failed for pin 76
[    1.256038] sun50i-h616-pinctrl 300b000.pinctrl: pin-76 (300b000.pinctrl:76) status -517
[    7.315696] WCN_ERR: dts node for bt_wake not found
[    9.204863] wifi ini path = /lib/firmware/wifi_2355b001_1ant.ini
[    9.235374] sprdwl:sprdwl_get_fw_info length mismatch: len_count=83, r_len=89
[    9.242515] sprdwl:sprdwl_get_fw_info, drv_version=1, fw_version=2, compat_ver=0
[    9.249913] sprdwl:chip_model:0x2355, chip_ver:0x0
[    9.254708] sprdwl:fw_ver:0, fw_std:0x7f, fw_capa:0x120f7f
[    9.260196] sprdwl:mac_addr:e0:51:d8:b9:ca:07
[    9.264557] sprdwl:credit_capa:TX_WITH_CREDIT
[    9.268915] sprdwl:ott support:0
[  264.528642] WCN_ERR: dts node for bt_wake not found
[  264.675958] Error: Driver 'sdiohal' is already registered, aborting...
[  264.682541] sdiohal err:sdio_register_driver error :-16
[  267.747899] WCN_ERR: wait SDIO rescan card time out
[  267.752832] WCN_ERR: chip power on fail
[  267.756697] sdiohal err:sdiohal_runtime_put line 1755 not have card
[  267.778947] sdiohal err:sdiohal_tx_thread line 152 not have card
[  270.819917] sprdwl:[WIFI_CMD_SYNC_VERSION]timeout
[  270.824694] sprdwl:ctx_id:0 cmd: WIFI_CMD_SYNC_VERSION[9] rsp timeout (mstime = 267775), num=1
[  270.833356] sprdwl:SYNC CMD ERROR!!
[  270.836974] sprdwl:sprdwl_tx_deinit cmd not yet transmited, cmd_send:1, cmd_poped:0
[  280.070000] sprdwl:sprdwl_msg_deinit ref not ok! wait for pop!

lsmod | grep sprdwl_ng

sprdwl_ng             344064  0
uwe5622_bsp_sdio      204800  1 sprdwl_ng
sunxi_addr             16384  1 sprdwl_ng
cfg80211              385024  1 sprdwl_ng

[PJVervoorn]

Orange PI's Bullseye 5.4 image does not have different versions for memory sizes.
http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/service-and-support/Orange-Pi-Zero-3.html
(direct link: https://drive.google.com/drive/folders/1g2o209HE9_28v7wIXdq0tf5jOTTJdpVb )
This image correctly finds 1.5GB for my board.
And, if you then run DietPi 9.0.2 installer -choosing 'Allwinner H6', not OPi Z3- you get a working (Bookworm) system...
On reboot eth comes back and 5G wifi is also working, but wifi scan fails. Manually filling slot 0 with SSID etc works fine.

I have created an image and am wondering if people with other Z3 memory sizes can boot from it: https://drive.google.com/file/d/12075O4QND1Kym6lZIQHkjrLj5BXRxokX/view
240219_ssh.txt
240219_uart.txt

[MichaIng]

We know that the 5.4 vendor kernel does not have the Ethernet issue, but it is too old to have any future. Relevant for us is the mainline-based kernel. With Linux 6.1 Orange Pi even has 3 different images.

[AlbertoTejada]

I see that the OrangePi Zero 3 image have been removed from the test images and the (test) tag have been removed from the official download image.
Does it mean that this ticket can be closed?

[deg011]

orange pi zero 3, is now moved in download version ;) Le ven. 23 févr. 2024 à 10:11, Alberto Tejada Molina < ***@***.***> a écrit :

…

I see that the OrangePi Zero 3 image have been removed from the test images and the (test) tag have been removed from the official download image. Does it mean that this ticket can be closed? — Reply to this email directly, view it on GitHub <#6594 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGIVC3GEFCFTQ5POKIOAUXLYVBML3AVCNFSM6AAAAAA4IDZNHKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRQHE3DMNJWGA> . You are receiving this because you commented.Message ID: ***@***.***>

[MichaIng]

Yes exactly. I know, especially the 1.5 GB RAM variant still has the Ethernet issue, and we left a warning at the download page about this.

Also some still report WiFi issues, @PJVervoorn at least. Still unsure about this, since I cannot replicate it. Just to rule it out, you could test our latest image, which has a little newer kernel.

However, I'll close this already too large issue now. Regarding Ethernet on 1.5G variant, I opened a new issue: #6938

If anyone faces other problems, please open a new issue.