Image | Orange Pi Zero 3

dirkhh commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

MichaIng commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

dirkhh commented 1 year ago

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 commented 1 year ago

First step done: https://github.com/MichaIng/DietPi/commit/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 commented 1 year ago

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 commented 1 year ago

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

bigross8 commented 1 year ago

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 commented 1 year ago

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

daniel-mller-87 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

When will the next Dietpi released?

Joulinar commented 1 year ago

https://github.com/MichaIng/DietPi/issues/6704

daniel-mller-87 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

reboot over ssh doesn't work: I'm receiving: Failed to connect to bus: No such file or directory only unplugging from power helps
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 commented 1 year ago

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 commented 1 year ago

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

daniel-mller-87 commented 1 year ago

I tried systemctl reboot as well. With the same issue. I'm using the 4GB RAM Version. Not shure if this makes a difference.

MichaIng commented 1 year ago

Okay, the reboot function is defined. So when using reboot, the error message does not appear, right? Same with poweroff and halt. All other commands to shutdown or reboot the system are expected to throw this (visual-only) error, unless you installed (software which requires) systemd-logind and hence dbus.

Good to know that the Ethernet issue is not individual but seems to affect all Zero 3 boards 🤔. This is something which needs to be solved most likely in the bootloader by Orange Pi. Some device state is probably not correctly reset.

bigross8 commented 1 year ago

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

Just tried it on my board, I don't see the "Failed to connect to bus" error message. Same issue with the Ethernet, fortunately the Wi-Fi works after a reboot. Are there some ethernet logs I can check?

daniel-mller-87 commented 1 year ago

Exactly, power off and halt also don't generate an error. I think the ethernet bug is the biggest issue. I'd use it as pi-hole and home assistant wifi connection isn't an option here.

bigross8 commented 1 year ago

For me, even the reboot command doesn't generate the error. But what I've noticed is that logged in as "dietpi", this error will show up for all three commands.

dietpi@DietPi:~$ reboot
Failed to connect to bus: No such file or directory
dietpi@DietPi:~$ poweroff
Failed to connect to bus: No such file or directory
dietpi@DietPi:~$ halt
Failed to connect to bus: No such file or directory

When logged in as "root", the errors don't show up.

daniel-mller-87 commented 1 year ago

same here. First time I tried as normal user with sudo.

Joulinar commented 1 year ago

you need to use them with sudo command

bigross8 commented 1 year ago

I know, my point was just to showcase that the error appears on all three commands.

MichaIng commented 1 year ago

Right, unprivileged users of course cannot just reboot or poweroff the system 😉. The dbus connection is then used for another (reasonable) purpose, to check whether policykit grants users these permissions (the same way how e.g. a non-root user can usually poweroff and reboot from the start menu of a desktop session).

poweroff, reboot and halt all behave the same in this regards: They all usually should throw the error, but thanks to the functions we defined, the underlying reason for the dbus call is bypassed. When calling them as non-root user, it throws the same error for a different reason, same as systemctl itself does.

Are there some ethernet logs I can check?

I have all logs about it here, but it is outside of my abilities to derive the underlying issue or fix it. This is something for Orange Pi kernel/bootloader developers.

bigross8 commented 1 year ago

That's unfortunate. I think there's an image with 5.4.125 kernel but I think it's too outdated to start tinkering with. Who knows, there may be a mainline kernel available by the time Orange Pi developers will fix the Ethernet issue. 😁

daniel-mller-87 commented 1 year ago

There's also an Image with Bulseye and 6.1. As long as you don't upgrade to bookworm it won't have this error. Also the Ubuntu 22.04 Image with 6.1 was working for me. However, I don't really trust their image, as there are always 3 Users running and weird high load sometimes. Waiting for some Armbian or better Dietpi Release.

MichaIng commented 1 year ago

As long as you don't upgrade to bookworm it won't have this error.

I had the same error with it, without upgrading to Bookworm. Also the userland/distribution version has no effect on such kind of kernel and/or bootloader related issues.

There is a very similar issue with the NanoPi R4S, where on reboot one of the two Ethernet adapters can disappear. But it only happens when the board has reached a certain temperature in my case. Very strange but probably some bad quality thermal-dependant resistor or weak soldering (but then on many/all boards at the very same place). Probably it is similar here, so that it does not always happen.

dirkhh commented 1 year ago

Testing the image linked above here using wifi and the ADS-B Feeder Image software. Seems solid and performs surprisingly well for such a tiny board... I'm impressed. Can't wait for this to be part of the regular releases...

daniel-mller-87 commented 1 year ago

I just tried the Ubuntu 22.04 image with 6.1 Kernel again. The ethernet bug doesn't show up here. Is it possible to take the uboot or so from here? I gues the kernel is the same as in Debian.

Though this image is working I wouldn't use it because of its changed mirrors etc. I don't know what else is running there.

This is the link: https://drive.google.com/drive/folders/1ek_VaZiNpCTq_H3T_e1AgKKWyXAxL9q1

MichaIng commented 1 year ago

I retested the original Debian Bullseye image form Orange Pi, and indeed at first the Ethernet adapter remains present after reboot. So I purged all the bloat in small chunks, including some of Orange Pi's own packages to see which one might be responsible, without finding any. Then I just enabled the Ethernet interface with a simple config:

cat << '_EOF_' > /etc/network/interfaces
iface eth0 inet static
address 192.168.1.15/24
gateway 192.168.1.1
_EOF_
ifup eth0

Internet is there, however, after reboot, the adapter is gone. Also without enabling the interface after reboot, it does not come back until a power cycle. It remains present, including after reboots, until I just enable it once again.

@daniel-mller-87 since I removed NetworkManager already, can you replicate the same on the Debian and/or Ubuntu images, that the adapter gets lost after reboot once you actually enable/use it once? It sounds suspicious that in your case it was lost after a Bookworm upgrade, which of course requires Internet as well. So probably the upgrade was not the issue, so simply that the adapter was used.

I tried to narrow it down and set the interface UP with low level tools:

ip l set up dev eth0

This enables the carrier signal, but it does not trigger the issue. I will further try to add an IP address and a default route manually and see at which point the issue appears:

🈯 ip l set up dev eth0 => no problem
🈯 ip l set up dev eth0; ip a add 192.168.1.15/24 dev eth0 => no problem
🈯 ip l set up dev eth0; ip a add 192.168.1.15/24 dev eth0; ip r add default via 192.168.1.1 dev eth0 => no problem
🈯 ip l set up dev eth0; ip a add 192.168.1.15/24 dev eth0; ip r add default via 192.168.1.1 dev eth0; apt update => Internet is there, used, but still no problem 🤔 ...
🈹 ifup eth0 (with above config) => problem ... strange, it should do the same I did ...
🈯 Comparing the routes precisely => ip l set up dev eth0; ip a add 192.168.1.15/24 dev eth0; ip r add default via 192.168.1.1 dev eth0 onlink; apt update => no problem

Does anyone have an idea what ifup with a simple static IP does on top of these commands? 🤔 The outputs of ip l, ip a and ip r are now exactly the same, but only ifup breaks the adapter on reboot.

... chrony, ethtool, wireless-tools and wpasupplicant have drop in scripts:

Purging chrony does not help ... makes sense as DietPi does not ship it either.
Purging ethtool does not help either.
Purging wireless-tools and wpasupplicant have no effect either.

daniel-mller-87 commented 1 year ago

Maybe it needs the network manager? Tell me what I should check? It's still running the ubuntu 22.04. and it survives multiple reboots. Internet as well as normal network is working. Tried a HA Docker which was working fine. However, load average is always 1.0. Maybe I should just grab one of these Intel n100 mini pcs from Ali an just install standard debian with standard kernel. Should be easy to apply dietpi script to a standard kernel etc. This thing seems to be a mess for everyone.

MichaIng commented 1 year ago

Are you using DHCP over Ethernet currently?

Maybe it needs the network manager?

More likely ifup does something which NetworkManager does not, which breaks it. It is not something missing, but something done, causing the problem.

daniel-mller-87 commented 1 year ago

Yes, I do. However, my DHCP-Server will always assign the same ip.

MichaIng commented 1 year ago

Do you have a monitor and keyboard to attach, just in case network does not come up again? If so, could you try this:

cat << '_EOF_' > /etc/network/interfaces
auto eth0
iface eth0 inet dhcp
_EOF_
systemctl disable NetworkManager
reboot

After first reboot, network should come up again, but, if the issue is the same on the Ubuntu image, after a second reboot, it won't. Btw, the kernel is the same like on the Debian version, I mean exactly the same, including build date etc?

root@orangepizero3:~# uname -a
Linux orangepizero3 6.1.31-sun50iw9 #1.0.2 SMP Mon Sep 25 13:54:37 CST 2023 aarch64 GNU/Linux

EDIT: Sorry, too much copy&paste above, just edited the /etc/network/interfaces content to actually use DHCP.

EDIT2: Okay, this is/should be what ifup does precisely:

root@orangepizero3:~# ifup -nv eth0

ifup: configuring interface eth0=eth0 (inet)
/bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
/sbin/ip addr add 192.168.1.15/255.255.255.0 broadcast 192.168.1.255      dev eth0 label eth0
/sbin/ip link set dev eth0   up
 /sbin/ip route add default via 192.168.1.1  dev eth0 onlink
/bin/run-parts --exit-on-error --verbose /etc/network/if-up.d

Repeating exactly these commands does not trigger the issue. So the output is not correct/incomplete 😞.

daniel-mller-87 commented 1 year ago

It's the same Kernel but with different date:

Linux orangepizero3 6.1.31-sun50iw9 #1.0.2 SMP Thu Sep 28 14:15:40 CST 2023 aarch64 aarch64 aarch64 GNU/Linux

I'm not shure if I understand. Should I try the first step - with network manager disabled? I have it only headless but don't mind losing the image if it breaks. I don't trust it at this stage.

MichaIng commented 1 year ago

It's the same Kernel but with different date:

Okay, I could not find any commit in Orange Pi's kernel, U-Boot or build repo, so it should all be practically the same.

I'm not shure if I understand. Should I try the first step - with network manager disabled? I have it only headless but don't mind losing the image if it breaks. I don't trust it at this stage.

Yeah right, the commands configure ifupdown and disable NetworkManager, so it should be the absolute minimum change to verify that the same happens on all Orange Pi images, and that ifupdown is the issue, btw regardless whether DHCP or a static IP is used (in my case both trigger the issue). So it seems to be some invisible pre/post step ifup does.

That's the kind of issues we love, when we have no way to find out what's going on, Orange Pi itself does not have an issue, as NetworkManager does not trigger it, and ifupdown/Debian does not have an issue, as ifup does not cause issues like that on any other hardware (and likely any other kernel build) ...

EDIT: iface eth0 inet manual does not cause the issue. In this case, the interface is set UP (carrier signal), but no IP or route is assigned. Setting it to static and adding the minimum required address as variable triggers the issue:

root@orangepizero3:~# ifup -v eth0

ifup: configuring interface eth0=eth0 (inet)
/bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
/sbin/ip addr add 192.168.1.15/255.255.255.0 broadcast 192.168.1.255      dev eth0 label eth0
/sbin/ip link set dev eth0   up

/bin/run-parts --exit-on-error --verbose /etc/network/if-up.d

Comparing kernel errors:

[    1.183095] axp20x-regulator axp20x-regulator: DCDC frequency on AXP313a is fixed to 3 MHz.
[    1.183101] axp20x-regulator axp20x-regulator: Error setting dcdc frequency: -22
[    1.291953] debugfs: Directory '1100000.mixer' with parent 'regmap' already present!
[    1.291982] debugfs: Directory '1100000.mixer' with parent 'regmap' already present!
[    1.329315] OF: /thermal-zones/gpu-thermal/cooling-maps/map0: could not get #cooling-cells for /soc/gpu@1800000
[    1.329336] thermal_sys: Add a cooling_device property with at least one device
[    1.329344] thermal thermal_zone0: binding zone gpu-thermal with cdev cpufreq-cpu0 failed:-2
[    6.082550] WCN_ERR: dts node for bt_wake not found
[    7.533037] wifi ini path = /lib/firmware/wifi_2355b001_1ant.ini
[    7.558915] sprdwl:sprdwl_get_fw_info length mismatch: len_count=83, r_len=89
[    7.558935] sprdwl:sprdwl_get_fw_info, drv_version=1, fw_version=2, compat_ver=0
[    7.558946] sprdwl:chip_model:0x2355, chip_ver:0x0
[    7.558955] sprdwl:fw_ver:0, fw_std:0x7f, fw_capa:0x120f7f
[    7.558964] sprdwl:mac_addr:24:b7:2a:46:2e:6b
[    7.558977] sprdwl:credit_capa:TX_WITH_CREDIT
[    7.558984] sprdwl:ott support:0

After ifup eth0:

[    1.182831] axp20x-regulator axp20x-regulator: DCDC frequency on AXP313a is fixed to 3 MHz.
[    1.182837] axp20x-regulator axp20x-regulator: Error setting dcdc frequency: -22
[    1.292081] debugfs: Directory '1100000.mixer' with parent 'regmap' already present!
[    1.292110] debugfs: Directory '1100000.mixer' with parent 'regmap' already present!
[    1.329357] OF: /thermal-zones/gpu-thermal/cooling-maps/map0: could not get #cooling-cells for /soc/gpu@1800000
[    1.329378] thermal_sys: Add a cooling_device property with at least one device
[    1.329385] thermal thermal_zone0: binding zone gpu-thermal with cdev cpufreq-cpu0 failed:-2
[    1.966136] dwmac-sun8i 5020000.ethernet: EMAC reset timeout
[    6.111328] WCN_ERR: dts node for bt_wake not found
[    7.529020] wifi ini path = /lib/firmware/wifi_2355b001_1ant.ini
[    7.557000] sprdwl:sprdwl_get_fw_info length mismatch: len_count=83, r_len=89
[    7.557016] sprdwl:sprdwl_get_fw_info, drv_version=1, fw_version=2, compat_ver=0
[    7.557028] sprdwl:chip_model:0x2355, chip_ver:0x0
[    7.557036] sprdwl:fw_ver:0, fw_std:0x7f, fw_capa:0x120f7f
[    7.557046] sprdwl:mac_addr:24:b7:2a:46:2e:6b
[    7.557059] sprdwl:credit_capa:TX_WITH_CREDIT
[    7.557066] sprdwl:ott support:0

=>

[    1.966136] dwmac-sun8i 5020000.ethernet: EMAC reset timeout

daniel-mller-87 commented 1 year ago

That did it. Now Ubuntu is broken the same way. I need to cold cycle to access it again. Exactly the same behaviour.

MichaIng commented 1 year ago

Okay, thanks for testing. Do this to revert to NetworkManager:

> /etc/network/interfaces
systemctl enable --now NetworkManager

daniel-mller-87 commented 1 year ago

thx. But I'll wait for the proper image now :D. Never planned on using the Chinese mirror ubuntu.

MichaIng commented 1 year ago

Never planned on using the Chinese mirror ubuntu.

You can change it in /etc/apt/sources.list. As the host key matches, you can be sure that it is an exact mirror of any other official Ubuntu APT server. However, the image composition itself with lots of bloat and stuff running + autologin on all (serial) consoles etc is not great.

I btw verified that using NetworkManager here also works fine. I'll open an issue at Orange Pi and one at the Debian bug tracker, in the hope to find out what additional thing ifup does on top of what its verbose output indicates. It looks like it is Debian themselves who manage the source code, at least I cannot find any external/upstream source for it.

jmescorcio commented 1 year ago

I have the Orange PI Zero 3 4g, but when trying to use this test image, it always hangs on this screen, regardless of whether I select YES or NO e1ed6d57-374f-45b2-99f7-4c47278895c1

daniel-mller-87 commented 1 year ago

I have the Orange PI Zero 3 4g, but when trying to use this test image, it always hangs on this screen, regardless of whether I select YES or NO

It's working with my 4G version. However, you have to use the bulseye server or the the ubuntu 22.04 server image. Didn't test the other ones. Bookworm Server never really worked even in initial state.

Best approach at the moment ist to use the Bullseye Server -> apply dietpi script (with bookworm) -> apply hack by Michaeling above -> kill all processes by user orangepi -> remove user orangepi. That leaves you with a system with average load of 0.0. But still with some bugs

MichaIng / DietPi