Orange Pi Zero 3

[dr_toggleswitch]

KICKPI K2b is working with the Armbian build for Orange Pi Zero 3  -  ethernet, wifi, sound, etc all working well. bluetooth and IR not yet tested. Simply wrote the image file to a microSD card, and everything worked as expected. :-)

 

 

[Edit:  Not sure if it's working on Orange Pi Zero 3,  but I had to disable suspend after 15 minutes in the Power settings since I wasn't able to get it to wake back up.]

 

 

I noticed the PCB looked nearly identical to the Zero 3,  though it has normal-size HDMI instead of micro-HDMI, as well as the IR module, more push buttons, and extra USB ports.

 

I used

Armbian_community_25.5.0-trunk.87_Orangepizero3_noble_current_6.6.72_gnome_desktop.img.xz

Edited February 23 by dr_toggleswitch
Added comment regarding suspend

[robertoj]

Differences:

 

20 pin IO, instead of 26 pin

Wifi chip Aw859, instead of CdTech 20U5622 (aw859 is in opi 3 LTS)

1 more built-in USB port

 

Is the wifi antenna included in the package?

Is it wifi 5 or wifi 6?

Under what kernel are they supporting video acceleration?

[Dual Stack]

My OPi Zero v3 4GB has a problem with booting. It works once out of ten attempts (same with dietpi). The official bookworm image (from orangepi site) always works correctly.

 

When it doesn't start:

 

U-Boot SPL 2024.01-armbian-2024.01-S866c-P4a40-H8869-V380a-Bb703-R448a (Feb 18 2025 - 02:39:42 +0000)
DRAM base address is defined as 0x40000000
DRAM has 16 b/raw, 11 b/col, 4 B/width, 2 #rank and 8 #bank
DRAM top address must be less than 0x200000000

 

When starts:

 

U-Boot SPL 2024.01-armbian-2024.01-S866c-P4a40-H8869-V380a-Bb703-R448a (Feb 18 2025 - 02:39:42 +0000)
DRAM base address is defined as 0x40000000
DRAM has 16 b/raw, 10 b/col, 4 B/width, 2 #rank and 8 #bank
DRAM top address must be less than 0x100000000
DRAM: 4096 MiB
Trying to boot from MMC1
NOTICE:  BL31: v2.10.2(debug):armbian
NOTICE:  BL31: Built : 02:39:29, Feb 18 2025
NOTICE:  BL31: Detected Allwinner H616 SoC (1823)
NOTICE:  BL31: Found U-Boot DTB at 0x4a0b2eb8, model: OrangePi Zero3

....

 

 

[robertoj]

Can you try other armbian images (i always use minimal), and self-built armbian image?

 

Can you change USB cable? Powering with the 0V-5V pins in the GPIO pins?

[Dual Stack]

I use this one, Armbian_community_25.5.0-trunk.87_Orangepizero3_bookworm_current_6.6.72_minimal.img.xz

Same HW components as for working Orange image - cables, sdcard, power supply. 

[Igor]

1 hour ago, Dual Stack said:

Same HW components

Majority of firmware on Armbian images are developed from scratch and around mainline sources (dietpi only download Armbian, re-brand it to dietpi and "support" - they never fixed any common issues). Alternatively we could use Allwinner stack provided by Orangepi to achieve same hardware functional level, but in that case many other things won't be working (well). Static private kernels are in very poor state and not long term solution as nobody is going to maintain them. https://docs.armbian.com/User-Guide_FAQ/#why-does-hardware-feature-xy-work-in-old-kernel-but-not-in-more-recent-one Either use Orangepi fixed kernel or support development that happens at and around projects such as Armbian. We are spiting blood to make those boards working with modern kernel, without any help of this vendor. And very little, close to none, from end users. This is the main reason why things are not at the state you expect. It's a lot of work to get those devices working well and developers are humans with their needs.

[Dual Stack]

Thank you, I understand. Unfortunately I can't help the community, I'm not a programmer, I don't understand system things in depth. I'm going with the official software.

[ag123]

@Dual Stack

I think it has to do with DRAM timings and detection and that possibly Orange Pi used different dram chips even though the board is sold as Orange Pi Zero 3

DRAM initialization is in the embedded boot loader u-boot and  the problem mainly occurs during a cold startup reboot. 

https://github.com/u-boot/u-boot/blob/master/arch/arm/mach-sunxi/dram_helpers.c#L28-L64

There used to be a '1.5 GB' problem and other associated problem detecting memory sizes, those has been resolved to some extent.

 

Among the solutions, without resorting to fixing codes:

• make sure your Wifi antenna is not lying on the board near any of the chips (cpu, dram etc), bring the antenna outside the board so that it don't lie over any electronic components. There has been reports that the Wifi interference has caused some problems with memory / cpu etc.
• as for myself, after booting successfully, I practically simply leave the board on, that is ok as I used it as a WiFi AP.
  Otherwise the 'solution' is to simply reboot taking note of the Wifi antenna issue above.

 

That said, Armbian on Orange Pi Zero 3 should be running pretty well except for some of these hiccups
https://www.armbian.com/orange-pi-zero-3/

it is one of the distributions/images that has considerable volunteered effort to make Armbian run on Orange Pi Zero 3.

you can review this long thread for the history.

 

The difference between Armbian vs the vendors images is that the vendor's images is to some extent proprietary.

While Armbian is literally / actually build from source and you can rebuilt an image if you are willing to go the distance.

https://docs.armbian.com/Developer-Guide_Build-Preparation/

It is also different in this sense in that Armbian can be updated to a recent kernel and supporting codes (e.g. u-boot) (which indeed it is) and often the kernel in the vendors images tend to be 'left behind' with an old kernel version, which may not get updated.

 

It'd be good to support the Armbian project via donations etc as this is probably about the only way to keep the project sustainable and supported. Strictly speaking, those donations are subscriptions as would be for commercial os and distributions.
---

There is an old *unsupported* image that I rebuilt from source based on 6.7 kernel back then. I won't be providing any support for this image, and it may not necessarily fix this problem and may have other issues e.g. the 1.5GB issue. But if you'd like to try it it is here:

 

-----

It is quite possible to hard code memory configuration in u-boot, but that it requires re-building an armbian image from source.
It is probably not recommended currently, but that if you are curious to look at an early fix back then about the 1.5 GB issue

a similar tactic can be used to hardcode say 4GB for your board, but requires re-building the at least u-boot and patching it into the image, or rebuilding armbian image from source. That can 'work around' those memory detection issues since all that configurations is hard coded.

 

[dr_toggleswitch]

@robertoj

 

Regarding Kickpi K2B

 

1.  Yes the wifi antenna was included in the package.

2.  I only have Wifi 5 at home.  I can't verify Wifi 6 operation. It does connect to the 5G Wifi network.

3.  Stuff like x264/x265 plays ok in mpv, but webm is unusable,  here is my uname -a.

 uname -a
Linux orangepizero3 6.6.72-current-sunxi64 #1 SMP Fri Jan 17 12:36:27 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux

 

[robertoj]

9 hours ago, dr_toggleswitch said:

3.  Stuff like x264/x265 plays ok in mpv, but webm is unusable,  here is my uname -a.

I just looked at your neofetch screenshot again... linux 6.6.72. Armbian community 25.5.0-trunk.87... I am surprised that H264 hardware acceleration is working

 

But I noticed you are running Wayland and Gnome... is that how it works from the desktop-armbian image? Or did you install it later?

 

(I hope I can start with a minimal image, and install all that's needed for wayland+labwc in my SPI LCD <- aiming for minimal ram use and lowest load time)

Edited March 10 by robertoj

[dr_toggleswitch]

@robertoj
I did not verify that it's hardware acceleration, but i assume it is because the playback quality is very acceptable.

Also, the Android OS that comes on the EMMC  could do hardware accelerated mp4 decoding.

 

Even more,   the Kickpi website provides a download link to a premade Ubuntu 24.04 image, but the performance is miserable compared to this Armbian, and it's on kernel 5.x  or something.

 

Quote

But I noticed you are running Wayland and Gnome... is that how it works from the desktop-armbian image? Or did you install it later?

 

yes,   that's all as it is from the desktop-armbian image.  Nothing installed separately besides neofetch in that photo.

 

 

this is what i used.  (well not the March 6 build, it would have been one of the Feb 2025 ones)

 

Also,  keep in mind,   i don't know it's exact power requirements -  I have an Anker 200w USB C charger with 2 USB-A slots and 4 USB-C slots.   So i power my Kickpi off one of the USB-C slots.   It is happy with that.

 

In armbian_zram_config,  I have ZRAM_PERCENTAGE=30  otherwise it could crash/power-off while compiling bigger programs.

 

I don't use the gpio or video decoding.  I just use it for internet browsing,  email,   some retro emulators

[robertoj]

Thanks!

 

Try playing a 1080p H264 video. With hardware acceleration, the CPU should be at 25% or less (check cpu % in htop)

[TRay]

Orange Pi Zero 3/2W | 1GB model sometimes detects 2GB after reboot

 

I found an interesting description of the problem that appeared on my OZPI v3 with ArmBian 25.x , especially when the program was being compiled, so the memory usage was greater and OZPI v3 would hang. When I found the following information from DietPi users, I understood where my problem was coming from time to time. Maybe the following information will be useful to someone when they have a similar problem with U-Boot, which sometimes incorrectly detects DRAM on the 1 Gb version, but users of 2Gb DRAM also reported it

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

 

[c0rnelius]

If it's detecting more or less dram than it should, its U-Boot related.

 

Depending on the version of u-boot there are two remedies as far as I know.

 

Put a delay on it; https://github.com/armbian/build/blob/main/patch/u-boot/v2024.04/board_bananapim4zero/006-mach-sunxi-dram_helpers-add-delay-to-steady-dram-detection.patch

 

For v2025.01 and above; https://lore.kernel.org/linux-sunxi/20250309063143.62859-1-jernej.skrabec@gmail.com/T/#t

 

[Igor]

1 hour ago, TRay said:

When I found the following information from DietPi users

 

It seems that this forum/project, along with similar initiatives, faces challenges in effectively addressing bugs that naturally arise in open-source software. Unfortunately, last year, one such project was even shut down due to various and constant pressures, while many open-source developers quietly walk away.

 

DietPi users are Armbian users, though most of them may not be aware of it. A more concerning issue is the way DietPi prevents its users from understanding where the actual value comes from. When users compliment their work - often based on our contributions - DietPi accepts the praise. However, when issues arise, the blame is deflected elsewhere, with responses like, "I contacted the author of the U-Boot patch," or "This is an Armbian bug," instead of acknowledging responsibility.

[TRay]

Thank you c0rnelius for your answer, maybe your suggestions are worth applying to Orange Pi Zero 3 and will help to solve the problem that does not appear permanently but only from time to time, which makes diagnosis difficult. At the moment I have used the proposed script that checks whether after a reboot the memory is not greater than 1 Gb, if so, then another reboot and I see that currently I no longer have problems with the system stopping during program compilation, and sometimes it happened during system updates. The solution based on the script is not an elegant solution, but it helps until corrections appear for Orange Pi Zero 3

[TRay]

I have just managed to illustrate this phenomenon with screenshots

 

 

 

 

Edited March 15 by TRay

[TRay]

Now after next reboot looks all OK size memory

 

 

[TRay]

If it happens that the system starts with an incorrect amount of physical memory, as a result of processes such as compilation or even system update (which I experienced a few times) that want to use memory that is not physically available, the system hangs during compilation or system update.

[going]

17 минут назад, TRay сказал:

Now after next reboot looks all OK size memory

Please post the name of the memory chip.
Literally what it says on it.

 

This issue has already been raised here on the forum.
Two different users had different chips soldered on the same boards.
 Memory chips from different manufacturers.
In one case, the memory was defined as 2GB, in the other as 1GB.

[TRay]

Unfortunately I can't read it because I have special tapes on the CPU and memory to transfer the temperature to the mounted radiator I won't rip these tapes off because I don't have spare ones On the second OZPI v3 which has the same phenomenon, the system has the following written on it: SEC 913 K4F8E30 4HBMGCJ

[TRay]

I don't really understand, if there is some memory mounted on the board, why the system recognizes it once as 1 Gb and the next time the reboot recognizes it as 2 Gb???

[TRay]

I bought OZPI 3 in the 1 GB RAM version and when the system recognizes it as 2 GB I have problems with compilation system update because system want to use the memory range that does not exist physically when the system recognizes it as 1 GB everything works smoothly compilation and system update does not cause the system to hang But I am not an expert in this matter, I just write what I observe

Edited March 15 by TRay

[TRay]

my case is exactly similar to the one I found in the description by providing a link in my post

 

 

[Nick A]

Maybe these two parches will fix the issue .

https://github.com/warpme/minimyth2/commit/962ac7da6cb84d0e41826c5555cb101b70a53a8d
https://github.com/warpme/minimyth2/commit/2e267842b1033bbc4c2c5d80c1756a142e347cc5

More information can be found here 

https://oftc.irclog.whitequark.org/linux-sunxi/2025-03-03#34058621

[TRay]

Hi Nick A

 

Thank you for links and looks like in post from c0rnelius above

 

For v2025.01 and above; https://lore.kernel.org/linux-sunxi/20250309063143.62859-1-jernej.skrabec@gmail.com/T/#t

 

Jernej Skrabiec send patch so we need to wait for update for U-boot / kernel for OZPI v3 in ArmBian distribution ? maybe this will solve the problem

Currently OZPIv3 has kernel 6.6.75 available but I don't know what the U-Boot version is, probably I can see it via serial port

 

[TRay]

I found information on my OZPIv3 with Armbian 25.5 (which updated) in the directory /usr/lib/linux-u-boot-current-orangepizero3

 

declare UBOOT_BIN_DIR="/usr/lib/linux-u-boot-current-orangepizero3"
declare UBOOT_VERSION="2024.01"
declare UBOOT_ARTIFACT_VERSION="2024.01-S866c-P4a40-H8869-V380a-Bb703-R448a"
declare UBOOT_GIT_REVISION="866ca972d6c3cabeaf6dbac431e8e08bb30b3c8e"
declare UBOOT_GIT_SOURCE="https://github.com/u-boot/u-boot"
declare UBOOT_GIT_BRANCH="tag:v2024.01"
declare UBOOT_GIT_PATCHDIR="u-boot-sunxi"

[going]

15 часов назад, TRay сказал:

On the second OZPI v3 which has the same phenomenon, the system has the following written on it: SEC 913 K4F8E30 4HBMGCJ

Printed on the chip itself:

SEC 913

K4F8E30

4HBMGCJ

Now we know about this chip.

There is a similar discussion here

25244-ram-problem/#findComment-160334

 

Unfortunately, Armbian will not be able to support all the variety of chips.

Only the user can independently add changes for their device and test them.

 

If you want to build the u-boot package yourself, then

Configuration for your device:

config/boards/orangepizero3.csc

Similarly, add the following lines to your configuration file

config/boards/orangepizero2w.csc#L5-L8

Place the required set of patches in the appropriate folder.

 

[TRay]

Thank you for your answer but I am a regular user of the ArmBian system on Orange Pi Zero 3 and I do not have such a large experience in such areas as recompiling U-Boot patch applications. I can only wait patiently that maybe in a stable version, it will be "fixed" and until then I will use the script provided by DietPi users

[ag123]

cross posting this thread, as this seemed to be a related 'bleeding edge' thread

one can probably ignore the 'don't use' remarks as apparently, efforts are underway to make the recent kernel work (on zero3, zero2w)