Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Image | Orange Pi Zero 3 #6594

Closed
dirkhh opened this issue Sep 1, 2023 · 198 comments
Closed

Image | Orange Pi Zero 3 #6594

dirkhh opened this issue Sep 1, 2023 · 198 comments

Comments

@dirkhh
Copy link
Contributor

dirkhh commented Sep 1, 2023

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
Copy link
Contributor Author

dirkhh commented Sep 27, 2023

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 MichaIng added this to the v8.23 milestone Sep 27, 2023
@MichaIng MichaIng changed the title please add support for the Orange Pi Zero 3 Image | Orange Pi Zero 3 Sep 27, 2023
@MichaIng
Copy link
Owner

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

@MichaIng
Copy link
Owner

MichaIng commented Sep 27, 2023

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:

@dirkhh
Copy link
Contributor Author

dirkhh commented Sep 27, 2023

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
Copy link
Owner

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
Copy link

bigross8 commented Oct 20, 2023

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
Copy link

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

@dirkhh
Copy link
Contributor Author

dirkhh commented Oct 21, 2023

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
Copy link
Owner

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.

@MichaIng MichaIng modified the milestones: v8.23, v8.24 Oct 21, 2023
@daniel-mller-87
Copy link

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
Copy link

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

@bigross8
Copy link

bigross8 commented Nov 1, 2023

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
Copy link
Owner

MichaIng commented Nov 1, 2023

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

@daniel-mller-87
Copy link

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
Copy link

bigross8 commented Nov 3, 2023

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
Copy link

When will the next Dietpi released?

@Joulinar
Copy link
Collaborator

Joulinar commented Nov 8, 2023

#6704

@daniel-mller-87
Copy link

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
Copy link
Owner

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
Copy link
Owner

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
Copy link

daniel-mller-87 commented Nov 10, 2023

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
Copy link
Owner

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
Copy link

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

@StaticReverb
Copy link

StaticReverb commented Jan 27, 2024

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
Copy link
Contributor Author

dirkhh commented Jan 27, 2024

@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
Copy link
Collaborator

Do you have a serial adapter?

@MichaIng
Copy link
Owner

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
Copy link
Contributor Author

dirkhh commented Jan 27, 2024

Do you have a serial adapter?

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

@MichaIng
Copy link
Owner

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
Copy link
Contributor Author

dirkhh commented Jan 27, 2024

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
Copy link

StaticReverb commented Jan 27, 2024

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
Copy link
Owner

MichaIng commented Jan 27, 2024

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
Copy link

johndo100 commented Jan 28, 2024

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

image

opi-zero3-dietpi.log

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

@deg011
Copy link

deg011 commented Jan 29, 2024

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

@PJVervoorn
Copy link

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
Copy link

bigross8 commented Jan 31, 2024

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
Copy link
Collaborator

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

@bigross8
Copy link

bigross8 commented Jan 31, 2024

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
Copy link
Owner

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
Copy link

...
@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
Copy link

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
Copy link

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
Copy link
Owner

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
Copy link

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
Copy link

deg011 commented Feb 23, 2024 via email

@MichaIng
Copy link
Owner

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.

@tmoore22
Copy link

For everyone that comes looking for answers to OrangePI Zero3 issues (and for my future reference), following a couple of weeks playing around.. I concluded:

  1. the Ethernet issue is solved by using the OrangePI uBoot (v2024.01-orangepi) - it loads (and reset the Ethernet adapter every boot which makes it work fine when the Kernel loads the driver)
  2. the 1.5G patch is rubbish, on my 4G Zero3 this causes 2/3 boots to fail because the RAM calculation gets spurious results and is inconsistent. uBoot will hang (can be seen over UART console) also can be seen because uBoot does not light the red LED. Fix here: Invalid DRAM detection [pi zero 3] orangepi-xunlong/u-boot-orangepi#19 (comment)
    So for 1.5G users, suggest using a hard-coded RAM value... do some research there are examples.

@MichaIng
Copy link
Owner

@tmoore22 can you be a bit more precise about the issues you face, and in case provide serial console logs?

  1. The Ethernet issue is long solved, as both variants use the same bootloader now. The issue did only exist with the old Orange Pi bootloader, which we needed to use until the 1.5 GB RAM detection was added to the newer Armbian-based bootloader build.
  2. Which instability do you face? The linked issue is about the Orange Pi bootloader, which you can also see from the logs of the user. So the patch you linked is not applied at this user's bootloader. I am running the Armbian-based (=our) on a 2 GB and a 1.5 GB variant of that board perfectly fine. The only issue I am aware of is that for some, the 1 GB variant sometimes detects 2 GB for unknown reasons. The 1.5 GB patch is however entirely unrelated to this, the false detection happens before any of the patched code even runs.

So whichever issue you face on your 4 GB variant, please open a new issue about this, and detail the issues you face, and serial console logs, at best.

@tmoore22
Copy link

tmoore22 commented Nov 29, 2024

Hi @MichaIng,
4GB version of OrangePI Zero3
I have just downloaded the latest Armbian and installed to a SD card.. after the second reboot... I got this and a hang:
image

after a power cycle, good boot looks like this:

image

@MichaIng
Copy link
Owner

MichaIng commented Nov 30, 2024

@tmoore22
So you are facing the very same issue reported here: #7242
Only difference is that in your case, not the bita per row but bits per column are evaluated one byte too high, randomly.

Very weird, as the math is correct and also the method should be failsafe. Even if e.g. there was a race condition with something else writing to the start of the RAM during the check, it should not stop exactly one byte higher, but at the end of the range of checked values.

However, it is unrelated to the 1.5G patch, which runs after these false values have been derived already. Other than that, the patch adds this output about the RAM size/parameters, else one wouldn't even recognise what's going wrong.

I'll compare with my 2G and 1.5G models, to see whether any inconsistency appears there as well, and add some more debug output. Maybe we can narrow it down. I also mailed the author of the 1.5G patch already whether he observed something similar and/or has an idea how it is even possible (as of the method which looks solid), but no direct result.

Let's discuss further in the linked issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests