Orange Pi Zero 3

[Gunjan Gupta]

Raised another PR for HDMI support. Its merged now. Pending things as I understand are now audio, dma, iommu and cpufreq for H618

[pixdrift]

Builds for PR6116 from @Gunjan Gupta are now up, but this has been merged into mainline now I see. Either way, you can provide feedback on the current status of Zero2 / Zero3 in Armbian with these images.

Note: CPU Frequency not working in zero3 is a known issue, as is load average due to the WiFi driver.

https://armdev.pixeldrift.net/orangepi/zero2/pr_testing/
https://armdev.pixeldrift.net/orangepi/zero3/pr_testing/

Edited February 2 by pixdrift

[Stephen Graf]

I got a fresh copy of the repository and built an xfce image for zero3.  The desktop works properly now without any of the malfunctions that occurred on the previous build.

Still I would not recommend this machine as a PC replacement.  Is there an option to stop implementing zram on the build? My machine only has 1GB and swapping to ram does not help.

[pixdrift]

@Gunjan Gupta with key pieces going in to the orange pi zero shared config, it may be a good time to add your zero2w patches?

I notice u-boot still lacks an entry for zero2w, and there are some minor differences with zero3, but now that I have the zero2w hardware I am happy to test/iterate and provide feedback with you on a PR.

[johndo100]

I've just install latest build from https://github.com/viraniac/armbian_build.

I'm using server version and it works so far.

I'll test the xfce version in the next day.

 

 

tio_ttyUSB0_2023-12-31T11:45:07.log

[Gunjan Gupta]

5 hours ago, pixdrift said:

it may be a good time to add your zero2w patches?

Feel free to do that. I only worked on zero2w for a client. I don't have the device and hence can't be the maintainer for that one. Also I have no interest to add that to armbian either. But if you will raise a PR, I will review the same.

 

BTW, there seems to be a sudden influx of H618 based devices, I noticed Bananapi M4 berry and there is also Sipeed Longan Pi3H. More devices must be coming soon as well.

[pixdrift]

2 hours ago, Gunjan Gupta said:

Feel free to do that. I only worked on zero2w for a client. I don't have the device and hence can't be the maintainer for that one. Also I have no interest to add that to armbian either. But if you will raise a PR, I will review the same.

Going through your patch set in GitHub on the zero2w branch, it looks fairly straightforward, but I think I would prefer that it inherits configuration from the shared orangepi zero dtsi now that it has matured with your latest updates, similar to how zero2 and zero3 currently are so I may move it in a PR, can you see any reason not to do this considering it's H618 based and shares some commonality?

On a similar note, I think that dtsi is named fairly poorly (this is a kernel issue I guess) because the orangepizero device (not 2 or 3, the original) doesn't really share any commonality and it looks like the dtsi is for that 

Another update @Gunjan Gupta.. I tested your PR6116 build on the Zero 2 and video is working but there is still some glitches in the display, but it does work.

@Stephen Graf good question about zram/zswap.. I will dig a little deeper but not sure on how modular turning on features are like this (I have seen feedback about Armbian mentioning similar issues of configurability). I had a similar experience to you on the Zero2, as it's only 1G of RAM and quickly OOM'd / locked up in testing with XFCE/desktop. I really wonder if MicroSD with a low kernel swapiness value configured is still as much of an issue as it was originally when people started using SBCs and were concerned about wear and premature memory card failure?

Edited December 31, 2023 by pixdrift

[Gunjan Gupta]

15 minutes ago, pixdrift said:

I tested your PR6116 build on the Zero 2 and video is working but there is still some glitches in the display, but it does work.

There are still glitches? Can you tell me the steps to reproduce the same? I will try it on my zero3

[Gunjan Gupta]

17 minutes ago, pixdrift said:

Going through your patch set in GitHub on the zero2w branch, it looks fairly straightforward, but I think I would prefer that it inherits configuration from the shared orangepi zero dtsi now that it has matured with your latest updates, similar to how zero2 and zero3 currently are so I may move it in a PR, can you see any reason not to do this considering it's H618 based and shares some commonality?

I would say keep it in the format as done in mainline or next kernel that way we can easily handle kernel updates.

[Gunjan Gupta]

9 hours ago, Stephen Graf said:

Is there an option to stop implementing zram on the build? My machine only has 1GB and swapping to ram does not help.

Its setup using a systemd service as I remember armbian-zram-config.service. Disabling that service should be enough. 

[Gunjan Gupta]

23 minutes ago, pixdrift said:

On a similar note, I think that dtsi is named fairly poorly (this is a kernel issue I guess) because the orangepizero device (not 2 or 3, the original) doesn't really share any commonality and it looks like the dtsi is for that 

Yeah I see what you mean. But then orangepi zero is a 32-bit device, so the developer might have thought that it would be obvious that a dtsi in arm64 directory will not be applicable to the same.

[jokakilla]

Tried https://rpmbuild.pixeldrift.net/armbian/orangepi/zero3/pr_testing/PR6106_20231229_b1fb0d159_Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.7.0-rc7.tar.xz on my 4GB zero3 and so far for my purposes (headless little server running some docker containers using a zigbee usb stick) all seems pretty nice.

Zigbee2Mqtt running in docker container with Zigbee USB stick and Unifi Network server running on it several hours without issue. Rebooting is working fine, network is coming up again.

 

Network seems to be stable for me (some retransmission that are gone when I limit the bandwidth a little)

Zitat

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.07 GBytes   918 Mbits/sec  148             sender
[  5]   0.00-10.00  sec  1.07 GBytes   916 Mbits/sec                  receiver

 

Unfortunately can't test HDMI stuff as I missed to order a micro HDMi to HDMI adapter🫣

[jiggle24]

Hi, first off thank you so much for contributing your skills and time into this hardware! This is my first SBC (OPi zero3) and really I'm just beginning to learn about linux/armbian systems. I am just a guy who bought a small computer with little knowledge.

 

I built armbian from github repo using current 6.6.8 kernel with xfce desktop this morning and have been exploring. I found that wifi is working well, hdmi output is fine with no glitches like mentioned earlier (up to 1080p 100fps). I  connected a bluetooth DAC/amplifier with no issue as well. CPUfreq in config seems to not work like mentioned still. Big issue is that ethernet does not seem to be working correctly for my image. DHCP assigns address and I seem to be able to ping but i cannot interact with even local network. I have used the official images and the port didn't seem to be defective.

 

honestly when building the image, I didn't really know what I was doing - just following some tutorials - so I'm not sure if this ethernet issue is from my own error. I will build again with more consideration and figure out how to log more information and also see if it is resolved. But right now I am typing this from the orangepi zero3 THANKS and HNY!

 

[fizban]

@pixdrift I tested your latest desktop image (PR6116_20231230) on my OPIZ3 4GB and it seems to freeze at "Begin: Running /scripts/init-premount ... (initramfs)" the serial console stayed at "Starting kernel...". I was not able to go pass that point. The previous image (PR6106_20231229) did not had that problem, although it did have the half screen issue that this image was fixing...

 

Anyway, second time I flashed the same image, it worked fine. I do not know what could have happen the first time...

 

HNY as well!

Edited December 31, 2023 by fizban

[Gunjan Gupta]

1 hour ago, jiggle24 said:

DHCP assigns address and I seem to be able to ping but i cannot interact with even local network. I have used the official images and the port didn't seem to be defective.

Interact how? you are trying to ssh or something? If ping works, I fail to see why other things won't 

[Sean Perez]

Kinda a long one ... but it's been like 1 week trying to get u-boot and all this stuff correct on my own not specific to armbian. But, been searching all over for all sorts of things, made comments on the uboot/uboot github etc.. I'm learning this whole linux uboot etc... maybe this might be useful, any input or corrections etc let me know.

The uboot/uboot github you got to pay attention to the branches...
The orangepi_zero3 is almost identical to the orangepi_zero2w. but in no way is the orangepi_zero2 and zero2w compatible don't even bother looking at that, except for maybe the the eth phy , but since the 2w doesn't have that, I don't see a chip in docs, or on the board (maybe on the expansion board but I don't have one, those docs, same don't really show anything unless its built into the rj45 board connector or just uses the SoC). The zero3 does have a `motorcomm=y` the chip (10/100/1000) that is in the defconfig from uboot/uboot.. the zero2 has some `rtl8211f=y` in the defconfig, that might be the only thing (maybe) that the zero2 and zero2w might have in common.

So the DDR4 if you look at the schematics side by side orangepi_zero3 and 2w they are the same (not just ddr4 but everything - the eth ic). the PMIC are the same and the busses and voltages are all the same ( one of them the schematic shows extra capacitors but the voltage / "bus" address all the same)

The WiFi chip is the same power / pins etc, I saw someone mentioned the WiFi no working but on the official (beta build 6.1 debian) I've had no issues with it (haven't benched marked it or anything), on the older debian it gave me issues, like on first boot I could get my apt updates, after that restart it wouldn't connect, but it would after a second reboot... ( not sure I remember some of those helium miners I messed around with had issues like that, and a lot of the time it was the 2.4ghz and 5ghz home routers, would have the same SSID name and for whatever reason some of those drivers / chips would get stumped on that).

As I was looking around I finally stumbled on the "next" branch in the the `1.`orangepi-build github directory, and that things been getting updates like every week and is like a year ahead of the master branch. There are no instructions there... But for the past 10 hours I been going threw it and banging out the headaches of figuring it out... but its kind of different and I'm just learning what all this different parts of uboot / linux build are structured.

ref `1.` : https://github.com/orangepi-xunlong/orangepi-build/tree/next

This seems to be the files you might need to compare here with what you got ( just referencing the wifi area since I noticed that was an issue a lot of people were having)

zero2w
https://github.com/orangepi-xunlong/orangepi-build/blob/next/external/packages/pack-uboot/sun50iw9/bin/dts/orangepizero2w-u-boot-current.dts#L2707

zero3 - should be same note the difference in line number...
https://github.com/orangepi-xunlong/orangepi-build/blob/next/external/packages/pack-uboot/sun50iw9/bin/dts/orangepizero3-u-boot-current.dts#L2688

Some other files here that have settings, other board in the parent folder...
https://github.com/orangepi-xunlong/orangepi-build/blob/next/external/packages/pack-uboot/sun50iw9/bin/sys_config/sys_config_orangepizero2w.fex

 

But also in the above files notice the HDMI ( someone was saying something about that)
I had an issue with an armbian I downloaded 2-3 of the community versions for the 2w and it kinda worked... but I had issues with the HDMI with a DVI converter, I could see stuff it was just all glitching out, and would stall out on me. I tried it with just plugging it in HDMI to the TV HDMI (no dvi adapter + 1080) and it wasn't glitching out, I think the GNOME and the video drivers crash it im guessing, I did try to install GNOME on the official working xfce debian "beta" 6.1 and it was lagging hard, I tried to figure out wayland but leaving that for after I build this kernel to have "full control" of my debuging etc.. The orange pi beta 6.1 debian worked fine with the HDMI to DVI at any res, and the 6.1 mainline kernel I think already has the support for the Mali gpu, ( I still had to build it, with mesa etc for getting gstreamer ffmpeg codecs etc... I built that like 3 different ways... via the debian-mali method, with the ARM docs method, and random stuff I first found.  As I've been going through the orangepi-build files / build I'm pretty sure there was a setting / option already set for PanfrostLima ...

debian-mali
https://wiki.debian.org/PanfrostLima#Hardware_support

Mesa-mali
https://docs.mesa3d.org/drivers/panfrost.html

ARM-mali
https://developer.arm.com/downloads/-/mali-drivers/bifrost-kernel

But if you go into the orangepi-build/external/ you'll find all the things I mentioned above, and how I have been confirming all my random configs I been hacking together over the week. That repo is actually very well organized vs the other things I been going through, just files seem to have different names, and/or are structured more for whiptail style config / build system (actually really nice once you figure out how to get it to run (I even made / currently debuging a windows 11 Dockerfile that lets me use build on windows using linux docker, with the whole 'docker in docker' method).

So you might not find like a defconfig (I'm not sure how armbian does this), but all the settings are there, even if they are mixed into a file that just builds those files out... but its actually convenient because you see the orangepi_zero3 and zero2w on the same page or directory without 10000 files in it, separated by whatever if statement / setting that is different. for example

https://github.com/orangepi-xunlong/orangepi-build/blob/next/external/config/sources/families/include/sunxi64_common.inc#L69

https://github.com/orangepi-xunlong/orangepi-build/blob/next/external/config/sources/families/sun50iw9.conf#L118

Like it all works, I'm just in that stage of trying to update it to newer mainline kernels, fixing w.e errors pop up on my windows docker build attempt... but if your happy with what they got already there 6.1 and 5.4... and the ./build.sh just runs a menu config, that lets you build each part separate , uboot / kernel / fs .. and it has option for updating the kernel through the standard  menuconfig.

Preset configs that auto load into the menuconfig for orangepi_zero2w /zero3 and be completely adjusted from the whiptail menu...
ref: - check parent folder for the other models
https://github.com/orangepi-xunlong/orangepi-build/blob/next/external/config/kernel/linux-6.1-sun50iw9-next.config

So there are no instructions for that thing but this is what I was able to do, but then ran into, and still debugging some stuff (just for my windows docker container)

1. `git clone https://github.com/orangepi-xunlong/orangepi-build.git`
2. `cd ./orangepi-build`
3. `sudo chmod +x build.sh` (if necessary)
4. `./build.sh`
- Note the build process makes a docker image and downloads all the build dependencies, so you shouldn't need to. But if you are building on x86_64 linux it has some function in there that will throw an error `You are running on an unsupported system [ bookworm<distro> ]` , the function that causes this has a note 'Ubuntu 21.04.x (Hirsute) x86_64 is the only fully supported host OS release', but you can use this ENV / VAR in the console or maybe the ./build <arg> `export NO_HOST_RELEASE_CHECK=yes`, which will bypass that, but with no gaurentee if it will work.
5. from the whiptail menu pick what you want to build uboot, kernel, fs, etc..
- Note that once you go into that option, its going to build the option at the end, it does not go back to the main menu for you to pick the next build option, it builds 1 at a time, then at the end theres another option to put it together, ( this is where you can either switch to armbian or w.e @least you hopefully* got a working u-boot)
- Note when you are going through each step of the build option you made it will give you a list, to pick which board -> the ram -> what branch you want to use "master" or "next", next is like 1 year ahead of master, especially for orangepi_zero2w / orangepi_zero3

Thats pretty much it you just repeat step 5 untill you build everything you want, then combine it with armbian, or w.e ( havent ever built a U-boot before), but it spits each step out to some output folder in that orangepi-build directory, if it works then just go copy the settings and update the armbian repo or w.e

I know it was alot, but I got alot of info from this forum, and others so I figure I post where I'm at , where I Noticed an active thread dealing with this. Again I've never built U-boot before but I'm sure alot of us haven't so to save someone from 1-2 weeks of reading 5 year old post and what not thats what I've gathered.
Happy Newyears eve ... dunno if im going to finish this build for a day or 2

Edited December 31, 2023 by Sean Perez

[pixdrift]

Welcome to the forum @jokakilla, @jiggle24, and @Sean Perez and Happy NY!

 

@jokakilla thanks for this feedback, it's great information and how I generally use my SBCs too (small servers with no X windows). Great to hear it's been stable for you.. one thing I haven't done much of is run images for much longer than testing components work, so this is good information

@jiggle24, great work getting you own image built if you're new to all this!. Are you able to provide some more details on which github repository you built from specifically? (ie. repository and commit id), this is interesting feedback about the NIC, I haven't seen any issues with the NIC myself except for the initial issue with speed which I thought was resolved with a patch, so if you can let us know the specifics and perhaps provide a reproducer (steps to reproduce) it would help. Also, try with different cable + network configuration perhaps to rule out hardware issues unrelated to the SBC? Are you able to test the network with the PR6116 build I posted from @Gunjan Gupta and see if it has the same network issue?
https://armdev.pixeldrift.net/orangepi/zero3/pr_testing/PR6116_20231230_8504bd650_Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.7.0-rc7_xfce_desktop.tar.xz

 

@fizban thanks for that feedback. It does sound like a bad write to the SD card, and glad to hear a re-image of the card resolved it. I use a few different methods to write my images, but have ended up using balenaEtcher as my primary tool now as it also verifies the image after writing. Great to hear you got it working, and let us know if you come across any other issues.

Hi @Sean Perez, thanks for the long post. @Gunjan Gupta are across all these sources and the requirements and differences to build zero2, zero3 and zero2w. This thread is more around Armbian specifics than just getting a working image, ie. the xunlog images exist, but this thread is about building working Aembian images and testing these images specifically. This includes merging the configuration from multiple different sources (patches, other repositories, and work from various communities) into Armbian so it works correctly for all the H61* boards as well. @Gunjan Gupta did some earlier work to get the zero2w working in Armbian and that is available in his branch here and may provide some additional insight:
https://github.com/viraniac/armbian_build/tree/zero2w

This is the work I am discussing merging, as it's known working with Armbian, and the H618 is shared by the zero3 and the pattern used for zero2/zero3 @Gunjan Gupta has used reduces the rework for some of the shared components and will benefit the Armbian project when more H618 boards come onto the market as @Gunjan Gupta has mentioned.

I assume from your post you have a zero2w? One of the challenges we have had is that no one has had zero2w hardware to test, but I bought one over the break (with an expansion board) so will look at it more closely now I can actually test the images. My zero2w is still sealed as I have been keen to work through zero2 and zero3 issues while @Gunjan Gupta is merging. We may need a new thread for zero2w board specifically.

Edited February 2 by pixdrift

[pixdrift]

15 hours ago, johndo100 said:

I've just install latest build from https://github.com/viraniac/armbian_build.

I'm using server version and it works so far.

I'll test the xfce version in the next day.

Welcome to the forum @johndo100, sorry I missed this post.

Which board and configuration are you using? If it's a Zero2 or Zero3, you will now be able to use the main Armbian repository as @Gunjan Gupta's latest changes (viraniac repository) have been merged.

[pixdrift]

10 hours ago, Gunjan Gupta said:

There are still glitches? Can you tell me the steps to reproduce the same? I will try it on my zero3

 

@Gunjan Gupta There are minor glitches that I would characterise as artefacting. It isn't hard to reproduce, I could see it when XFCE first launched and when I select the drop down menu and open a terminal, I get glitching around where the terminal window draws. It is like a 'flash' of different bits and pieces of window components etc. in the middle of the screen, almost like video RAM isn't refreshed before being drawn or something.

I have only tested this on the Zero2, I can do a comparison with the Zero3 XFCE PR6116 image here and confirm it's not anything to do with hardware.

I would still be interested if you could test it on your Zero2, because it may just be a hardware issue with my device?

[jokakilla]

Glad to hear that my feedback was useful. Let me know if there is anything certainly interesting I could test. I'll maybe play around with more network stuff like vlan (docker ipvlan) but not sure If this is something where you would expect to see issues.

 

So thanks again for all your effort and happy new year to all of you.

[johndo100]

8 hours ago, pixdrift said:

Which board and configuration are you using? If it's a Zero2 or Zero3, you will now be able to use the main Armbian repository as @Gunjan Gupta's latest changes (viraniac repository) have been merged.

I'm using Orange Pi Zero 3 1GB.

XFCE version works just fine. There are some glitches as you stated before, it happened to mouse cursor.

Video test

 

Edited January 1 by johndo100

[Gunjan Gupta]

12 hours ago, pixdrift said:

I would still be interested if you could test it on your Zero2, because it may just be a hardware issue with my device?

I don't have a zero2. I only bought a zero3

[fizban]

@pixdrift Actually I also use Balena Etcher and the validation was also successful. The only thing I can think of is that currently I do not have access to my main monitor and I can only use a mini-touchscreen (7 Inch 1024*600), so the first time I tried to boot, since nothing was shown on the monitor I just switched off the orange pi. But sometimes the monitor does not switch on automatically and it has to be switched on with a button, and maybe there was actually something being displayed on it. The second time the monitor showed the initramfs message and stayed there forever. Subsequent reboots showed the same behaviour. Anyway, as I said, after reimaging the card, the first boot went well. Since I do not have currently access to the monitor that had problems with HDMI synchronization, I cannot verify if the new image has also that problem. 

 

Regarding additional things in the new image (PR6116_20231230) I did the VLC test to check video hardware acceleration and unfortunately the new image shows much worse performance, with more than 20% frames lost, with videos that previously had 0 lost frames (image Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.6.7.bt.fixed.tar). I did not test vlc with the  previous image (PR6106_2023122), the one with the video glitch, but it was clear that having to set the scale to something different to 1x really took a toll on the graphics performance. I did not change the scale on the lastest image (PR6116_20231230), remaining at 1x, but still, as I said, the test with vlc indicates problems using the HW acceleration (comparison was done setting output to OpenGL for embedded systems, but other options did not show any improvement)

[Gunjan Gupta]

fizban, I haven't tried HW acceleration on allwinner boards, but generally you will need specially patched libraries that can support v4l2 request api for it to work. Armbian doesn't ship them by default

[pixdrift]

@Gunjan Gupta I think what is significant about the feedback from @fizban is that they are comparing the build from my opizero3 branch, to the mainline PR6116 build and seeing a difference.

The BT fixed image that @fizban is referring to is built from here
https://github.com/pixdrift/armbian_build/tree/zero3

I would expect the patches to provide similar outcomes (as I think they are essentially the same patches?).

 

Regarding CPU Frequency on the zero3, I am more convinced the code that branches based on H616/H618 I mentioned earlier in the thread is causing the issues.
 

This change here in the warpme repo changes the zero3 compatibility configuration to 616 from 618 in the CPU frequency patch. I am not sure if this is the best approach (I think I prefer to add logic for 618 to the CPU Frequency code, or change the logic slightly), but it means the CPU Frequency code works without modification for the zero3 as it changes the code path if it's 616 to essentially work like the zero2. (my theory) 

 

-       compatible = "xunlong,orangepi-zero3", "allwinner,sun50i-h618";
+       compatible = "xunlong,orangepi-zero3", "allwinner,sun50i-h616";

https://github.com/warpme/minimyth2/blob/67c1dec6e93743c8f4de1d5299d06f4036a8ea2b/script/kernel/linux-6.6/files/0631-arm64-dts-allwinner-h616-OrangePI-Zero23-enable-ths-hdmi-audio.patch#L215-L216

Edited January 1 by pixdrift

[Gunjan Gupta]

21 minutes ago, pixdrift said:

This change here in the warpme repo changes the zero3 compatibility configuration to 616 from 618 in the CPU frequency patch. I am not sure if this is the best approach (I think I prefer to add logic for 618 to the CPU Frequency code, or change the logic slightly), but it means the CPU Frequency code works without modification for the zero3 as it changes the code path if it's 616 to essentially work like the zero2. (my theory) 

Feel free to add a patch and test it out. Its a single line change after all. I won't be working on this for next few days as I am busy with some other things

[pixdrift]

3 minutes ago, Gunjan Gupta said:

26 minutes ago, pixdrift said:

 

Feel free to add a patch and test it out. Its a single line change after all.

Yeah sorry, that was my plan, I was just sharing the theory of why it may not be working based on some investigation.

I am low on time at the moment too, but as you mention, it's a quick one to validate and I will give feedback on results when I have a minute, cheers

[pixdrift]

As suspected the hack to the zero3.dts files fixed CPU Scaling on the zero3. I applied it to your mainline patches @Gunjan Gupta rather than my forked zero3 repo. This basically ensures the CPU scaling code executes because it passes the compatibility check which checks for h6 and h616 (but not h618 currently).
https://github.com/viraniac/armbian_build/compare/main...pixdrift:armbian_build:mainline_cpufreq

This leaves me in a weird spot, there are a few options here. I looked at the code and the h618 compatibility configuration defined in the zero3.dts doesn't appear to be used or referenced anywhere else in the code, so there is no real harm in setting it to h616. That being said, in the future this may change and trip us up.

I can replicate the configuration from h616 in the code for h618, but that feels like unnecessary duplication, so another method would potentially be to redefine the h616 configuration as h61X and reference it for both boards in the CPU Frequency code.

 

So options are:
1. Merge as is with h616 definition in zero3.dts and deal with the consequences when h618 specific code turns up in the kernel
2. Create kernel patch to also add h618 definitions replicating the h616 definitions so both are defined and separate
3. Modify existing kernel patch to change CPU h616 configuration to h61x, and reference that from both h616 and h618 compatible boards

I haven't uploaded any OS images using the above patch, but if people would like it for testing etc. I can upload it, or you can build directly off my mainline_cpufreq branch in my github repository.

 I have checked this fairly thoroughly with some background load tests and the scaling up/down was all working really well, so whoever wrote the original code should be commended. Here is the output from the board with the above patch applied.
 

  ___  ____  _   _____             _____
 / _ \|  _ \(_) |__  /___ _ __ ___|___ /
| | | | |_) | |   / // _ \ '__/ _ \ |_ \
| |_| |  __/| |  / /|  __/ | | (_) |__) |
 \___/|_|   |_| /____\___|_|  \___/____/

Welcome to Armbian-unofficial 24.2.0-trunk Bookworm with bleeding edge Linux 6.7.0-rc7-edge-sunxi64

No end-user support: built from trunk

System load:   29%           	Up time:       1:46
Memory usage:  5% of 3.84G  	IP:	       XXX.XXX.XXX.XXX
CPU temp:      50°C           	Usage of /:    3% of 58G
RX today:      1.9 MiB

pixdrift@orangepizero3:~$ cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 244 us.
  hardware limits: 480 MHz - 1.51 GHz
  available frequency steps: 480 MHz, 600 MHz, 792 MHz, 1.01 GHz, 1.20 GHz, 1.51 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil
  current policy: frequency should be within 480 MHz and 1.51 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 480 MHz (asserted by call to hardware).
  cpufreq stats: 480 MHz:64.13%, 600 MHz:2.89%, 792 MHz:1.56%, 1.01 GHz:0.00%, 1.20 GHz:0.00%, 1.51 GHz:31.42%  (2650)
analyzing CPU 1:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 244 us.
  hardware limits: 480 MHz - 1.51 GHz
  available frequency steps: 480 MHz, 600 MHz, 792 MHz, 1.01 GHz, 1.20 GHz, 1.51 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil
  current policy: frequency should be within 480 MHz and 1.51 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 480 MHz (asserted by call to hardware).
  cpufreq stats: 480 MHz:64.13%, 600 MHz:2.89%, 792 MHz:1.56%, 1.01 GHz:0.00%, 1.20 GHz:0.00%, 1.51 GHz:31.42%  (2650)
analyzing CPU 2:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 244 us.
  hardware limits: 480 MHz - 1.51 GHz
  available frequency steps: 480 MHz, 600 MHz, 792 MHz, 1.01 GHz, 1.20 GHz, 1.51 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil
  current policy: frequency should be within 480 MHz and 1.51 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 480 MHz (asserted by call to hardware).
  cpufreq stats: 480 MHz:64.13%, 600 MHz:2.89%, 792 MHz:1.56%, 1.01 GHz:0.00%, 1.20 GHz:0.00%, 1.51 GHz:31.42%  (2650)
analyzing CPU 3:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 244 us.
  hardware limits: 480 MHz - 1.51 GHz
  available frequency steps: 480 MHz, 600 MHz, 792 MHz, 1.01 GHz, 1.20 GHz, 1.51 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil
  current policy: frequency should be within 480 MHz and 1.51 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 480 MHz (asserted by call to hardware).
  cpufreq stats: 480 MHz:64.13%, 600 MHz:2.89%, 792 MHz:1.56%, 1.01 GHz:0.00%, 1.20 GHz:0.00%, 1.51 GHz:31.42%  (2650)

 

Edited January 2 by pixdrift

[pixdrift]

I have come up with a cleaner way to patch in CPU Frequency support in for the zero3.

Essentially it adds the h618 device to the compatibility list, then maps the h618 configuration to the same as the h616. This was the least invasive method to get support (two lines changed total in two driver source files)
https://github.com/pixdrift/armbian_build/commit/c9fdd448d729406f651131a428fa0027543a884a

 

I am considering raising a PR back to Armbian mainline for this after I also get a working patch for the 'current' kernel (should be roughly the same). To test this CPU Frequency patch for the zero3, you can build off the mainline_cpufreq_driver branch in my repo here:

https://github.com/pixdrift/armbian_build/tree/mainline_cpufreq_driver

[Gunjan Gupta]

Looks ok, but its just a diff and is not in git format-patch format similar to other patches. Also instead of saying blocklist, it should be something like add h618 to matchlist

 

Use ./compile BOARD=orangepizero3 BRANCH=current kernel-patch to create the patch