Jump to content

Orange Pi Zero 3


Recommended Posts

some news related to Orange Pi Zero 3




 [PATCH 0/3] sunxi: Orange Pi Zero 3 DT support
@ 2023-07-31  1:17 Andre Przywara
  2023-07-31  1:17 ` [PATCH 1/3] arm64: dts: allwinner: h616: Split Orange Pi Zero 2 DT Andre Przywara
                   ` (3 more replies)
  0 siblings, 4 replies; 8+ messages in thread
From: Andre Przywara @ 2023-07-31  1:17 UTC (permalink / raw)
  To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
	Jernej Skrabec, Samuel Holland
  Cc: Icenowy Zheng, devicetree, linux-arm-kernel, linux-sunxi, linux-kernel


Orange Pi recently released the Orange Pi Zero 3 board, which is some
updated version of their former Zero 2 development board. Some component
changes (Motorcomm PHY instead of Realtek, different PMIC), some board
layout changes, and it ships with up to 4GB of DRAM now. The SoC is now
labelled H618 instead of H616, which apparently is the same, just with
more L2 cache.

Split the existing OPi Zero2 DT, to allow sharing most DT nodes, then
add the binding documentation and DT for the new board.

Linux v6.5-rc boots out of the box (the PMIC driver just made it in),
and most things work: UART, PSCI, GPIO, SPI flash, SD card, USB.
Ethernet is almost working, I get an IP address via DHCP, but no further
packets come through. Might be either a problem with the new Motorcomm
PHY driver, or some missing delay settings, I have to investigate, any
help or advice welcome.
Also let me know if the DT split is a good idea or not, happy to roll
that back if requested.


Andre Przywara (3):
  arm64: dts: allwinner: h616: Split Orange Pi Zero 2 DT
  dt-bindings: arm: sunxi: document Orange Pi Zero 3 board name
  arm64: dts: allwinner: h616: Add OrangePi Zero 3 board support

 .../devicetree/bindings/arm/sunxi.yaml        |   5 +
 arch/arm64/boot/dts/allwinner/Makefile        |   1 +
 .../allwinner/sun50i-h616-orangepi-zero2.dts  | 119 +---------------
 .../allwinner/sun50i-h616-orangepi-zerox.dtsi | 131 ++++++++++++++++++
 .../allwinner/sun50i-h618-orangepi-zero3.dts  |  86 ++++++++++++
 5 files changed, 224 insertions(+), 118 deletions(-)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zerox.dtsi
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero3.dts


linux-arm-kernel mailing list

^ permalink raw reply	[flat|nested] 8+ messages in thread
* [PATCH 1/3] arm64: dts: allwinner: h616: Split Orange Pi Zero 2 DT
  2023-07-31  1:17 [PATCH 0/3] sunxi: Orange Pi Zero 3 DT support Andre Przywara
@ 2023-07-31  1:17 ` Andre Przywara
  2023-08-03 21:05   ` Jernej Škrabec
  2023-07-31  1:17 ` [PATCH 2/3] dt-bindings: arm: sunxi: document Orange Pi Zero 3 board name Andre Przywara
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 8+ messages in thread
From: Andre Przywara @ 2023-07-31  1:17 UTC (permalink / raw)
  To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
	Jernej Skrabec, Samuel Holland
  Cc: Icenowy Zheng, devicetree, linux-arm-kernel, linux-sunxi, linux-kernel

The Orange Pi Zero 2 got a successor (Zero 3), which shares quite some
DT nodes with the Zero 2, but comes with a different PMIC.

Move the common parts (except the PMIC) into a new shared file, and
include that from the existing board .dts file.

No functional change, the generated DTB is the same, except some phandle
numbering differences.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
 .../allwinner/sun50i-h616-orangepi-zero2.dts  | 119 +---------------
 .../allwinner/sun50i-h616-orangepi-zerox.dtsi | 131 ++++++++++++++++++
 2 files changed, 132 insertions(+), 118 deletions(-)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zerox.dtsi

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
index cb8600d0ea1ef..c786b170fb9a8 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
@@ -5,95 +5,19 @@
-#include "sun50i-h616.dtsi"
-#include <dt-bindings/gpio/gpio.h>
-#include <dt-bindings/interrupt-controller/arm-gic.h>
-#include <dt-bindings/leds/common.h>


Link to comment
Share on other sites

some news related to Orange Pi Zero 3





sunxi: H616: add LPDDR4 DRAM support

The H616 SoC family has support for several types of DRAM: DDR3, LPDDR3, DDR4 and LPDDR4. At the moment, the driver only supports DDR3 and LPDDR3 memory. Let's extend the driver to support the LPDDR4 memory. This type of memory widely used in device with T507(-H) SoC and new orangepi zero3 with H618. The compatibility with T507 is not yet complete, because there is difference in the phy_init array. The LPDDR4-2133 timings correspond to DRAM Rayson RS1G32LO4D2BDS-53BT found on the NOR SPI from the Orangepi Zero 3 4GB. Signed-off-by: Mikhail Kalashnikov <iuncuim@gmail.com> Tested-by: Piotr Oniszczuk <piotr.oniszczuk@gmail.com> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by: Andre Przywara <andre.przywara@arm.com>




power: regulator: add AXP313 support

The X-Powers AXP313a is a small PMIC with just three buck converters and three LDOs, one of which is actually fixed (so not modelled here). Add the compatible string and the respective regulator ranges to allow drivers to adjust voltages. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>


er-em, this is at the .. far bleeding edge

i.e. uboot source


and like between 1 week to 1 month ago

Edited by ag123
Link to comment
Share on other sites

some 'old' discussions across from linux sun-xi mailing list



Andre Przywara

Aug 1, 2023, 9:37:20 PM

to andrew g, linux-sunxi


Hi Andrew,

On 11/07/2023 19:29, andrew g wrote:
> Has anyone ordered and/or played with this

> https://www.cnx-software.com/2023/07/03/orange-pi-zero-3-allwinner-h618-sbc-ships-with-up-to-4gb-ram/ <https://www.cnx-software.com/2023/07/03/orange-pi-zero-3-allwinner-h618-sbc-ships-with-up-to-4gb-ram/>

Please look here:
and here:

In short, it boots existing mainline Linux v6.5-rc1, given the right DTB,
which is in the patch series above. U-Boot support is work in progress.
For now you could use the firmware binary from one of the official images,
that's actually not too bad (because based on just two year old
mainline, and without too many custom hacks, it seems).

> https://liliputing.com/orange-pi-zero-3-is-a-cheap-tiny-single-board-pc-with-up-to-4gb-ram-gigabit-ethernet-and-allwinner-h618/ <https://liliputing.com/orange-pi-zero-3-is-a-cheap-tiny-single-board-pc-with-up-to-4gb-ram-gigabit-ethernet-and-allwinner-h618/>
> http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-Zero-3.html <http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-Zero-3.html>

> even the linux images is very 'fresh' as in that they are just released

> *yesterday* 😄[Click and drag to move]

"Freshly built" doesn't mean it's fresh software. On the SPI flash I
found some kernel 4.9.170 (4.9 is out of LTS support for a while now),
compiled with GCC 5.3 in a 2016 build.

In general I would disregard any official software offering, and just
focus on fixing problems in mainline, and supporting more hardware.
For instance graphics support is missing from H616, even though patches
for the display engine, HDMI, and the GPU are floating around. Same goes
for DVFS, so defining voltage/frequency pairs for the CPU.



Link to comment
Share on other sites


Feature Orange Pi Zero2 Orange Pi Zero3
SoC H616 H618
DRAM sizes 512MB/1GB 1/1.5/2/4 GB
SPI flash size 2MB 16MB
Ethernet PHY RTL8211F YT8531C




Dual-band WiFi 5 and Bluetooth 5.0 (CdTech 20U5622 module) with external antenna

Edited by ag123
Link to comment
Share on other sites

it seemed during the 6.6 kernel build - UWE5622 driver is inlined in the 6.6.2 kernel, but that this is just the 'armbian' kernel, I'm not sure if it is there in mainline.





^ well, didn't seem so, mainline didn't seem to explicitly list that



Can't find the part number YT8531C, but that there is a tag for Allwinner devices, I'm not sure if that is included



Edited by ag123
Link to comment
Share on other sites

@Gunjan Gupta

Thanks, I'd try that out.



some news from the 'bleeding edge'


arm64: dts: allwinner: h616: add Orange Pi Zero 2W supportsunxi/dt-for-6.8
The Orange Pi Zero 2W is a board based on the Allwinner H618 SoC.
It uses the RaspberryPi Zero form factor, with an optional expansion
board, connected via an FPC connector, to provide more connectors.

The base board features:
	- Allwinner H618 SoC (quad Cortex-A53 cores, with 1MB L2 cache)
	- 1, 2 or 4GB of LPDDR4 DRAM
	- SD card socket
	- two USB-C sockets, one UFP, one DFP
	- HDMI connector
	- (yet unsupported) WiFi module
	- 16 MiB SPI flash
	- power supply via the UFP USB-C port

The FPC connector provides access to two more USB host ports, Fast
Ethernet, some GPIOs, Audio Line out and the IR receiver pin.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://lore.kernel.org/r/20231020145706.705420-3-andre.przywara@arm.com
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>


It seemed quite a lot of things are happening for h616, h618 (e.g. Orange Pi Zero 3, Zero 2W etc) at the mainline 6.6 kernel versions and beyond. But as seen in the various dts trees at the 'bleeding edge'


UWE5622 Wifi isn't there in mainline. Hence, for UWE5622 Wifi drivers. 
it is from Armbian.

a few other places where the UWE5622 driver codes are found seemed to be from orange-pi 6.1 kernel branch


bigtreetech cb1


it seemed the souce tree for all 3 sets of UWE5622 codes Armbian, OrangePi (2 branches 6.1 and 6.6), and Bigtreetech CB1 are after all 'similar'.

But that there are various differences in some files, some updates are apparently possibly bug fixes.

e.g. some of the commit logs here





It'd be good to 'keep an eye' on fixes that goes into either one as there has been some reported issues for uwe5622, I've personally encountered some of that as I'm trying to setup a wireless hotspot with that.

For now, the above are just 'for information', nice to know. And I think I should just try to make an image and try it out

-- off-topic:
I ran into some issues making an image, but it has nothing to do with the Armbian build process, It is simply because I'm running the build from within a systemd-nspwan container.

systemd-nspawn do not support loop devices, which is a bummer to make images from within the container.

Hence, I'd need to figure out how to make the images manually separately, but that that is still significant as compiling the kernel and building the raw image file (including all that apt-get pulls) is successful in the systemd-nspawn container 


Edited by ag123
Link to comment
Share on other sites

agree with @Igor, supporting a board is a long term commitment and no easy feat.

those who are reading this thread should take it that there is no official Armbian release for this board (yet).

These are 'community efforts', attempts to run it on Orange Pi Zero 3.


But I'm hoping that we can build up enough *community* support and involvement for Orange Pi Zero 3 here.

Note that for a supported board, it would call on the community for continuous maintenance and integration,  as well as being involved in doing tests when new releases are made. Armbian isn't just supporting one single board after all.

It'd also means that the community would need to support this effort financially as well, i.e. supporting Armbian.



Board testing (Orange Pi Zero3) and many issues:


For the record, I've tried using the board with the vendor's Debian (bookworm) images (it is an early image released in August 2023, there is a more recently release in Oct 2023).


The scenario tested is setting up this Orange Pi Zero 3 as a Wifi hotspot.


The distribution is running hostapd and for the record I managed to set up a 5Ghz 802.11ac hotspot on this little board. It clocked like in excess of 100 Mbps (100 mega bits per second) through the WiFI UWE5622 and the (gigabit) Ethernet interface. it is quite an 'eyebrow raiser' (wow).


The trouble is there apparently (it seems) is some real hardware bugs/defects in the gigabit Ethernet chip, within less than a day the ethernet hardware stall on me, ethernet connection goes offline. And Network manager disabled the ethernet interface.

I've had to manually re-enable that from network manager, and not just that, power cycle the board completely off, disconnect and re-connect ethernet cable in an attempt to restore it. It has become frustrating as this is becoming frequent, like less than an hour.



For those curious or is trying to reproduce the hostapd WiFi AP on Orange Pi Zero 3, the hostapd.conf is like such





a session form a DietPi test distribution seemed to show the same hardware issue with the ethernet chip. 



just 2 cents: Orange Pi Zero 3 is still a 'significant' board, due to an updated Cortex A53 from Allwinnner H616 to H618, accordingly things are similar except that OrangePi Zero 3 is using LPDDR4 while OrangePi Zero 2 is using DDR3, and a different PMIC 

OrangePi Zero 3 supports up to 4GB memory (important for various apps), the performant gigabit ethernet and 5Ghz 802.11ac capable Wifi is a big plus. It makes this board perfect for a WiFi hotspot, pretty sure open source router distributions like OpenWrt would have noticed it. The trouble is I'm not sure if the ethernet chip (hardware) defect is after all true, that is a real bummer.

Edited by ag123
Link to comment
Share on other sites

@Shivan SpS

yes there are problems with the UWE5622, various errors in dmesg.


But for that matter, in my current tests, UWE5622 wifi has worked fairly ok



In fact, running UWE5622 with the on board gigabit ethernet phy YT8531, I've achieved in excess of 100 Mbps (100 mega bits per seconds) throughput on this board. it is an eyebrow raiser (wow).

this is done by running hostapd as a wifi hotspot. In the tests, i've transferred > 1 GB (1 gigabyte) across the wifi hotspot running on OrangePi Zero 3 from a phone running android apps update, and the link stays up after that.

Unfortunately, the ethernet phy YT8531 is not stable (at 1 gbps). it (ethernet, not wifi) drops the link on reboot (not always though) and drops the link after some time even if it is idle.


The tests are in the link above but in DietPi though. I'm currently repeating the same wifi hotspot tests but setting the ethernet link at 100 Mbps.

I'm hoping to achieve a stable ethernet link.


For a wifi hotspot, ether of the link (wifi or ethernet) breaks is a bummer, it defeats its purpose as a wifi hotspot. A wifi hotspot is probably a best connectivity tests for this board.

This is a good board if the gigabit ethernet interface is stable.


Edited by ag123
Link to comment
Share on other sites

Yeah thats exactly what i was thinking, using a Zero 3 as a Access Point, or even a router... i will to see the wireguard bandwidth. Too bad they didnt wired the built-on 100mbits NIC to the pins.


For now, im playing with a Orange PI Zero 2W i couldt not boot armbian yet. I wanted to use a wavewhare 3.5" SPI display on it, that i have no idea of how to make it work. The 2W is it mostly compatible with RPI GPIO, SPI pins are all on the same place, even the SPI CS.

Link to comment
Share on other sites

I did one thing, changed the ethernet cable. Maybe I should have done that earlier 

now it looks different:
I’ve just completed an Android apps update, Orange Pi Zero 3 is my Wifi hotspot, Orange Pi’s official ubuntu images released in Oct 23:

orangepi@orangepizero3:~$ vnstat
                      rx      /      tx      /     total
         today    413.90 MiB  /    5.22 MiB  /  419.12 MiB
         today      4.24 MiB  /  417.69 MiB  /  421.93 MiB

But that I only managed to configure a 2.4Ghz 802.11g wifi hotspot in the official images with hostapd. that is 40 Mbps. Throughput is decent, though i’m running at 100 Mbps at the ethernet end.


1 link drop, recovers on its own - it’s a new cable ! uptime 1 hour


After replacing the cable with a new cable, link has been up 20 hours without ethernet completely freezing out, I'm still able to connect to the hotspot and use it normally after 20 hours.

The above confirms that my ethernet woes are simply due to ethernet cable defect and not onboard hardware nor software.

I’ve previously manually set the Ethernet to run at 100 Mbps via ethtool -s eth0 speed 100 , but that it is unknown why it sticks to 100 Mbps even across reboots.

But for now I don’t think this is a defect, e.g. it could be due to my up stream hub etc.


Hope that this paves the way towards eventually being supported in Armbian as well.




Edited by ag123
Link to comment
Share on other sites

Thanks for all your updates to date @ag123 (and others in the thread), I have several Orange Pi boards including the Zero 3, and have been following your updates on upstream progress here.

I will check out the DietPi images you have linked and see how they go. Thanks again for all the information you have collated here.

Edited by pixdrift
Link to comment
Share on other sites

agree with @Igor, supporting a board is a long term commitment and no easy feat.

Those who are reading this thread should take it that there is no official Armbian release (not even 'community' nor 'unsupported')  for this board (yet).
The images tested prior to these comment includes:

  • vendor's images
  • some images created by 3rd parties (possibly including Armbian derivative)

These are 'community efforts', attempts to run it on Orange Pi Zero 3 and is purely 'experimental'.


But I'm hoping that we can build up enough *community* support and involvement for Orange Pi Zero 3 here.

Note that for a supported board, it would call on the community for continuous maintenance and integration,  as well as being involved in doing tests when new releases are made. Armbian isn't just supporting one single board after all.

It'd also means that the community would need to support this effort financially as well, i.e. supporting Armbian.


I've been (*messing*) experimenting with this board and I learned something, while one is messing with 'experimental' software, and 'experimental' boards e.g. this board.

It is easy to think of it as a software problem. After all the experiments, it turns out some of my network woes I encountered are simply due to a defective network cable.

But that said, there are 3rd party images or some such images there are broken in the software.

issues with other (e.g. network) hardware are after all quite common e.g. in this case a problem with network hub, and in my case a defective network cable


i.e. there are so many blind spots when something doesn't work, and your hardware (including like cables, other hardware etc) should be in the checklist for troubleshooting.


Edited by ag123
Link to comment
Share on other sites

After reading this thread I spent some time trying to understand what would be required to get this board officially into Armbian (there is lots to read). I am very new to this project, but have been attempting to collate the information available and find out where the current gaps are.


To that end, I had a look at the Orange Pi SDK which appears to be the source of the majority of the not-actually-armbian images mentioned and linked here, and the SDK itself is extensively documented by Orange Pi.

This SDK uses what seems to be a heavily modified version of the armbian build tool/scripts. It successfully builds a u-boot image, and has a dtc/defconfig onfiguration in an Orange Pi hosted u-boot repo. Unfortunately the u-boot version they are using is fairly dated.. so my approach was:

1. Determine if configuration would work with u-boot mainline (rather than the Orange Pi repo)
2. Remove any other Orange Pi repo specific requirements in preference for upstream tools (compilers/tools)
3. Try and unpick the required elements from the build scripts and see if I can get them working with Armbian (a little bit off this step yet, but consider this aspirational)


So with item 1. I moved the Orange Pi defconfig into the mainline repo and modified the Orange Pi SDK to build off mainline. After working through a few issues I determined that the configuration for the H616 board had changed (new options) that weren't in the old Orange Pi version of the repo, I made an issue here with some of the specifics (although this may not have been the correct place to raise it):

Note: Looking at the differences to what has been contributed below to the sunxi repo, and the information I was seeking. in the above thread. I think I was still miles off getting it working with my trial/error :)

I also noticed in the mainline version of u-boot that the Orange Pi Zero 2 board configuration had been updated with these additional options, so I contacted the contributor that made the changes for the Pi Zero 2 in an attempt to find out how to get this information (I won't mention their name here to avoid them getting sent questions, but I am extremely grateful).  They very gracefully provided advice on the where to find this information for sunxi boards:

IRC: OFTC, #linux-sunxi)
Mailing List: linux-sunxi@lists.linux.dev

In a somewhat coincidental turn of events, they also advised that a patch had just been submitted to the mailing list to add mainline u-boot support for the Orange Pi Zero 3.

The defconfig is here (line from the above email), but please check the entire patch as several other files are also updated:

So with that in mind, my next step is to try using the Orange Pi SDK + u-boot mainline repository with the Orange Pi Zero 3 patch applied.

One thing I have learnt starting this process is that there are many extremely talented individuals contributing every step of the way, and it's humbling to look through their code and contributions and see just how much work is involved!



Good news, Orange Pi SDK + mainline u-boot with patch worked and built uboot + spl image cleanly (although haven't had a chance to test it yet).

Edited by pixdrift
Link to comment
Share on other sites


I'm thinking we'd need to try to start from the mainline u-boot


as there are some changes as related Orange Pi Zero 3 H618


And as well with 6.6 mainline kernels and upwards.

if you noted Andre Przywara's (likely from arm.com ! He has been pretty active in Linux sunxi https://linux-sunxi.org/H618 https://linux-sunxi.org/Xunlong_Orange_Pi_Zero3which is an independent effort by open sourced developers separate from Orange Pi I think)  commit in the *mainline kernels 6.6* about the Orange Pi Zero 3.

i think that it is 'independent' as if you look carefully this git is the 'upstream', 'bleeding edge' of developments on linux-sunxi


those changes developed in this repository, eventually get merged back into


the 'enterprise' of which the whole universe of Linux (imagine the millions  of cloud containers, linux distributions, (debian, ubuntu, redhat (ibm), opensuse, Intel, AMD, Micsosoft, Nvidia, Arm, RISC-V etc and users running it) runs on ;) 


I'm learning the ropes on building Armbian


And I think this is a good starting point. The main point is to start with the 'edge' i.e. 6.6 and above kernels build which is supported by the Armbian build process (you can choose 'edge' kernel during the interactive setup for the build which is the 6.6 kernel (currently)).

In that way, we can have a look at where are the gaps between mainline kernels and mainline u-boot vs getting it to run on Orange Pi Zero 3 H618.

I'm of an opinion that if those commits in mainline are after all for Orange Pi Zero 3 H618, it probably means that someone has succeeded running it (the mainline kernel) on Orange Pi Zero 3.

if you read this, the instructions are *very precise*, it practically means if you try that, you get Linux running on Orange Pi Zero 3.


edit more news:



From: Andre Przywara <andre.przywara@arm.com>
To: Jagan Teki <jagan@amarulasolutions.com>
Cc: Vignesh R <vigneshr@ti.com>,
    Jaehoon Chung <jh80.chung@samsung.com>,
    Jernej Skrabec <jernej.skrabec@gmail.com>,
    Mikhail Kalashnikov <iuncuim@gmail.com>,
    Piotr Oniszczuk <piotr.oniszczuk@gmail.com>,
    u-boot@lists.denx.de, linux-sunxi@lists.linux.dev
Subject: [PATCH 0/3] sunxi: add OrangePi Zero 3 board support
Date: Tue, 14 Nov 2023 01:31:03 +0000    [thread overview]
Message-ID: <20231114013106.31336-1-andre.przywara@arm.com> (raw)

The OrangePi Zero 3 is a small development board featuring the Allwinner
H618 SoC. Compared to its predecessor OrangePi Zero 2, the new board uses
LPDDR4 DRAM instead of DDR3 DRAM, and an X-Powers AXP313 PMIC instead of
the AXP305.
U-Boot gained support for both LPDDR4 DRAM and the new PMIC just
recently, so add a user for those features by adding a defconfig for the
new board.
To make this work, patch 1/3 introduces support for zBIT SPI NOR flash
chip, and patch 2/3 removes the default AXP305 PMIC selection when
compiling for H616 SoCs.
Patch 3/3 then adds the defconfig. The DT was already synced from the
Linux kernel repo a few weeks ago.


Andre Przywara (3):
  mtd: spi-nor: Add support for zBIT ZB25VQ128
  sunxi: H616: remove default AXP305 selection
  sunxi: H616: Add OrangePi Zero 3 board support

 arch/arm/dts/Makefile            |  1 +
 board/sunxi/MAINTAINERS          |  5 +++++
 configs/orangepi_zero2_defconfig |  1 +
 configs/orangepi_zero3_defconfig | 30 ++++++++++++++++++++++++++++++
 configs/x96_mate_defconfig       |  1 +
 drivers/mtd/spi/Kconfig          |  5 +++++
 drivers/mtd/spi/spi-nor-ids.c    |  5 +++++
 drivers/power/Kconfig            |  1 -
 8 files changed, 48 insertions(+), 1 deletion(-)
 create mode 100644 configs/orangepi_zero3_defconfig


(this is getting exciting, if you want to know what wizards@work practically means review that thread in the link, patching up usb, fixing up memory dram issues, clocking up dram speeds, hacking spi flash,  putting uboot in SPI flash ! who needs bios these days (this is the *ultimate*, start from the beginning cpu cold start run 1st instruction and it is uboot ! :) )


Hence, this is a good starting point.

But that as noted by Andre Przywara, the UWE5622 Wifi driver isn't yet in mainline, we'd probably graft that in back from Armbian which already has the codes.


While building Armbian from the sources, start by selecting and building for Orange Pi Zero 2 H616 board and with 'edge' 6.6 kernels. This is the best base as H618 is an improved H616 but that on Orange Pi Zero 3, it uses LPDDR4 ram and has a different PMIC as noted in the above 2 references.


This line of thought is 'rather important' as starting from mainline and integrating mainline is much more sustainable in the long run. Because after successful integration, and possibly tipping off linux-sunxi about these efforts, they could probably merge more codes into mainline and who knows Orange Pi Zero 3 may be 'supported' in mainline without needing to graft patches.

And we may reach a point 'supporting' the board is basically setting up a 'config' file for the build and it 'just works' with mainline codes. 



Link to comment
Share on other sites

this is an 'off-topic' and an interesting blurb:

for *ancient* people who understands what is BASIC (programming language) and PEEK and POKE



it is given a modern twist, in a modern times in our modern Arm 32 / 64 bits SBC landscape, with gigabytes of memory, in full blown *Linux*, on the *shell* :


peekpoke is a Linux command line tool to read from and write to system memory. Its main use is to talk to hardware peripherals from userland: to read or manipulate state, and to dump registers. It is similar, but more powerful than devmem2: It supports accessing multiple memory locations in one call, and can (hex-)dump a range of memory.


^ look who did it :)


I think it has to do with mmap() , which likely does: map those registers into this window of memory, and now those *registers* GPIO (or any memory mapped hardware registers) etc, is right there at your disposal. This is similar but far more 'advanced' (light years) from those BASIC PEEK and POKE days. But that these days we are even more spoilt and asked for *device drivers* and/or /proc and /sys file system so that *everything is a file*, without even needing peek and poke. GPIO ? just peek and poke. how about 'bare metal linux', well we are close, right down to the metal  :)



Link to comment
Share on other sites

So I feel I have made some progress but currently have very little to show for it. Sharing some of what I have tested here in the hopes that someone else can take a look and fill in any missing pieces.

I have managed to get the following orangepizero conf building cleanly in Armbian using 'edge' (6.6.5) and 'current' (6.1.66) but unfortunately neither of the generated images boots. The 'edge' image shows a green LED with blinking red LED after about 10 seconds, but 'current' seem to be a non-starter. I have currently only tested both images with HDMI, so may just been a display configuration issue.

I was going to post a link to a github repo, but decided it's probably just as easy to post the single config file here for discussion. I have added the following orangepi zero 3 config to my local copy of the current Armbian build framework. This file references the specific commit in mainline u-boot where the Orange Pi defconfig was merged (discussed above) and also references the Orange Pi defconfig. The build correctly downloads u-boot from mainline and finds the defconfig and builds cleanly (from what I can see).


# Allwinner H618 quad core 1GB/2GB/4GB RAM SoC WiFi SPI USB-C
BOARD_NAME="Orange Pi Zero3"

There was also an issue with applying one of the sunxi patches with the 'edge' kernel, so I have renamed that patch for the time being as I haven't had a chance to dig too deeply into this, but it appears others have reported similar issues with the patch, and the patching issue doesn't look related to the above configuration. By looking at the ignored patch, it's primarily defconfig changes for DRAM timings, but doesn't include anything orangepizero specific. All the other patches in this directory appear to apply cleanly so haven't looked any closer at them.

Renamed broken patch so Armbian ignores it:

/boot/patch/u-boot/u-boot-sunxi/allwinner-adjust-default-dram-clockspeeds.patch -> /boot/patch/u-boot/u-boot-sunxi/allwinner-adjust-default-dram-clockspeeds.patch.ignore


I will check the 'edge' image with a serial cable to see if it's producing anything while the lights are blinking, but keen to hear if anyone else has had success with this.

Edited by pixdrift
Link to comment
Share on other sites

Well sorry for the quick double post, I found a serial cable and can confirm that the Orange Pi Zero 3 image boots with the above configuration and works over serial cable (red blinking is disk IO of boot process).

Stepped through the Armbian configuration, it's picked up the correct memory configuration (I only have 4G model to test). I have also confirmed that network (wired) works 'out of the box' and plugged into a network, got DHCP address.. all working without issues (not stress tested, but validated).

root@orangepizero3:~# uname -a
Linux orangepizero3 6.6.5-edge-sunxi64 #1 SMP Fri Dec  8 07:52:25 UTC 2023 aarch64 GNU/Linux

root@orangepizero3:~# free
               total        used        free      shared  buff/cache   available
Mem:         4027112      251964     3623560        5500      292596     3775148
Swap:        2013552           0     2013552

root@orangepizero3:~# lsmod
Module                  Size  Used by
rfkill                 24576  1
sunrpc                290816  1
lz4hc                  12288  0
lz4                    12288  0
zram                   28672  3
binfmt_misc            20480  1
sunxi_cedrus           49152  0
v4l2_mem2mem           28672  1 sunxi_cedrus
videobuf2_dma_contig    20480  1 sunxi_cedrus
videobuf2_memops       16384  1 videobuf2_dma_contig
polyval_ce             12288  0
videobuf2_v4l2         20480  2 sunxi_cedrus,v4l2_mem2mem
polyval_generic        12288  1 polyval_ce
videodev              221184  3 sunxi_cedrus,videobuf2_v4l2,v4l2_mem2mem
videobuf2_common       45056  5 sunxi_cedrus,videobuf2_dma_contig,videobuf2_v4l2,v4l2_mem2mem,videobuf2_memops
mc                     57344  5 sunxi_cedrus,videodev,videobuf2_v4l2,videobuf2_common,v4l2_mem2mem
fuse                  126976  1
dm_mod                131072  0
motorcomm              24576  1
dwmac_sun8i            24576  0
mdio_mux               12288  1 dwmac_sun8i

Above is using bookworm:

Edited by pixdrift
Link to comment
Share on other sites

thanks for the update, as for myself, I'm still caught in a bind trying to build armbian as I'm using a systemd-nspawn container.

it has to do with loop devices, systemd-nspawn do not allow loop devices, so it breaks the build and stop at the step where it builds the images.

I've found some ways to get around the loop devices issue, but i hit further bummers as I don't just need a single loop device but loop control as well. And that is done with some pretty large workarounds so that I attempt to patch loop devices in systemd-nspawn container manually.


But your attempts with 6.6 kernel is really good progress, hope I can reproduce that with 2GB boards.

I think we'd 'focus' on 6.6 and above 'edge' builds for Orange Pi Zero 3 as I think this would most likely succeed, possibly 'easiest'. 6.1 if it is 'ever' done would be a 'back port' and I think it may not be that simple after all. There is a marginal chance that the same group of kernel developers may attempt that backport themselves, then it would make it possible to 'support' 6.1 with the developments at 6.6+ 'edge'. Orange Pi zero 3 requires LPDDR4 support and the new AXP313A PMIC support, for that alone, I don't think it'd work out of box in 6.1 as this 2 things has been developed (including the DTS) mainly for 6.6 kernel. This is gathered from reading the various posts and commit messages posted in comments earlier.


Link to comment
Share on other sites

I started to investigate the display issue and why it's not producing anything.

Looking at the Zero 2 configuration the HAS_VIDEO_OUTPUT has been set to 'no' and DEFAULT_CONSOLE is set to 'serial' which means it won't output anyway. Not sure if this is intentional in the Zero 2, I was wondering why the Zero 2 board didn't display anything when I tested Armbian on a Zero 2 board. I might contact that board maintainer and try and get some history to save myself some time researching.



I enabled these display options in the Zero 3 configuration I posted, but as mentioned, it doesn't appear to work. I confirmed in the boot configuration in the final image that these settings were added correctly, and console should be output to display (if it's there).

If anyone has an Orange Pi SDK build (or DietPi) running, would be good to see an lsmod from there (if you have HDMI display working) to compare, otherwise I will start picking through what the Orange Pi SDK image build does to get the display working in that image, it may still need patching on edge because required changes aren't in mainline yet.

In terms of getting it working for 6.1, I personally don't have any real motivation to get it working on a previous kernel, but can understand the benefits of having it connected to an LTS version. Will look at that as a lower priority, getting a working display is my focus now. :)

I expect the same configuration that is posted above will work for 1GB/2GB/4GB boards, there only seems to be modifications in configuration for the 1.5GB variant.

Edited by pixdrift
Link to comment
Share on other sites

Thanks for posting those links @ag123, I will read them tomorrow.

Only a quick update from me.

I booted the Orange Pi released version of Debian Bookworm (Orangepizero3_1.0.2_debian_bookworm_server_linux6.1.31) for a comparison, and it has HDMI out, at least for the framebuffer... not currently looking at acceleration... just any video output on HDMI from the Armbian build tool build. :)


These are the dmesg lines related to HDMI from the Orange Pi Debian image

[    0.032022] platform 6000000.hdmi: Fixed dependency cycle(s) with /soc/tcon-top@6510000
[    0.034437] platform 6000000.hdmi: Fixed dependency cycle(s) with /connector
[    1.436612] sun8i-dw-hdmi 6000000.hdmi: supply hvcc not found, using dummy regulator
[    1.436839] sun8i-dw-hdmi 6000000.hdmi: Detected HDMI TX controller v2.12a with HDCP (DWC HDMI 2.0 TX PHY)
[    1.437282] sun8i-dw-hdmi 6000000.hdmi: registered DesignWare HDMI I2C bus driver
[    1.437669] sun4i-drm display-engine: bound 6000000.hdmi (ops 0xffff800008e84f08)

This is the lsmod output

orangepi@orangepizero3:~$ uname -a
Linux orangepizero3 6.1.31-sun50iw9 #1.0.2 SMP Thu Sep 28 12:01:45 CST 2023 aarch64 GNU/Linux

orangepi@orangepizero3:~$ lsmod
Module                  Size  Used by
overlay               126976  0
algif_hash             16384  1
algif_skcipher         16384  1
af_alg                 24576  6 algif_hash,algif_skcipher
bnep                   28672  2
hci_uart              135168  1
btqca                  24576  1 hci_uart
btrtl                  28672  1 hci_uart
btbcm                  20480  1 hci_uart
btintel                40960  1 hci_uart
bluetooth             712704  29 btrtl,btqca,btintel,hci_uart,btbcm,bnep
ecdh_generic           16384  2 bluetooth
ecc                    32768  1 ecdh_generic
sunrpc                286720  1
lz4hc                  16384  0
lz4                    16384  0
sprdbt_tty             36864  2
polyval_ce             16384  0
polyval_generic        16384  1 polyval_ce
sunxi_cedrus           45056  0
sunxi_cir              20480  0
videobuf2_dma_contig    24576  1 sunxi_cedrus
dw_hdmi_cec            16384  0
rc_core                49152  2 sunxi_cir
v4l2_mem2mem           36864  1 sunxi_cedrus
videobuf2_memops       20480  1 videobuf2_dma_contig
videobuf2_v4l2         24576  2 sunxi_cedrus,v4l2_mem2mem
videobuf2_common       49152  5 sunxi_cedrus,videobuf2_dma_contig,videobuf2_v4l2,v4l2_mem2mem,videobuf2_memops
videodev              204800  4 sunxi_cedrus,videobuf2_v4l2,videobuf2_common,v4l2_mem2mem
mc                     53248  5 sunxi_cedrus,videodev,videobuf2_v4l2,videobuf2_common,v4l2_mem2mem
display_connector      20480  0
zram                   28672  3
binfmt_misc            24576  1
sprdwl_ng             352256  0
sunxi_addr             20480  1 sprdwl_ng
cfg80211              372736  1 sprdwl_ng
rfkill                 36864  7 sprdbt_tty,bluetooth,cfg80211
uwe5622_bsp_sdio      208896  2 sprdbt_tty,sprdwl_ng
fuse                  126976  1
dm_mod                131072  0
motorcomm              24576  1
dwmac_sun8i            28672  0
mdio_mux               16384  1 dwmac_sun8i

Interestingly, for the images I tested, one of my monitors complained about the HDMI input timing of the signal coming from the Orange Pi Zero 3, so I re-validated with the monitor that was happy to display the output (and confirmed again the image I built with Armbian build tool doesn't have HDMI output.. yet).

After looking at bit closer at the patches that were being applied in Armbian (15 in total, with 1 set to ignore), I found the following, which I think may be relevant.


This looks to specifically enable the GPU on H616 boards and is enabled for any build that passes the CONFIG_MACH_SUN50I_H616 option, which the Orange Pi Zero 3 configuration does (in the defconfig file). The hack is only a single call to a write function, but I am wondering if the h616 and h618 SoCs may differ enough (like the DRAM timing configuration) that this value needs to be configured specifically for h618 boards.. I will chase this up and see if I can find an answer.

+               /* enable GPU */
+               writel(0, 0x7010254);


Edited by pixdrift
Link to comment
Share on other sites

saw that cedrus keyword, hence googled and stumbled into this:


H6 Supported (5.1) Supported (5.0)

H616 Untested Untested


if we made an assumption that H616, H618 is a 'simplified' H6, there is a chance it may work.

However, while reading that I'm nore sure if that is after all part of mainline etc.

e.g. can we find an option to select 'cedrus' in the make config, at least as a module?


but that beyond just the kernel, some support may be needed in u-boot as well. But that if u-boot doesn't have display support, it may mean having to go the uart console route, until it loads and start the kernel, then for the kernel to initialize and start the display


i really dislike those 'arbitrary' register writes, but I'd guess there is little choice if after all it is undocumented.

and after GPU is 'enabled', how do the kernel knows where is the framebuffer etc? I'd think there'd need to be a 'driver' of some sort.


cedrus is an astonishing effort 700 thousand commits




Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines