Orange Pi Zero 3

[pixdrift]

4 minutes ago, Gunjan Gupta said:

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

Thanks for the feedback @Gunjan Gupta.

The patch was generated by git diff, if it wasn't I don't think the Armbian patching utility would parse it (ie. doesn't support straight diff).

The patch is called blocklist because that is what is being updated/changed, but sure, that can change, it's only a label.

Not following on what the ./compile command is going to do for me? am I providing my patch to it? where am I putting the patch for that command to 'work'? I will take a look when I get some more time, cheers.

[iun cuim]

I also made a manjaro image for zero3 based on the warpme patches.

If anyone wants to compare with armbian and use something for it, there is a link: https://drive.google.com/file/d/10z1Kq6_7NXE4p3n8QfV8MWFcKlicx_9t/view

From the very beginning, many things will not work, you need to update the kernel with the command sudo pacman -U ./linux-blahblah.zst : https://drive.google.com/file/d/1Rv7NS364Pc8ZCgyEuN-nnwuI2lINR5W4/view?usp=sharing

After the update the kernel mostly things works.

For wifi to work, you additionally need to download firmware files.

GTA Vice City (PC version) game video: https://drive.google.com/file/d/10WkmibRqYXEb6IzarZRU6FPXSl8BxT-c/view?usp=drive_link

Edited January 2 by iun cuim

[Gunjan Gupta]

@pixdriftLets just patch dts instead of patching driver. I think that is the better solution

[pixdrift]

8 hours ago, Gunjan Gupta said:

@pixdriftLets just patch dts instead of patching driver. I think that is the better solution

 

Can you provide more specific details on why you believe this is better? is there a policy in Armbian or something I can refer to to determine how it should be handled?

My concern with modifying the .dts is that it feels like a 'step backwards' as we are essentially reverting a change that should be there, where as the change to the driver is moving to a more likely target state for that driver (but I can only speculate). I appreciate the driver is probably more likely to change in mainline, which may deprecate the patch more quickly.

 

Would you be able to give me a run through of your full patch generation workflow for Armbian so I can generate a patch that meets PR requirements (or link to a doc)? Do you checkout the full kernel source and generate the patch there? or do you pull the generated/patched kernel source out of Armbian build into a git repository and then modify and generate from there?

I have my own workflows for these things, but it's a little obtuse when applied to Armbian due to the amount of patching/changes that occur during the build process.

 

My current patch generation workflow for Armbian is to pull resultant files from the build cache (after a build), modify them and generate patches from there using git diff.

[Stephen Graf]

@Gunjan GuptaWould you please fit just one more small patch into some convenient dtsi.

I2c is sort of half baked for i2c3, the only i2c brought out to the external headers. The correct pins are set aside but they are not referenced in the i2c3 definition and without that the port does not work.  I have used armbian-config dtb edit to add the definitions and tested the port and it works.

 

From sun50i-h616.dtsi, one can see the i2c pin definitions:

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

But there is no reference to them in the i2c3 definition:

                i2c3: i2c@5002c00 {
                        compatible = "allwinner,sun50i-h616-i2c",
                                     "allwinner,sun8i-v536-i2c",
                                     "allwinner,sun6i-a31-i2c";
                        reg = <0x05002c00 0x400>;
                        interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
                        clocks = <&ccu CLK_BUS_I2C3>;
                        resets = <&ccu RST_BUS_I2C3>;
                        status = "disabled";
                        #address-cells = <1>;
                        #size-cells = <0>;

 

What needs to be added is :

                i2c3: i2c@5002c00 {
                        compatible = "allwinner,sun50i-h616-i2c",
                                     "allwinner,sun8i-v536-i2c",
                                     "allwinner,sun6i-a31-i2c"; 

                        reg = <0x05002c00 0x400>;
                        interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
                        clocks = <&ccu CLK_BUS_I2C3>;
                        resets = <&ccu RST_BUS_I2C3>;

+                        pinctrl-names = "default";
+                        pinctrl-0 = <&i2c3_pins>;
                        status = "disabled";
                        #address-cells = <1>;
                        #size-cells = <0>;

 

With the current state of patches I am not sure of where to put these two lines.

 

[ALIGMSTEN]

On 1/2/2024 at 9:18 AM, pixdrift said:

whoever wrote the original code should be commended

 

Hello All,

 

Good to see all the progress.

 

I wrote and tested the dvfs code for zero2, however did not have enough time spare to optimize as would have liked.

 

Was a bit surprised that it was also adopted by others including the Vendor.

 

There are two ways to incorporate dvfs, the xlate method which I decided to eventually adapt, and v2 opp points.

 

xlate is as example. v2 you can use in tri-state, which avoids the driver patching.

 

I haven't had interest to examine the h618 soc, however am assuming that variants should be addressed as it is supposed to be h616 similar.

[Gunjan Gupta]

8 minutes ago, ALIGMSTEN said:

I wrote and tested the dvfs code for zero2, however did not have enough time spare to optimize as would have liked.

 

Was a bit surprised that it was also adopted by others including the Vendor.

 

Your patch seems to be base of https://lore.kernel.org/all/20231128005849.19044-1-andre.przywara@arm.com/ as well. Though there is no reference in the patch series that it came from your patch

[ALIGMSTEN]

 

9 minutes ago, Gunjan Gupta said:

Though there is no reference in the patch series that it came from your patch

 

Oh well it was open source, would have liked to have had some discussions at the time to optimise though!

[pixdrift]

Just a note for anyone that was using my armbian repository, I have re-created it to re-establish the fork relationship with the mainline armbian project, as it was becoming difficult to track changes derived off @Gunjan Gupta's repo (ie. I was two steps away). Apologies if this causes any issues, I am hoping now I will have some consistency and can better contribute to the mainline project.

[pixdrift]

For those that may just be following this thread and not the GitHub repository, my changes for CPU Frequency on the zero3 were merged into the main Armbian Build repository last night, so rebuilding from armbian/build:main will add working CPU Frequency on zero3  I will build images at this PR for people to use (will let you know when they are up).

https://github.com/armbian/build/pull/6127

 

I will take a look at the I2C issue you've raised next @Stephen Graf as it looks like a fairly quick fix.

[ag123]

I made some progress to run armbian build *compile.sh* in a systemd-nspawn container

https://gist.github.com/ag88/05245121cce37cb8f029424a20752e35

 

It did create the loop devices in systemd-nspawn, but it still fail subsequently in accessing the partitions in the loop device.

--

I'd try out the test binaries from @pixdrift for the time being

 

[pixdrift]

The latest mainline builds after PR6127 merge are up, CLI only, if people want XFCE please let me know. This fixes CPU frequency scaling on the Zero3.

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

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

Edited February 2 by pixdrift

[ag123]

 

@pixdrift thanks,

I tried

PR6127_20240103_919ec9a62_Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.7.0-rc7.tar.xz from 2024-01-04

on a 2GB OrangePi Zero 3 board

cpufreq-info works, thanks for the dts patches:

armbian@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:85.58%, 600 MHz:1.60%, 792 MHz:0.08%, 1.01 GHz:0.26%, 1.20 GHz:0.22%, 1.51 GHz:12.26%  (173)
analyzing CPU 1:
  ...
armbian@orangepizero3:~$ armbianmonitor -m
Stop monitoring using [ctrl]-[c]
Time        CPU    load %cpu %sys %usr %nice %io %irq   Tcpu  C.St.

18:13:16  1512 MHz  1.08   5%   1%   2%   0%   1%   0%  41.3 °C  0/5
18:13:21   480 MHz  1.08   0%   0%   0%   0%   0%   0%  41.3 °C  0/5
18:13:26   480 MHz  1.07   0%   0%   0%   0%   0%   0%  40.9 °C  0/5

 

other stuff looks good

the login:
  ___  ____  _   _____             _____ 
 / _ \|  _ \(_) |__  /___ _ __ ___|___ / 
| | | | |_) | |   / // _ \ '__/ _ \ |_ \ 
| |_| |  __/| |  / /|  __/ | | (_) |__) |
 \___/|_|   |_| /____\___|_|  \___/____/ 
                                         
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:   26%              Up time:       3 min
Memory usage:  7% of 1.94G      IP:            192.168.1.173
CPU temp:      37°C             Usage of /:    7% of 29G    
RX today:      72.6 MiB 

armbian@orangepizero3:~$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: end0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 02:00:6c:53:f7:f9 brd ff:ff:ff:ff:ff:ff
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state DORMANT mode DORMANT group default qlen 1000
    link/ether 80:a0:53:73:a3:89 brd ff:ff:ff:ff:ff:ff

 

Ethernet / Wifi works as prior, only tested in console (e.g. serial) as well as ssh over ethernet.

[pixdrift]

On 1/3/2024 at 2:44 PM, Stephen Graf said:

With the current state of patches I am not sure of where to put these two lines.

Hi @Stephen Graf, sorry for the slow follow up.

In the edge kernel, I found that this patch appears to add the i2c3 configuration for h6:

arm64-dts-allwinner-h6-Add-AC200-EPHY-nodes.patch
 

It adds it to the following h6 dtsi
/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
 

But the h616 and h618 boards don't inherit this h6 dtsi.. it looks like the configuration is set for the zero3 in the sun50i-h616.dtsi include file here:
/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
 

Here is a rough diagram I put in Graphviz, sorry for the size:
 

That block in /arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi looks like the following post patching
 

                i2c3: i2c@5002c00 {
                        compatible = "allwinner,sun50i-h616-i2c",
                                     "allwinner,sun8i-v536-i2c",
                                     "allwinner,sun6i-a31-i2c";
                        reg = <0x05002c00 0x400>;
                        interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
                        clocks = <&ccu CLK_BUS_I2C3>;
                        resets = <&ccu RST_BUS_I2C3>;
                        status = "disabled";
                        #address-cells = <1>;
                        #size-cells = <0>;
                };

 

I will write a quick patch for you, and we can see if that fixes it, then I can figure out how to graft it in more formally once you've tested it .

@Stephen Graf looking at your code block, the reference should be 'i2c3_ph_pins', not 'i2c3_pins' as 'i2c3_pins' isn't defined in the h616.dtsi, can you confirm tha makes sense and it was a typo? I notice the h6 dtsi doesn't have 'ph' in the name.

Edited January 4 by pixdrift

[pixdrift]

@Stephen Graf this has what I think should fix it, please build using edge and let me know
https://github.com/pixdrift/armbian_build/tree/zero3_i2c3

 

I decided to try and patch the zero3 dts to avoid potential impacts to other boards (for now), the patch file can be found in the repo under the zero3_i2c3 branch.
arm64-dts-sun50i-h618-orangepi-zero3-Enable-i2c3

-edit-

It compiled cleanly, there is a test build here if you want to use that:
https://armdev.pixeldrift.net/orangepi/zero3/Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.7.0-rc7.i2c3.test.tar.xz

Edited February 2 by pixdrift

[Stephen Graf]

@pixdrift said looking at your code block, the reference should be 'i2c3_ph_pins', not 'i2c3_pins' as 'i2c3_pins' isn't defined in the h616.dtsi, can you confirm tha makes sense and it was a typo? I notice the h6 dtsi doesn't have 'ph' in the name.

 

Yes it was a typo. Your patch should be correct. I would expect the zero2 would benefit with the same change. I will try to build and retest.

[pixdrift]

4 hours ago, Stephen Graf said:

I would expect the zero2 would benefit with the same change. I will try to build and retest.

 

That's sounds good, I think the challenge is going to be getting the zero2 changes validated.

That being said, as I am not too familiar with i2c because I use these boards primarily as servers for varying purposes, would you be able to recommend some tests I could do to validate the i2c changes myself (and other GPIO tests you are doing). I am looking for both hardware and software (code sample) recommendations for the testing. Happy to buy hardware components so I can validate these changes too.

 

I have posted a link to a build with the i2c3 changes above for the orangepizero3 to avoid you needing to rebuild, but all good if you want to build it

[Stephen Graf]

I just finished testing with the build you supplied and it worked as expected.  I have a temperature & pressure sensor on an 12c device that I connect to the zero3 header and then read it with rust code.

There are i2c tools installed on the image that you can use to interrogate the i2c system:

 

root@orangepizero3:~# i2cdetect -l
i2c-0   i2c             mv64xxx_i2c adapter                     I2C adapter
i2c-1   i2c             DesignWare HDMI                         I2C adapter
i2c-2   i2c             mv64xxx_i2c adapter                     I2C adapter
root@orangepizero3:~# i2cdetect 2
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-2.
I will probe address range 0x08-0x77.
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- 38 -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
root@orangepizero3:~#

 

I think there are 2 i2c systems used internally by the zero3.  The i2c3 that we are working on became i2c-2 as enumerated by linux. My device shows up as address 38 on the scan.

 

Thank you for your work adding the patch.

[Stephen Graf]

@pixdrift On the i2c patch you enabled the device in the dts.

 

Normally these devices are left disabled and I use armbian-config, system, hardware to enable the devices I require. However, this menu option is currently not working on my zero3. It just comes up with a blank list.  Can you try it on a zero2?

[pixdrift]

51 minutes ago, Stephen Graf said:

@pixdrift On the i2c patch you enabled the device in the dts.

 

My understanding is that this just includes it in the kernel device tree, but I may be wrong, I am fairly new to this.

It would be quick to fork my repo, change the patch file to remove the status=okay, or just replace it was status=disabled and rebuild and see if that resolves your issue?

I can take a look on zero2, but as I mentioned, I would need hardware to test no? otherwise I should be expecting a blank list

[aleda]

will this work for the opi2w 4gb?

[Stephen Graf]

The patch for i2c3 is fine.  There is no need to change anything, although the armbian developers might want to leave i2c3 disabled.

 

The armbian-config issue is a separate item. I just want you to look at the system-hardware item in armbian-config to see it there are any items listed.  My zero3 list if blank. The armbian-config is a utility for a number of things and one is to enable and disable hardware items. 

 

 

root@orangepizero3:~# armbian-config

then System

then Hardware

 

 

On the Zunlong image all the devices, spi, 12c, serial etc are listed as they should be, even when they are disabled in the dtb.  I suspect armbian-config does not know about H618 and is not reading the dtb. The dtb for zero3 in Zunlong is labeled with H616!?

[Gunjan Gupta]

Its possible armbian-config might be looking for files starting with sun50i-h618 as that is the compatible string in zero3.dts. Try adding symlinks or renaming h616 overlay files present in /boot/dtb/overlay and see if armbian-config starts listing those files

[Stephen Graf]

The overlay_prefix in armbianEnv.txt is not defined so I added overlay_prefix=sun50i-h616. Then I get:

 

 

I was hoping that i2c3 would be there, but only the following exist. Who decides what goes into the overlays?

 

root@orangepizero3:/boot# ls -al dtb-6.7.0-rc7-edge-sunxi64/allwinner/overlay/sun50i-h616*
-rwxr-xr-x 1 root root 4203 Jan  4 13:23 dtb-6.7.0-rc7-edge-sunxi64/allwinner/overlay/sun50i-h616-fixup.scr
-rwxr-xr-x 1 root root  268 Jan  4 13:23 dtb-6.7.0-rc7-edge-sunxi64/allwinner/overlay/sun50i-h616-ir.dtbo
-rwxr-xr-x 1 root root  512 Jan  4 13:23 dtb-6.7.0-rc7-edge-sunxi64/allwinner/overlay/sun50i-h616-light.dtbo
-rwxr-xr-x 1 root root  339 Jan  4 13:23 dtb-6.7.0-rc7-edge-sunxi64/allwinner/overlay/sun50i-h616-mcp2515.dtbo
-rwxr-xr-x 1 root root  661 Jan  4 13:23 dtb-6.7.0-rc7-edge-sunxi64/allwinner/overlay/sun50i-h616-spidev0_0.dtbo
-rwxr-xr-x 1 root root  661 Jan  4 13:23 dtb-6.7.0-rc7-edge-sunxi64/allwinner/overlay/sun50i-h616-spidev1_0.dtbo
-rwxr-xr-x 1 root root  661 Jan  4 13:23 dtb-6.7.0-rc7-edge-sunxi64/allwinner/overlay/sun50i-h616-spidev1_1.dtbo
-rwxr-xr-x 1 root root  661 Jan  4 13:23 dtb-6.7.0-rc7-edge-sunxi64/allwinner/overlay/sun50i-h616-spidev1_2.dtbo
-rwxr-xr-x 1 root root  808 Jan  4 13:23 dtb-6.7.0-rc7-edge-sunxi64/allwinner/overlay/sun50i-h616-spi-spidev.dtbo
-rwxr-xr-x 1 root root  616 Jan  4 13:23 dtb-6.7.0-rc7-edge-sunxi64/allwinner/overlay/sun50i-h616-tft35_spi.dtbo
-rwxr-xr-x 1 root root  272 Jan  4 13:23 dtb-6.7.0-rc7-edge-sunxi64/allwinner/overlay/sun50i-h616-ws2812.dtbo

 

 

 

 

 

 

 

[pixdrift]

7 minutes ago, Stephen Graf said:

The overlay_prefix in armbianEnv.txt is not defined so I added overlay_prefix=sun50i-h616.

 

Thanks for this clarification @Stephen Graf, once again this is something I haven't seen before being new to Armbian.

 

This raises an interesting point because there is going to be crossover here, so anything that is shared between 616/618 should probably be 616, and then specific 618 configuration with 618.. so the prefix could technically be 'overlay_prefix=sun50i-h61'.. but this doesn't accomodate configuration that is in h616 that may be dropped from h618. Should we just replicate everything into a new set of files for h618?

Is everything listed for h616 there valid h618?

How is ArmbianEnv.txt generated? I am happy to add a patch to fix this for zero3 so at least we're getting some kind of menu out of the box.

[pixdrift]

5 hours ago, aleda said:

will this work for the opi2w 4gb?

 

Hi @aleda, welcome to the forum.

 

Not yet, we haven't started discussing/targeting the zero2w in this thread yet, although a lot of the work being done here for zero2 and zero3 will benefit the zero2w and likely make the process of adding the zero2w straightforward.

I have recently purchased a zero2w myself, so it's good to know there are other people in this thread potentially available for testing if/when we do add the board.

@Gunjan Gupta did some work in his own branch to test/validate the zero2w, you could potentially build off this branch while you wait, but this isn't supported in any way.
https://github.com/viraniac/armbian_build/tree/zero2w

Edited January 5 by pixdrift

[Gunjan Gupta]

6 minutes ago, pixdrift said:

How is ArmbianEnv.txt generated?

Its generated based on the options specified in the board config file. You can add OVERLAY_PREFIX=sun50i-h616 in orangepizero3.conf and that should get replicated in armbianEnv.txt in your next build

[Gunjan Gupta]

As h616 and h618 are suppose to be pin compatible, same overlays should work between the same

[pixdrift]

Interested in some feedback here.

As the i2c3 component is confirmed working, and it's the same for all h616, I was considering adding the following lines to the sun50i-h616.dtsi

pinctrl-names = "default";

pinctrl-0 = <&i2c3_ph_pins>;

 

...and then for zero2 and zero3 (or using the zero dtsi) just enabling the i2c3 components with status = "okay" at the board level

But I have a concern that there are several boards including the sun50i-h616.dtsi file, and not sure if this change is going to impact these boards.

 

So interested in feedback.. perhaps @Gunjan Gupta you can advise on what level (file) I should add these two lines?, then I will update the patch before the PR.

pinctrl-names = "default";

pinctrl-0 = <&i2c3_ph_pins>;

Edited January 5 by pixdrift

[pixdrift]

4 hours ago, Gunjan Gupta said:

Its generated based on the options specified in the board config file. You can add OVERLAY_PREFIX=sun50i-h616 in orangepizero3.conf and that should get replicated in armbianEnv.txt in your next build

I notice that the orangepizero2.conf file doesn't include OVERLAY_PREFIX, is this because the board defined in the dts/dtb already correctly matches so doesn't need explicit overwrite?