Orange Pi Zero 3

[Werner]

16 minutes ago, TechX said:

he armbian image that orange pi suggests

Armbian does not support this board. The images you may have found in the web are not ours. Complain where you got them from.

 

Our own Zero3 support is WIP: https://github.com/armbian/build/blob/main/config/boards/orangepizero3.wip

[TechX]

I’m not complaining as Ik you guys don’t support the orange pi version found on there website as I previously read. I’m more or less wondering about the current state of images that the guys in this topic have made and whether they’d be able to be used for a reliable server.

Edited January 8 by TechX

[ag123]

if you browse the thread above, this is still in *testing* *alpha* stage, *use at your own risk* , *unsupported* and review the prior comments and you may find the images from pixdrift.

if you do *test* them feedback on your findings here, and provide details about your board, ram size, image used etc.

There is one thing about these chips/boards e.g. H618, I *cannot find* the reference manual / user manual for H618, after searching in several search engines google, bing, yahoo (altavista), you.com,

and all the developers simply *assume* that it is the same as / similar to H616. Hence, it is practically *reverse engineered*. This may practically  mean that *use at your own risk* probably would always apply even if this become 'community' supported, i.e. it is some wild near blind attempts to make it work, and it is an accident that various things works by virtue of pure *wild tries*.

the chip manufacturer has thus far not provided *public* reference doc nor support any of these and the codes are *wild tries* and they just happened to work with our collective guesses.

[Stephen Graf]

@Gunjan Gupta, Would you be able move forward the following patch. I have been working on the zero3 overlays and with your help I have made some progress. But it all depends on having the overlay_prefix set.  It makes sense to point to the h616 overlays as the zero3 and zero2 are common for the items that would normally go into the overlays. I have been using the proposed change and it makes the fixup.scr work on boot and allows armbian-config > System > Hardware to work and load overlays on boot

 

diff --git a/config/boards/orangepizero3.wip b/config/boards/orangepizero3.wip
index 18bcae79d..642eb216f 100644
--- a/config/boards/orangepizero3.wip
+++ b/config/boards/orangepizero3.wip
@@ -3,6 +3,7 @@ BOARD_NAME="Orange Pi Zero3"
 BOARDFAMILY="sun50iw9"
 BOARD_MAINTAINER="viraniac"
 BOOTCONFIG="orangepi_zero3_defconfig"
+OVERLAY_PREFIX=sun50i-h616
 BOOT_LOGO="desktop"
 KERNEL_TARGET="current,edge"
 FORCE_BOOTSCRIPT_UPDATE="yes"

 

[Stephen Graf]

PH5 pin assignment conflict.

 

The sun50i-h616.dtsi has PH5 in 2 pin assignments.

 

                        i2c3_ph_pins: i2c3-ph-pins {
                                pins = "PH4", "PH5";
                                function = "i2c3";
                        };

and

                        /omit-if-no-ref/
                        spi1_cs0_pin: spi1-cs0-pin {
                                pins = "PH5";
                                function = "spi1";
                        };

 

The diagrams for zero3 and zero2 both show that spi1-cs as PH9. The zero2w has a very different layout!

 

I think

patch/kernel/archive/sunxi-6.7/patches.armbian/arm64-dts-allwiner-sun50i-h616.dtsi-add-usb-ehci-ohc.patch

which has changes for spi also should be modified to change spi1_cs0

                                pins = "PH9";

There is no reference to PH9 in the zero3 dtb.

[jokakilla]

Just a quick update from a "test user" point of view running "Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.7.0-rc7.i2c3.test.tar.xz". i2c port and io stuff isn't very interesting for me personally..bear with me

I'm using SBC more or less as little servers.

 

Overall stability: Pretty good. No crashes reboots or so

Docker: Hardware device forwarding to container (zigbee usb stick) works fine. Giving containers separate interface in different VLAN (ipvlan) works well.

lmsensors gives reasonable information:

{
   "cpu_thermal-virtual-0":{
      "Adapter": "Virtual device",
      "temp1":{
         "temp1_input": 37.079
      }
   },
   "gpu_thermal-virtual-0":{
      "Adapter": "Virtual device",
      "temp1":{
         "temp1_input": 37.970
      }
   },
   "ddr_thermal-virtual-0":{
      "Adapter": "Virtual device",
      "temp1":{
         "temp1_input": 37.727
      }
   },
   "ve_thermal-virtual-0":{
      "Adapter": "Virtual device",
      "temp1":{
         "temp1_input": 36.674
      }
   }
}

 

mpstat is also working fine. Idle is little low because Unifi server is eating up lots or resources when starting 🫣:

{"sysstat": {
	"hosts": [
		{
			"nodename": "orangepizero3",
			"sysname": "Linux",
			"release": "6.7.0-rc7-edge-sunxi64",
			"machine": "aarch64",
			"number-of-cpus": 4,
			"date": "08.01.2024",
			"statistics": [
				{
					"timestamp": "22:15:23",
					"cpu-load": [
						{"cpu": "all", "usr": 32.22, "nice": 0.00, "sys": 2.99, "iowait": 6.49, "irq": 0.00, "soft": 0.01, "steal": 0.00, "guest": 0.00, "gnice": 0.00, "idle": 58.29}
					]
				}
			]
		}
	]
}}

 

Edited January 8 by jokakilla

[pixdrift]

On 1/8/2024 at 10:06 PM, TechX said:

I’m not complaining as Ik you guys don’t support the orange pi version found on there website as I previously read. I’m more or less wondering about the current state of images that the guys in this topic have made and whether they’d be able to be used for a reliable server.

Hi @TechX and welcome to the forum.

The current state of the images is that they are in heavy development, so they can't be expected to be reliable. That being said, they won't get to a state of being 'reliable' without adequate testing, so you've arrived at the right time to contribute to that if you are interested, and the result at the end may well be a reliable image

The latest build I have done for testing is available here (USE AT YOUR OWN RISK)
https://armdev.pixeldrift.net/orangepi/zero3/Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.7.0-rc7.i2c3.test.tar.xz

By all means, test this image and see what kind of results you get and provide feedback here. We're more interested in the lower level feedback on network/wifi/bluetooth etc, rather than application and userspace feedback that applications don't work as expected on the image. Hopefully with more feedback we can get to the point of a reliable image.

Cheers for your interest 

Edited February 2 by pixdrift

[pixdrift]

4 hours ago, jokakilla said:

Overall stability: Pretty good. No crashes reboots or so

Thanks for this feedback @jokakilla, are you running a heatsink?

Interested in CPU temps, uptime, and cpufreq-info output if you have it? would be good to confirm that is working reliably over the longer term.

[pixdrift]

4 hours ago, Stephen Graf said:

The diagrams for zero3 and zero2 both show that spi1-cs as PH9. The zero2w has a very different layout!

Yeah I was looking at the zero2w layout yesterday.. I think the overlay work may trip us up when we get to the zero2w, as it is also H618.

I am keen to get the single line OVERLAY_PREFIX into the configuration in mainline Armbian, but also wonder if we should just break out the overlays to be board specific given the complexity with zero2w? what will we use as an OVERLAY_PREFIX when we hit zero2w?

If nothing else, this would be a good fix to get in and thanks to @Stephen Graf for digging through this, it has been good to read your various attempts and progress through getting it working

[Stephen Graf]

Quote

what will we use as an OVERLAY_PREFIX when we hit zero2w?

The sun50-h616.dtsi will not work for zero2w either.  Zero2 and zero3  i/o layout are the same but zero2w is different.  Dtb is all about describing the hardware and so zero2w will need something different.

Edited January 9 by Stephen Graf
typo

[pixdrift]

1 minute ago, Stephen Graf said:

The sun50-h616.dtsi will not work for zero2w either.  Zero2 and zero3  i/o layout are the same but zero2w is different.  Dtb is all about describing the hardware and so zero2 will need something different.

What are your thoughts on splitting the overlay files out to be board specific? they will be some duplication, but will give the flexibility to configure the boards exactly as needed, without potential impact to current/future boards?

I think the overhead/duplication is worth the trade off, but maybe that isn't a decision we have the luxury of making.

@Gunjan Gupta do you have any thoughts on making the overlay configuration board specific for these boards? zero2, zero2w, zero3?

[Stephen Graf]

I think the overlay files for zero2 and zero3 can be the same as the hardware layout is identical. Zero2w is different.

I have put together and tested 3 overlay files,

- enable i2c3

- enable spi1 and create spidev

- change usbotg to host

I could use the i2c3 and spi1 overlays to fix the PH5 duplication if it will not be done in sun50i-h616.dtsi.

Usb2 and 3 are already enabled and work without further changes.

I am still looking into uart5 to determine what is required. Ir is another item to look at.  Then there is sound which has output on the header. But since sound is not yet working that will have to wait.

All these overlays currently exist in the Zunlong image. After @Gunjan Gupta showed me how to build an overlay I am now able to reverse engineer the Zunlong dtbos and create dts/dtbo for Armbian.

[pixdrift]

4 hours ago, Stephen Graf said:

All these overlays currently exist in the Zunlong image. After @Gunjan Gupta showed me how to build an overlay I am now able to reverse engineer the Zunlong dtbos and create dts/dtbo for Armbian.

It sounds like just a matter of giving you some time to work through this? if you want a hand preparing a PR and reviewing.. or generating/hosting test builds for others, let me know  Based on this, we shouldn't promote my i2c3 changes (which enables in the base dts) as it is optional and should be in your overlay work.

Let me know how you go, and if you need anything... appreciate your efforts on this!

Edited January 9 by pixdrift

[Gunjan Gupta]

13 hours ago, Stephen Graf said:

The diagrams for zero3 and zero2 both show that spi1-cs as PH9. The zero2w has a very different layout!

I see SPI1_CS1 is PH9 for zero2w as well based on the schematics made available by orange pi. Why do you feel its different?

[Gunjan Gupta]

10 hours ago, pixdrift said:

What are your thoughts on splitting the overlay files out to be board specific? they will be some duplication, but will give the flexibility to configure the boards exactly as needed, without potential impact to current/future boards?

overlays are generally soc specific and allow a specific functionality to be enabled or disabled. For example, you can think of creating an overlay that will enable all things are are available on headers of zero3, but then as Stephen pointed out, some pins will be used in more than one functionality. Also to add it it, a person using the header might need only one i2c or just the pwm or some other single functionality while needing rest of the pins to continue working as single gpio. Hence creating a board specific overlay that enables everything is not a solution. 

 

You can however create overlays enabling multiple functionalities needed for an addon board/hat. This will be ok as only people having that addon board will enable the same. For example all the functionality exposed by addon board used on the 13-pin header like usb, tv-out, ir, audio must be combined into a single dtoverlay and should not be enabled by default on the device. So we do have some extra things enabled that we need to get rid of from dts and move to seperate overlay.

[Gunjan Gupta]

16 hours ago, Stephen Graf said:

@Gunjan Gupta, Would you be able move forward the following patch

Raise a PR and I will review and merge. I volunteered to be the maintainer for the board, but that doesn't mean I am the only one that can raise the PR for the same. Currently I am working on a vim1s and vim4 issue, so am a bit busy trying to figure that out. Until thats solved, I trust the community to take care of the development for this board.

[Sma]

16 hours ago, pixdrift said:

Interested in CPU temps, uptime, and cpufreq-info output if you have it? would be good to confirm that is working reliably over the longer term.

I may try to get in on this. I'm looking to use my OPiZ3 for discord bots, and later maybe some other projects like an all-sky camera/weather station, that'll likely not be for the Z3 since it probably wouldn't be able to handle the image processing/storage, but that is a bit down the road still. I'm also thinking about MAYBE adding addressable LED support to the bots, so bot status could be displayed via different colors/patterns. 

I haven't done any work yet to port the existing bot from node.js to python, which is I think where I want to take it. I'll go back and find the latest image you posted @pixdrift and let it run, maybe tinker with setting up the bot and note down temps etc (I'm sure theres a way to have it log that data?). So far in my limited testing, the heatsink has barely been warm, and the temps haven't been very high, hovering around 100F give or take.

I do have a heatsink, it's a full plate, with the standard OEM heat transfer pads. The plate covers the whole board, along with a plate on the bottom. I also have a 3.5" touch screen, but since you all are working on the SPI/i2c stuff, I haven't tried getting it to work yet. It is of course running off the power provided by the pin headers though, and is connected via HDMI. The interesting thing is that Armbian was still set for 1920x1080 when I connected the 3.5" screen, and it worked, but of course, all the fonts were so tiny you couldn't read them. The recommended resolution for the screen wasn't listed when I went to change it, but it displays fine at the lowest resolution that Armbian lists. Everything is readable at least. 

[Stephen Graf]

@Gunjan Gupta, @pixdrift Re zero2w

The hardware output on the zero2 is very different from the zero2/3.  The zero2w has a 40 pin header and a 24 pin connector while the zero2/3 have a 26 pin and 13 pin header.

The zero2w exposes

- twi0, 1, 2 (i2c)

- uart0, 2, 3, 4

- spi1

- pm1, 2, 4

- usb2, 3

and a bit more

 

The zero2/3 expose

- i2c3 (twi)

- spi1

- uart5

- usb2, 3

and a bit more.

 

Some of the pin definitions are common, but many are not.  Also the zero2w has multiple definitions for some pins.

[Stephen Graf]

@pixdrift Since  @Gunjan Gupta is busy with another project he asked me to prepare a PR for the following patch. I have never done this and so I am asking you to help with it.

 

It makes sense to point to the h616 overlays as the zero3 and zero2 are common for the items that would normally go into the overlays. I have been using the proposed change and it makes the fixup.scr work on boot and allows armbian-config > System > Hardware to work and load overlays on boot.

 

diff --git a/config/boards/orangepizero3.wip b/config/boards/orangepizero3.wip
index 18bcae79d..642eb216f 100644
--- a/config/boards/orangepizero3.wip
+++ b/config/boards/orangepizero3.wip
@@ -3,6 +3,7 @@ BOARD_NAME="Orange Pi Zero3"
 BOARDFAMILY="sun50iw9"
 BOARD_MAINTAINER="viraniac"
 BOOTCONFIG="orangepi_zero3_defconfig"
+OVERLAY_PREFIX=sun50i-h616
 BOOT_LOGO="desktop"
 KERNEL_TARGET="current,edge"
 FORCE_BOOTSCRIPT_UPDATE="yes"

 

 

(When I first started working, the concept of patching and PR consisted of shuffling a deck of IBM punched cards!)

[Gunjan Gupta]

27 minutes ago, Stephen Graf said:

Some of the pin definitions are common, but many are not.

The pin arrangement on the board can be different. But what pins can be used for what functionality is something that is fixed for the SoC. The pin PH9 for example, doesn't mean 9th pin on the header. Its the PH9 pin exposed on the h618 soc and will remain the same no matter whether that is exposed on header or used on the board to connect to some other device.

[Gunjan Gupta]

24 minutes ago, Stephen Graf said:

@pixdrift Since  @Gunjan Gupta is busy with another project he asked me to prepare a PR for the following patch. I have never done this and so I am asking you to help with it.

 

You already know what change needs to be done. All that is left is fork the armbian/build project on github, clone your fork, make and commit the change there and then push it back to github. Then whats left is creating a PR and github's UI will guide you with that. If you are not familiar with git and github that much, I am pretty sure you can find plenty of videos for the same on youtube that will walk you through it

[jokakilla]

Zitat

Thanks for this feedback @jokakilla, are you running a heatsink?

Interested in CPU temps, uptime, and cpufreq-info output if you have it? would be good to confirm that is working reliably over the longer term.

  

Yup mine is running with a heatsink (kit from aliexpress). Idle 37°C. After running "stress --cpu 4" for a few minutes it's going up to 60°C. The sensor values delivered from the SOC seem legit.

Zitat

joka@orangepizero3:~$ sensors -j
{
   "cpu_thermal-virtual-0":{
      "Adapter": "Virtual device",
      "temp1":{
         "temp1_input": 60.488
      }
   },
   "gpu_thermal-virtual-0":{
      "Adapter": "Virtual device",
      "temp1":{
         "temp1_input": 54.008
      }
   },
   "ddr_thermal-virtual-0":{
      "Adapter": "Virtual device",
      "temp1":{
         "temp1_input": 53.117
      }
   },
   "ve_thermal-virtual-0":{
      "Adapter": "Virtual device",
      "temp1":{
         "temp1_input": 56.438
      }
   }
}

 

Have been running some stress tests for io and ram too without instabilities: "stress --cpu 4 --io 4 -m 4 --vm-bytes 512M -t 300".

Not sure if the cpu frequency and so on is controlled by the kernel, driver or by the SOC internally. So no idea if this is interesting but the data shown by cpufreq-info seems ok. After stress testing high percentage is at 1.51 GHz. When idling the percentage of time in 480 MHz is rising. So switching between different frequencies looks good. Unfortunately the tool is printing stuff in german.

Zitat

joka@orangepizero3:~$ cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Bitte melden Sie Fehler an cpufreq@vger.kernel.org.
analysiere CPU 0:
  Treiber: cpufreq-dt
  Folgende CPUs laufen mit der gleichen Hardware-Taktfrequenz: 0 1 2 3
  Die Taktfrequenz folgender CPUs werden per Software koordiniert: 0 1 2 3
  Maximale Dauer eines Taktfrequenzwechsels: 244 us.
  Hardwarebedingte Grenzen der Taktfrequenz: 480 MHz - 1.51 GHz
  mögliche Taktfrequenzen: 480 MHz, 600 MHz, 792 MHz, 1.01 GHz, 1.20 GHz, 1.51 GHz
  mögliche Regler: conservative, ondemand, userspace, powersave, performance, schedutil
  momentane Taktik: die Frequenz soll innerhalb 480 MHz und 1.51 GHz.
                    liegen. Der Regler "ondemand" kann frei entscheiden,
                    welche Taktfrequenz innerhalb dieser Grenze verwendet wird.
  momentane Taktfrequenz ist 480 MHz  (verifiziert durch Nachfrage bei der Hardware).
  Statistik:480 MHz:33,67%, 600 MHz:8,52%, 792 MHz:0,37%, 1.01 GHz:0,07%, 1.20 GHz:0,06%, 1.51 GHz:57,31%  (1262)
analysiere CPU 1:
  Treiber: cpufreq-dt
  Folgende CPUs laufen mit der gleichen Hardware-Taktfrequenz: 0 1 2 3
  Die Taktfrequenz folgender CPUs werden per Software koordiniert: 0 1 2 3
  Maximale Dauer eines Taktfrequenzwechsels: 244 us.
  Hardwarebedingte Grenzen der Taktfrequenz: 480 MHz - 1.51 GHz
  mögliche Taktfrequenzen: 480 MHz, 600 MHz, 792 MHz, 1.01 GHz, 1.20 GHz, 1.51 GHz
  mögliche Regler: conservative, ondemand, userspace, powersave, performance, schedutil
  momentane Taktik: die Frequenz soll innerhalb 480 MHz und 1.51 GHz.
                    liegen. Der Regler "ondemand" kann frei entscheiden,
                    welche Taktfrequenz innerhalb dieser Grenze verwendet wird.
  momentane Taktfrequenz ist 480 MHz  (verifiziert durch Nachfrage bei der Hardware).
  Statistik:480 MHz:33,67%, 600 MHz:8,52%, 792 MHz:0,37%, 1.01 GHz:0,07%, 1.20 GHz:0,06%, 1.51 GHz:57,31%  (1262)
analysiere CPU 2:
  Treiber: cpufreq-dt
  Folgende CPUs laufen mit der gleichen Hardware-Taktfrequenz: 0 1 2 3
  Die Taktfrequenz folgender CPUs werden per Software koordiniert: 0 1 2 3
  Maximale Dauer eines Taktfrequenzwechsels: 244 us.
  Hardwarebedingte Grenzen der Taktfrequenz: 480 MHz - 1.51 GHz
  mögliche Taktfrequenzen: 480 MHz, 600 MHz, 792 MHz, 1.01 GHz, 1.20 GHz, 1.51 GHz
  mögliche Regler: conservative, ondemand, userspace, powersave, performance, schedutil
  momentane Taktik: die Frequenz soll innerhalb 480 MHz und 1.51 GHz.
                    liegen. Der Regler "ondemand" kann frei entscheiden,
                    welche Taktfrequenz innerhalb dieser Grenze verwendet wird.
  momentane Taktfrequenz ist 480 MHz  (verifiziert durch Nachfrage bei der Hardware).
  Statistik:480 MHz:33,67%, 600 MHz:8,52%, 792 MHz:0,37%, 1.01 GHz:0,07%, 1.20 GHz:0,06%, 1.51 GHz:57,31%  (1262)
analysiere CPU 3:
  Treiber: cpufreq-dt
  Folgende CPUs laufen mit der gleichen Hardware-Taktfrequenz: 0 1 2 3
  Die Taktfrequenz folgender CPUs werden per Software koordiniert: 0 1 2 3
  Maximale Dauer eines Taktfrequenzwechsels: 244 us.
  Hardwarebedingte Grenzen der Taktfrequenz: 480 MHz - 1.51 GHz
  mögliche Taktfrequenzen: 480 MHz, 600 MHz, 792 MHz, 1.01 GHz, 1.20 GHz, 1.51 GHz
  mögliche Regler: conservative, ondemand, userspace, powersave, performance, schedutil
  momentane Taktik: die Frequenz soll innerhalb 480 MHz und 1.51 GHz.
                    liegen. Der Regler "ondemand" kann frei entscheiden,
                    welche Taktfrequenz innerhalb dieser Grenze verwendet wird.
  momentane Taktfrequenz ist 480 MHz  (verifiziert durch Nachfrage bei der Hardware).
  Statistik:480 MHz:33,67%, 600 MHz:8,52%, 792 MHz:0,37%, 1.01 GHz:0,07%, 1.20 GHz:0,06%, 1.51 GHz:57,31%  (1262)

 

 

Edited January 9 by jokakilla

[Sma]

@jokakilla ahh that's the same heatsink I have for mine, but from Amazon. 

Sorry for the large image, i'll try to make it smaller next time. 

 

Interestingly though, using x11vnc, i can move the mouse around, click on things, and use the keyboard over VNC, and the LCD stays off (no signal). It doesn't wake up until I hit something on the keyboard connected to the OPi. Not an issue for me, just an interesting observation.
 

Edited January 9 by Sma

[pixdrift]

3 hours ago, Stephen Graf said:

@pixdrift Since  @Gunjan Gupta is busy with another project he asked me to prepare a PR for the following patch. I have never done this and so I am asking you to help with it.

Absolutely.
 

@Gunjan Gupta has outlined the GitHub process, but it can be a bit obtuse the first time through.

That process aside, I was thinking the configuration change (PREFIX) and the overlays you are working on could all go in with a single PR, but if you prefer, we can do just the config update in a PR first.

 

I want to make sure people here have what the need to do the PR with some assistance. To break down the steps @Gunjan Gupta has summarised I have given a quick set of more detailed steps.  Sorry if it's simplified too much, I am hoping others reading this thread may benefit from it if they are new to Armbian and github.

1. Create a github account, will use the example 'ArmbianHacker' 

2. Browse to the main Armbian project https://github.com/armbian/build

3. At the top right there is a 'Fork' drop down, select this and then select 'Create a new fork', this is to essentially create a working copy of the code in your own namespace (account)

4. You can name the repository whatever you like, but I have used 'armbian_build' and I notice @Gunjan Gupta did the same because 'build' looks a bit too generic without the armbian context

5. You will now have a repository 'fork' of Armbian build in your own namespace, eg. ArmbianHacker/armbian_build

6. The next step is my personal workflow, but I prefer to work on a branch in my own fork of the repo, so it doesn't get mixed up with your copy of the 'main' branch that is tracking the same branch in 'Armbian/build', so in your own copy of the repository, drop down the branch dropdown box that will say 'main' and create a new branch by typing 'zero3_overlay_fixes' or similar, when you type out a branch name the dropdown menu then gives you the option to 'Create new branch zero3_overlay_fixes from main', click this to create your new branch

7. Now you have your new branch, make sure it's selected in the branch dropdown, and you can make the updates/modifications in that branch that you would like to include in your PR. If you are using git command line, clone your copy of the repository (ArmbianHacker/armbian_build) and switch to the  'zero3_overlay_fixes' branch to make your changes, then push them back up. This branch is where we can collaborate on the changes
8. Once you are satisfied with the changes in this branch, the PR process is fairly straightforward (but can discuss that further along). With the the 'zero3_overlay_fixes' branch selected in the repository view, you will drop down 'Contribute' and then click 'Open pull request', and select 'Armbian/build:main' as the target. This will then show you a diff between your changes and the Armbian project, and allow you to raise the PR back to the main project, where it will go through the Armbian review process and be merged if it meets their requirements/standards.

 

If anyone has any concerns with these instructions please give me feedback.. or if I have missed something obvious that may help others reading this, please let me know! 

Edited January 9 by pixdrift

[SteeMan]

Also the contribute/PR process as documented in the Armbian Docs:  https://docs.armbian.com/Process_Contribute

[Stephen Graf]

I have a zero3 with 1G ram. I just stuck some small heats sinks on the cpu and mem. A stress test and results are included below.

Before Armbian was viable I compiled the Linux kernel on this system using the Zunlong image.  It ran for a couple of hours with all 4 cpus at 100%.  The temperature stayed constant at about 65, but it worked without a problem.

 

sysadmin@orangepizero3:~$ sudo stress --cpu 4 --io 4 -m 4 --vm-bytes 256M -t 300
stress: info: [2144] dispatching hogs: 4 cpu, 4 io, 4 vm, 0 hdd
stress: info: [2144] successful run completed in 301s

 

12:07:25   480 MHz  3.60   0%   0%   0%   0%   0%   0%  41.3 °C  0/5
12:07:31   480 MHz  3.39   0%   0%   0%   0%   0%   0%  41.3 °C  0/5
12:07:36  1512 MHz  3.20  22%  15%   7%   0%   0%   0%  43.8 °C  0/5
12:07:41  1512 MHz  4.07 100%  64%  35%   0%   0%   0%  48.0 °C  0/5
12:07:46  1512 MHz  4.78 100%  64%  35%   0%   0%   0%  48.7 °C  0/5
12:07:51  1512 MHz  5.44 100%  64%  35%   0%   0%   0%  49.3 °C  0/5

...

12:12:09  1512 MHz 13.22 100%  66%  33%   0%   0%   0%  56.7 °C  0/5
12:12:14  1512 MHz 13.20 100%  64%  35%   0%   0%   0%  56.5 °C  0/5
12:12:19  1512 MHz 13.18 100%  65%  34%   0%   0%   0%  56.4 °C  0/5

Time        CPU    load %cpu %sys %usr %nice %io %irq   Tcpu  C.St.
12:12:25  1512 MHz 13.17 100%  64%  35%   0%   0%   0%  57.0 °C  0/5
12:12:30  1512 MHz 13.16 100%  65%  34%   0%   0%   0%  56.8 °C  0/5
12:12:35  1512 MHz 13.14  96%  62%  30%   0%   3%   0%  56.8 °C  0/5
12:12:40   480 MHz 12.17   0%   0%   0%   0%   0%   0%  51.0 °C  0/5
12:12:45   480 MHz 11.28   0%   0%   0%   0%   0%   0%  49.9 °C  0/5
12:12:50   480 MHz 10.45   0%   0%   0%   0%   0%   0%  49.1 °C  0/5
12:12:55   480 MHz  9.69   0%   0%   0%   0%   0%   0%  48.4 °C  0/5

...

12:56:56   480 MHz  1.00   0%   0%   0%   0%   0%   0%  39.1 °C  0/5
12:57:01   480 MHz  1.08   0%   0%   0%   0%   0%   0%  39.5 °C  0/5
12:57:06   480 MHz  1.07   0%   0%   0%   0%   0%   0%  39.3 °C  0/5
12:57:11   480 MHz  1.06   0%   0%   0%   0%   0%   0%  39.2 °C  0/5

[pixdrift]

Not wanting to side track this thread off the Orange Pi, but I found some info about an upcoming h618 board from Sipeed, the Longan Pi 3H, which is similar to the Orange Pi Zero2W.

From the news I have read and the store, it's in early production and appears to have limited availability.
https://www.aliexpress.us/item/3256806204597847.html?gatewayAdapt=glo2usa

The reason it may be useful in this thread, is the mainlining effort they have undertaken may have some crossover with what we are looking at for the Orange Pi Zero 3, so their repository may be a good point of reference for patches/changes etc:
https://github.com/sipeed/LonganPi-3H-SDK

 

-edit-

 

Couldn't help myself, I have ordered one 

Edited January 10 by pixdrift

[pixdrift]

Well.. one small line for orangepizero3.wip, one giant leap for Orange Pi Zero 3

The overlay PR fix from @Stephen Graf has been merged into Armbian.. thanks for sticking with it.. awesome to have more people contributing 

https://github.com/armbian/build/commit/08623d0e37dc02cb728b264f1e64771ddaba8025

 

[jokakilla]

That are awesome news. Congratulations!

 

Do we have an overview whats still "missing"?

 

For me personally it looks already pretty nice and complete.

Basic functionality seems stable and network, WiFi, bluetooth, io Pins, HDMI are working now to my knowledge. I believe USB via expansion board too? What about audio and IR?

 

 

 

[pixdrift]

1 hour ago, jokakilla said:

Do we have an overview whats still "missing"?

You have given a pretty good summary.

The main bits still missing:

Main board:
- HDMI audio output

Expansion board:
- Infrared receiver

- Analog audio output

- Microphone isn't supported on Zero 3 (hardware limitation)

 

There are HDMI audio patches available, and have been linked from here, it just hasn't been a focus. To be honest, I am not sure how to test this as I don't have anything that supports HDMI audio handy, can anyone advise if the following would be a good box for testing? (plug headphones in to verify HDMI audio), if so I will buy one for testing.
https://www.aliexpress.us/item/1005005630394541.html

Not sure what is required for analog audio to be honest, I will need to check if they actually have that working on the Zero2.

The other thing that would be good would be any suggestions/recommendations for a basic test that can be run to confirm both the audio components are working, ie. look for certain devices in device tree, attempt playback/volume control etc. The simpler the test, the easier it will be to be able to get people on board and testing.

Edited January 10 by pixdrift