Jump to content

H616 mainlining effort

mcerveny

By mcerveny
in Orange Pi Zero 2

 Share

Recommended Posts

mcerveny

mcerveny

Posted
Posted (edited)

Hello.

I see some progress in H616 (OPIZ2) support in mainline linux (now 6.2RC5 comes with USB) - https://linux-sunxi.org/Linux_mainlining_effort .
I tried to setup/enable some other components and I am successful with upstream linux kernel 6.2RC5:
- displayengine (drm, fb, mixer, tcon, hdmi) (seems to have some I2C/EDID problems)
- videoengine (cedrus) (in testing now)
- gpu (3d mali, panfrost)
- dma, efuse, thermal ...
but I am unsuccessful with
- crypto (total different behavior in contrast to H616 manual)
and untested
- audio codecs and hdmi audio
- opp power management (frequency + voltage) for CPU and GPU
- SDIO wifi 

I was also successful with uBoot (some patches from upstream uBoot) to boot sdcard-less from SPI flash and then from network PXE+NFS.

Does anyone do some work in this direction ?
 

image.png

Edited by mcerveny
add url
1
ALIGMSTEN

ALIGMSTEN

Posted
Posted (edited)

Nice, looks like you standing up on Orangepi there?

 

  On 1/27/2023 at 8:03 PM, mcerveny said:

Does anyone do some work in this direction ?

Expand  

 

Interesting, I've been working low down your list, testing cpu-frequency-scaling for a while, which I think now will submit PR to 5.19 for others to try. The patch addresses all variants, but is not optimized, limited to 1512 Mhz, still WIP is the frequency calc's and micro-volt testing.

 

All that you list has been in progress for a while, but has not seen the light here for lack of someone knowledgeable having time or perhaps interest, and that it seems there are still issues to be worked out in some parts.

 

@going is doing an incredible job at maintaining sunxi here for us to develop off.

Edited by ALIGMSTEN
Forgot to say!!
0
going

going

Posted
Posted
  On 1/27/2023 at 8:03 PM, mcerveny said:

crypto (total different behavior in contrast to H616 manual)

Expand  

Unfortunately, this is not the only discrepancy.

 

  On 1/27/2023 at 8:03 PM, mcerveny said:

Does anyone do some work in this direction ?

Expand  

I'm doing a little work, but it's about supporting a series of patches.

Which are applied using the function lib/functions/compilation/patch/patching.sh.

The day after the origin/linux-6.1.y branch appeared in linux-stable.git I extract from this repository

branch origin/orange-pi-6.1 all the commits that were applied from above. And it becomes a series of megous patches.

A series of armbian patches are those patches that one of the users once suggested for use.

I am not able to check all of them and the correctness of their work after applying them.

All I do is monitor their correct application when moving the kernel code upstream.

And I fix compilation errors if they occur.
@Igor also makes a huge contribution to this process.

We hope for your contribution to the development.

 

1
ALIGMSTEN

ALIGMSTEN

Posted
Posted

If you addressing me and above patch @mcerveny I'm happy to play here, its not serious.

 

I cant speak for mainline process.

 

In similar vein could quite happily carry on and not 'contribute' getting the 'stuffs' I need working and abuse. However I am completely against that type of behavior, and why I choose to donate and contribute.

0
mcerveny

mcerveny

Posted
  • Author
Posted
  On 1/29/2023 at 3:08 PM, ALIGMSTEN said:

Hi nope, fun in spare time approach here, arm64-dts-allwinner-h616-Add-efuse_xlate-cpufreq.patch.

Expand  

I tested with kernel 6.2RC4 (some driver code change needed), notes:

  • do not increase GPU voltage 
                 reg_dcdcc: dcdcc {
                 regulator-always-on;
                 regulator-min-microvolt = <810000>;
-                regulator-max-microvolt = <1080000>;
+                regulator-max-microvolt = <1100000>;
                 regulator-name = "vdd-gpu-sys";
             };
    absolute maximum (from H616_Datasheet_V1.0_cleaned.pdf):
    image.thumb.png.dce411d5e702a2f13d0b2b91c9a6adfd.png
    recommended (from H616_Datasheet_V1.0_cleaned.pdf):
    image.thumb.png.0beb29e4d7092146ddc3b5cfa73d9c60.png
    my sun50i-h616-orangepi-zero2.dts: 
    reg_dcdcc: dcdcc {
regulator-always-on;
regulator-min-microvolt = <810000>;
regulator-max-microvolt = <990000>;
regulator-name = "vdd-gpu-sys";
};

     

  • I also reworked temperature - cooling
    my sun50i-h616.dtsi: 
    		cpu_thermal: cpu-thermal {
			polling-delay-passive = <500>;
			polling-delay = <1000>;
			thermal-sensors = <&ths 2>;

			trips {
				cpu_target: cpu-target {
					temperature = <75000>;
					hysteresis = <2000>;
					type = "passive";
				};

				critical {
					temperature = <105000>;
					hysteresis = <2000>;
					type = "critical";
				};
			};

			cooling-maps {
				map0 {
					trip = <&cpu_target>;
					cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
						<&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
						<&cpu2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
						<&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
				};
			};
		};

    my sun50i-h616-orangepi-zero2.dts:
      

    &cpu_thermal {
	/delete-node/ trips; 
	// beaware, all points must have different names otherwise dts compiller does not hold position and driver stuck in differnt trip point
	trips {
		cpu_warm: cpu_warm {
			temperature = <75000>;
			hysteresis = <2000>;
			type = "passive";
		};

		cpu_hot_pre: cpu_hot_pre {
			temperature = <80000>;
			hysteresis = <2000>;
			type = "passive";
		};

		cpu_hot: cpu_hot {
			temperature = <85000>;
			hysteresis = <2000>;
			type = "passive";
		};

		cpu_very_hot: cpu_very_hot {
			temperature = <90000>;
			hysteresis = <2000>;
			type = "passive";
		};

		cpu_critical {
			temperature = <105000>;
			hysteresis = <2000>;
			type = "critical";
		};
	};

	/delete-node/ cooling-maps;
	cooling-maps {
		cpu_warm_limit_cpu {
			trip = <&cpu_warm>;
			cooling-device = <&cpu0 THERMAL_NO_LIMIT 2>;
		};

		cpu_hot_pre_limit_cpu {
			trip = <&cpu_hot_pre>;
			cooling-device = <&cpu0 3 3>;
		};

		cpu_hot_limit_cpu {
			trip = <&cpu_hot>;
			cooling-device = <&cpu0 4 4>;
		};

		cpu_very_hot_limit_cpu {
			trip = <&cpu_very_hot>;
			cooling-device = <&cpu0 5 THERMAL_NO_LIMIT>;
		};
	};
};

     

  • my testing
    • 0 - idle
    • 10 - run "stress --cpu 4"
    • 36 - additional external heating
    • 134 - remove heating
    • 304 - stop "stress --cpu 4"
      image.thumb.png.b927aa84f0e7c858d8827c093db93cb3.png
1
going

going

Posted
Posted
  On 1/29/2023 at 6:20 PM, mcerveny said:

So the question, the armbian patches are well aligned with the new kernel, why are they not pushed to mainline ?

Expand  

That's not so. Some patches are outdated and do not work in the 6.1 kernel.

sunxi-6.1/series.conf the bad ones are off

Some patches are applied and work, but these changes in the 6.1 kernel are useless.
I only discovered this today.

 

Most of the armbian patches were taken from those that were proposed for kernel.org .

Those patches that were accepted are gone from this list.

0
mcerveny

mcerveny

Posted
  • Author
Posted
  On 1/29/2023 at 3:08 PM, ALIGMSTEN said:

Hi nope, fun in spare time approach here, arm64-dts-allwinner-h616-Add-efuse_xlate-cpufreq.patch.

Expand  

This code does not seem to be right:
  

#define SUN50I_H616_NVMEM_MASK 0x22
#define SUN50I_H616_NVMEM_SHIFT 5
...
u32 efuse_value = (*(u32 *)efuse >> SUN50I_H616_NVMEM_SHIFT) & SUN50I_H616_NVMEM_MASK;
...
if (efuse_value >=1 && efuse_value <= 3)

Are you sure about MASK ?
Or it is bitmask that should be translated like A100 ->  https://www.lkml.org/lkml/2020/12/8/70

0
mcerveny

mcerveny

Posted
  • Author
Posted (edited)
  On 1/27/2023 at 8:03 PM, mcerveny said:

- displayengine (drm, fb, mixer, tcon, hdmi) (seems to have some I2C/EDID problems)
- videoengine (cedrus) (in testing now)

Expand  

I successfully tested videoengine (tested 2k,4k,hevc,h264 and 4k hdr hevc (with non hdr output)). I found the problem in VI (video) layer in DRM (displayengine) output. I must change at least once after poweron DRM property "COLOR_RANGE" to DRM_COLOR_YCBCR_FULL_RANGE to get correctly setup CSC (color space conversion) in hw 🤨, lost 3 days in kernel debug.

Edited by mcerveny
0
ALIGMSTEN

ALIGMSTEN

Posted
Posted
  On 2/2/2023 at 9:42 PM, mcerveny said:

n hw 🤨, lost 3 days in kernel debug

Expand  

 

Very interesting, thanks for your work.

 

Personally still making changes during my testing atm, better understanding uboot registers, static const struct sunxi_cpufreq_soc_data sun50i_h616_data.. . etc...

 

I see 10 Members have downloaded , Add-h616-efuse_xlate-cpu-freq-scaling - any other feedback?

 

Here as is sbc-bench output ( no extended thermal and gpu-sys set as manual recommends)

 

  Reveal hidden contents

 

 

0
ALIGMSTEN

ALIGMSTEN

Posted
Posted

Hello @mcerveny, I would like to include your thermal changes in a PR to armbian 6.1. Would this be agreeable and how can I best credit you <@users.noreply.github.com>, ofc should you be agreeable?

 

Incidentally the switch case is finding the bins in the same manner, the sign(u32) has been noted.

 

The intended patch is V1 as WIP and will evolve, so all constructive input very welcome please.

 

Here are graphs called from sbc-bench

 

sbc-bench-v0.9.13-orangepi-zero2-.YxRzeH.pdf

0
stewartwatson

stewartwatson

Posted
Posted

Hi

 

I am afraid I cannot contribute much to this project, as I lack the technical expertise - but I have the orangepizero2 H616, and I think it is a fantastic bit of hardware for the price. I would like to do much more with it (currently I am using it as a pikvm, which works nicely and is fun... and a lot cheaper than a raspberypi based solution).

 

It is a shame it is not more fully supported and I just wanted to say thank you for your work and efforts on this. :)

 

Thank you!

1
ALIGMSTEN

ALIGMSTEN

Posted
Posted

 

Armbian-next commits

 

Commits on May 3, 2023

  

h616 Cpu frequency scaling (#5123)
* Add-h616-efuse_xlate-cpu-freq-scaling

* series_additions_h616-cpu-freq-scaling

* series_armbian_changes_h616-cpu-freq-scaling

---------

Co-authored-by: AGM1968 <AGM1968@users.noreply.githib.com>

https://github.com/armbian/build/commit/250a9c2cc0206c586557f37bc3db820d3750da39

 

Commits on May 5, 2023

  

sunxi-6.2 h616: Fix thermal zones (add missing trips)
 main (#5135)
@mdziekon
@igorpecovnik
mdziekon authored and igorpecovnik committed last week 


https://github.com/armbian/build/commit/7167d5c4200de30f7b103e5f9b478dcec78642ec





sunxi-6.1 h616: Fix thermal zones (add missing trips)
 main (#5135)
@mdziekon
@igorpecovnik
mdziekon authored and igorpecovnik committed last week 


https://github.com/armbian/build/commit/613234a75cebd4de421e8b832a4efc8bc23eeac2

 

0
ALIGMSTEN

ALIGMSTEN

Posted
Posted

Hello,

 

I see that the original xlate patch has been followed and adopted by other known kernel developers for 6.x.y.

 

For the 6.x.y kernels there is a hard study to utilize the patch due to a change to tokens from tables.

 

The probe fails because of these changes. I did not want to do the obvious, and have been working through some options. However for the sake of progress to 6.x.y perhaps that might be the way to go for now, I am more comfortable doing that, seeing that was a solution adopted by well known dev.

  

[    2.335847] Internal error: Oops: 0000000096000004 [#1] SMP
[    2.341864] Modules linked in:
[    2.345158] CPU: 1 PID: 50 Comm: kworker/u8:1 Not tainted 6.1.19-sunxi64 #trunk
[    2.353065] Hardware name: OrangePi Zero2 (DT)
[    2.357848] Workqueue: events_unbound deferred_probe_work_func
[    2.364173] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    2.371706] pc : sun50i_cpufreq_nvmem_probe+0xd4/0x2e8
[    2.377270] lr : sun50i_cpufreq_nvmem_probe+0xcc/0x2e8
[    2.382847] sp : ffff8000097abad0
[    2.386405] x29: ffff8000097abad0 x28: 0000000000000000 x27: 0000000000000000
[    2.394143] x26: ffff0000020b8a74 x25: 0000000000000000 x24: ffff0000022e0000
[    2.401889] x23: ffff00003fd780b8 x22: ffff0000049c3300 x21: ffff0000049c3380
[    2.409627] x20: ffff0000049c3400 x19: ffff8000090bbe18 x18: 0000000000000014
[    2.417338] x17: 00000000413cc101 x16: 0000000042260e86 x15: 000066b8303dd330
[    2.425076] x14: 0000000000000001 x13: 000000000000006e x12: 0000000000000001
[    2.432778] x11: 0000000000000001 x10: 0000000000000050 x9 : ffff8000097ab890
[    2.440480] x8 : 0000000000000050 x7 : ffff00003fd92240 x6 : ffff0000049c3480
[    2.448199] x5 : ffff0000022e1304 x4 : 0000000000000000 x3 : 0000000000000001
[    2.455910] x2 : 0000000000000001 x1 : 0000000000000002 x0 : ffff0000022e1304
[    2.463612] Call trace:
[    2.466253]  sun50i_cpufreq_nvmem_probe+0xd4/0x2e8
[    2.471442]  platform_probe+0x68/0xd8
[    2.475378]  really_probe+0xc0/0x3a0
[    2.479265]  __driver_probe_device+0x7c/0x188
[    2.483967]  driver_probe_device+0x3c/0x108
[    2.488479]  __device_attach_driver+0xbc/0x158
[    2.493268]  bus_for_each_drv+0x7c/0xd0
[    2.497414]  __device_attach+0xec/0x1a8
[    2.501560]  device_initial_probe+0x14/0x20
[    2.506071]  bus_probe_device+0x9c/0xa8
[    2.510209]  deferred_probe_work_func+0x9c/0xf0
[    2.515101]  process_one_work+0x220/0x3e8
[    2.519420]  worker_thread+0x258/0x500
[    2.523477]  kthread+0xd8/0xe8
[    2.526758]  ret_from_fork+0x10/0x20
[    2.530605] Code: aa1503e0 9402276a b140069f 54000608 (f9400321)
[    2.537200] ---[ end trace 0000000000000000 ]---

 

0
dziekon

dziekon

Posted
Posted (edited)

Hi @ALIGMSTEN

could you please clarify what do you mean by saying that kernel 6.x.y is problematic in terms of introduction of CPU frequency tables?

 

Personally, I was able to replicate what you've done in that regard for kernel 5.19 (I'm referring to this PR: https://github.com/armbian/build/pull/5123)

in both kernel 6.1 (current) and 6.2 (edge) with no issues (as in - the OS boots, works & passes sbc-bench). You can see my results summary here: https://github.com/mdziekon/armbian-build/pull/2

 

For now I've opened a PR against my own fork, but if you think this is the right path, there's nothing preventing me from opening a PR against main armbian repo.

Edited by dziekon
0
ALIGMSTEN

ALIGMSTEN

Posted
Posted

Hi @dziekon yeah I've been a bit too much on the experiential side with this, which caused some problems with the probe failing during those tests. 

 

I wasn't wanting to progress further myself until finished with v2-opp points, xlate alternative structure and PLL_CPUX experimentation.

 

Your PR proposal is exactly how the xlate patch is transferred to 6.x.y, there is nothing magic about the change, I am experimenting with alternative ways of doing that.

 

Best,

Alistair

 

Patch below as reference: (Nonetheless just to note I was about to 'finally' submit V1 in light of the comments 12 May)

 

  

From 7aee19c8c4a6c400dc45556e138d577d5453661d Mon Sep 17 00:00:00 2001
From: AGM1968 <AGM1968@users.noreply.github.com>
Date: Wed, 1 Mar 2023 14:16:30 +0200
Subject: [PATCH] Add-h616-efuse_xlate-cpu-freq-scaling-v1

Signed-off-by: AGM1968 <AGM1968@users.noreply.github.com>
---
 .../dts/allwinner/sun50i-h616-cpu-opp.dtsi    | 75 ++++++++++++++++
 .../allwinner/sun50i-h616-orangepi-zero2.dts  |  6 ++
 drivers/cpufreq/cpufreq-dt-platdev.c          |  4 +
 drivers/cpufreq/sun50i-cpufreq-nvmem.c        | 87 ++++++++++++++-----
 4 files changed, 150 insertions(+), 22 deletions(-)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-cpu-opp.dtsi

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-cpu-opp.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h616-cpu-opp.dtsi
new file mode 100644
index 000000000000..36f2950367c6
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-cpu-opp.dtsi
@@ -0,0 +1,75 @@
+//SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+//Testing Version 1  from: AGM1968 <AGM1968@users.noreply.github.com>
+//Noted: PLL_CPUX = 24 MHz*N/P (WIP)
+
+/ {
+	cpu_opp_table: opp-table-cpu {
+		compatible = "allwinner,sun50i-h616-operating-points";
+		nvmem-cells = <&cpu_speed_grade>;
+		opp-shared;
+ 
+		opp-480000000 {
+			clock-latency-ns = <244144>; /* 8 32k periods */
+			opp-hz = /bits/ 64 <480000000>;
+			opp-microvolt-speed0 = <820000 820000 1100000>; 
+			opp-microvolt-speed1 = <880000 880000 1100000>;
+			opp-microvolt-speed2 = <880000 880000 1100000>;
+		};
+	
+		opp-600000000 {
+			clock-latency-ns = <244144>; /* 8 32k periods */
+			opp-hz = /bits/ 64 <600000000>;
+			opp-microvolt-speed0 = <820000 820000 1100000>;
+			opp-microvolt-speed1 = <880000 880000 1100000>;
+			opp-microvolt-speed2 = <880000 880000 1100000>;
+		};
+
+		opp-792000000 {
+			clock-latency-ns = <244144>; /* 8 32k periods */
+			opp-hz = /bits/ 64 <792000000>;
+		        opp-microvolt-speed0 = <860000 860000 1100000>;
+			opp-microvolt-speed1 = <940000 940000 1100000>;
+			opp-microvolt-speed2 = <940000 940000 1100000>;
+		};
+
+		opp-1008000000 {
+			clock-latency-ns = <244144>; /* 8 32k periods */
+			opp-hz = /bits/ 64 <1008000000>;
+			opp-microvolt-speed0 = <900000 900000 1100000>;
+			opp-microvolt-speed1 = <1020000 1020000 1100000>;
+			opp-microvolt-speed2 = <1020000 1020000 1100000>;
+		};
+
+		opp-1200000000 {
+			clock-latency-ns = <244144>; /* 8 32k periods */
+			opp-hz = /bits/ 64 <1200000000>;
+			opp-microvolt-speed0 = <960000 960000 1100000>;
+			opp-microvolt-speed1 = <1100000 1100000 1100000>;
+			opp-microvolt-speed2 = <1100000 1100000 1100000>;
+		};
+
+		opp-1512000000 {
+			clock-latency-ns = <244144>; /* 8 32k periods */
+			opp-hz = /bits/ 64 <1512000000>;
+			opp-microvolt-speed0 = <1100000 1100000 1100000>;
+			opp-microvolt-speed1 = <1100000 1100000 1100000>;
+			opp-microvolt-speed2 = <1100000 1100000 1100000>;
+		};
+	};
+};
+
+&cpu0 {
+	operating-points-v2 = <&cpu_opp_table>;
+};
+ 
+&cpu1 {
+	operating-points-v2 = <&cpu_opp_table>;
+};
+ 
+&cpu2 {
+	operating-points-v2 = <&cpu_opp_table>;
+};
+ 
+&cpu3 {
+	operating-points-v2 = <&cpu_opp_table>;
+};
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 b78941d290ad..4babfac99043 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
@@ -6,6 +6,7 @@
 /dts-v1/;
 
 #include "sun50i-h616.dtsi"
+#include "sun50i-h616-cpu-opp.dtsi"
 
 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/interrupt-controller/arm-gic.h>
@@ -216,6 +217,11 @@ &pio {
 	vcc-pi-supply = <&reg_aldo1>;
 };
 
+&cpu0  {
+	cpu-supply = <&reg_dcdca>;
+	status = "okay";
+};
+
 &spi0  {
 	status = "okay";
 	pinctrl-names = "default";
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index 69a8742c0a7a..7fadcbe0c3c6 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -2,6 +2,9 @@
 /*
  * Copyright (C) 2016 Linaro.
  * Viresh Kumar <viresh.kumar@linaro.org>
+ *
+ * ADD cpufreq nvmem for allwinner h616 SoC, known to be analagous to h6
+ * Version 1 AGM1968 <AGM1968@users.noreply.github.com>
  */
 
 #include <linux/err.h>
@@ -102,6 +105,7 @@ static const struct of_device_id allowlist[] __initconst = {
  */
 static const struct of_device_id blocklist[] __initconst = {
 	{ .compatible = "allwinner,sun50i-h6", },
+	{ .compatible = "allwinner,sun50i-h616", },
 
 	{ .compatible = "arm,vexpress", },
 
diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
index 1acec58c33c3..690ae956659b 100644
--- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
+++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
@@ -6,6 +6,9 @@
  * provide the OPP framework with required information.
  *
  * Copyright (C) 2019 Yangtao Li <tiny.windzz@gmail.com>
+ *
+ * ADD efuse_xlate to extract SoC version so that h6 and h616 can coexist.
+ * Version 1 AGM1968 <AGM1968@users.noreply.github.com>
  */
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
@@ -19,25 +22,61 @@
 
 #define MAX_NAME_LEN	7
 
-#define NVMEM_MASK	0x7
-#define NVMEM_SHIFT	5
+#define SUN50I_H616_NVMEM_MASK 0x22
+#define SUN50I_H616_NVMEM_SHIFT 5
+#define SUN50I_H6_NVMEM_MASK 0x7
+#define SUN50I_H6_NVMEM_SHIFT 5
+
+struct sunxi_cpufreq_soc_data {
+	u32 (*efuse_xlate) (void *efuse);
+};
 
 static struct platform_device *cpufreq_dt_pdev, *sun50i_cpufreq_pdev;
 
+static u32 sun50i_h616_efuse_xlate(void *efuse)
+{
+   u32 efuse_value = (*(u32 *)efuse >> SUN50I_H616_NVMEM_SHIFT) &
+             SUN50I_H616_NVMEM_MASK;
+
+   /* Tested as V1 h616 soc. Expected efuse values are 1 - 3,
+      slowest to fastest */
+   if (efuse_value >=1 && efuse_value <= 3)
+       return efuse_value - 1;
+   else
+       return 0;
+};
+
+static u32 sun50i_h6_efuse_xlate(void *efuse)
+{
+   u32 efuse_value = (*(u32 *)efuse >> SUN50I_H6_NVMEM_SHIFT) &
+             SUN50I_H6_NVMEM_MASK;
+
+   /*
+    * We treat unexpected efuse values as if the SoC was from
+    * the slowest bin. Expected efuse values are 1 - 3, slowest
+    * to fastest.
+   */
+   if (efuse_value >= 1 && efuse_value <= 3)
+       return efuse_value - 1;
+   else
+       return 0;
+};
+
 /**
  * sun50i_cpufreq_get_efuse() - Determine speed grade from efuse value
+ * @soc_data: pointer to sunxi_cpufreq_soc_data context
  * @versions: Set to the value parsed from efuse
  *
  * Returns 0 if success.
  */
-static int sun50i_cpufreq_get_efuse(u32 *versions)
+static int sun50i_cpufreq_get_efuse(const struct sunxi_cpufreq_soc_data *soc_data,
+		u32 *versions)
 {
 	struct nvmem_cell *speedbin_nvmem;
 	struct device_node *np;
 	struct device *cpu_dev;
-	u32 *speedbin, efuse_value;
+	u32 *speedbin;
 	size_t len;
-	int ret;
 
 	cpu_dev = get_cpu_device(0);
 	if (!cpu_dev)
@@ -47,9 +86,9 @@ static int sun50i_cpufreq_get_efuse(u32 *versions)
 	if (!np)
 		return -ENOENT;
 
-	ret = of_device_is_compatible(np,
-				      "allwinner,sun50i-h6-operating-points");
-	if (!ret) {
+	if (of_device_is_compatible(np, "allwinner,sun50i-h6-operating-points")) {}
+	else if (of_device_is_compatible(np, "allwinner,sun50i-h616-operating-points")) {}
+	else {
 		of_node_put(np);
 		return -ENOENT;
 	}
@@ -65,17 +104,7 @@ static int sun50i_cpufreq_get_efuse(u32 *versions)
 	if (IS_ERR(speedbin))
 		return PTR_ERR(speedbin);
 
-	efuse_value = (*speedbin >> NVMEM_SHIFT) & NVMEM_MASK;
-
-	/*
-	 * We treat unexpected efuse values as if the SoC was from
-	 * the slowest bin. Expected efuse values are 1-3, slowest
-	 * to fastest.
-	 */
-	if (efuse_value >= 1 && efuse_value <= 3)
-		*versions = efuse_value - 1;
-	else
-		*versions = 0;
+	*versions = soc_data->efuse_xlate(speedbin);
 
 	kfree(speedbin);
 	return 0;
@@ -83,18 +112,23 @@ static int sun50i_cpufreq_get_efuse(u32 *versions)
 
 static int sun50i_cpufreq_nvmem_probe(struct platform_device *pdev)
 {
+	const struct of_device_id *match;
 	int *opp_tokens;
 	char name[MAX_NAME_LEN];
 	unsigned int cpu;
 	u32 speed = 0;
 	int ret;
 
+	match = dev_get_platdata(&pdev->dev);
+	if (!match)
+		return -EINVAL;
+
 	opp_tokens = kcalloc(num_possible_cpus(), sizeof(*opp_tokens),
 			     GFP_KERNEL);
 	if (!opp_tokens)
 		return -ENOMEM;
 
-	ret = sun50i_cpufreq_get_efuse(&speed);
+	ret = sun50i_cpufreq_get_efuse(match-> data, &speed);
 	if (ret) {
 		kfree(opp_tokens);
 		return ret;
@@ -160,8 +194,17 @@ static struct platform_driver sun50i_cpufreq_driver = {
 	},
 };
 
+static const struct sunxi_cpufreq_soc_data sun50i_h616_data = {
+    .efuse_xlate = sun50i_h616_efuse_xlate,
+};
+
+static const struct sunxi_cpufreq_soc_data sun50i_h6_data = {
+    .efuse_xlate = sun50i_h6_efuse_xlate,
+};
+
 static const struct of_device_id sun50i_cpufreq_match_list[] = {
-	{ .compatible = "allwinner,sun50i-h6" },
+	{ .compatible = "allwinner,sun50i-h6", .data = &sun50i_h6_data },
+        { .compatible = "allwinner,sun50i-h616", .data = &sun50i_h616_data },
 	{}
 };
 MODULE_DEVICE_TABLE(of, sun50i_cpufreq_match_list);
@@ -197,8 +240,8 @@ static int __init sun50i_cpufreq_init(void)
 		return ret;
 
 	sun50i_cpufreq_pdev =
-		platform_device_register_simple("sun50i-cpufreq-nvmem",
-						-1, NULL, 0);
+		platform_device_register_data(NULL,
+		"sun50i-cpufreq-nvmem", -1, match, sizeof(*match));
 	ret = PTR_ERR_OR_ZERO(sun50i_cpufreq_pdev);
 	if (ret == 0)
 		return 0;
-- 
Created with Armbian build tools https://github.com/armbian/build

 

 

0
ALIGMSTEN

ALIGMSTEN

Posted
Posted

Simple led change proposal

 

As development gains traction here I would like to propose a change to the way the onboard led's trigger.

 

Please state your preference!

 

Personal preference over time spent working with edge here.

 

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 159ffe654..23349c6ec 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
@@ -28,16 +28,17 @@ leds {
         compatible = "gpio-leds";
 
         led-0 {
-            function = LED_FUNCTION_POWER;
+            function = LED_FUNCTION_STATUS;
             color = <LED_COLOR_ID_RED>;
             gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /* PC12 */
-            default-state = "on";
+            linux,default-trigger = "heartbeat";
         };
 
         led-1 {
-            function = LED_FUNCTION_STATUS;
+            function = LED_FUNCTION_POWER;
             color = <LED_COLOR_ID_GREEN>;
             gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /* PC13 */
+            default-state = "on";
         };
     };

0
dziekon

dziekon

Posted
Posted (edited)

The proposed change patch looks malformed, but I assume you'd like to swap the LEDs, so that green is the board's power, while red is the board's activity (currently, power)?

If that's the case, it makes sense to me, and I believe this was the original behavior as present on orangepi-xunlong 4.9 kernel.

 

As for the patch itself, maybe it would be better to send these proposals as RFCs on Github directly, gists, or even just files? Looks like the board doesn't handle large code snippets that nicely, as it doesn't support highlighting, nor collapsing for easier thread maintenance. Just some thoughts to prevent spamming this discussion thread with non-exactly-discussion things.

Edited by dziekon
0
ALIGMSTEN

ALIGMSTEN

Posted
Posted
  On 5/27/2023 at 12:07 AM, dziekon said:

The proposed change patch looks malformed,

Expand  

 

My humble apologies, in haste copy/paste incorrectly! have amended the example.

 

  On 5/27/2023 at 12:07 AM, dziekon said:

green is the board's power, while red is the board's activity (currently, power)?

Expand  

 

Correct I've found that change to be visually appealing and closest to the 4.9 legacy kernels  

 

Thanks, valid points, noted the on-page posting last couple, instead of correctly formatted text in attachments or links, agreed that might be easier read.

 

Trigger Options: 

usb-gadget usb-host kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock
kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlo
ck kbd-ctrlllock kbd-ctrlrlock usbport disk-activity disk-read disk-write ide-di
sk mtd nand-disk heartbeat cpu cpu0 cpu1 cpu2 cpu3 activity default-on panic mmc
0 rfkill-any rfkill-none stmmac-0:01:link stmmac-0:01:1Gbps stmmac-0:01:100Mbps
stmmac-0:01:10Mbps

 

Lets see, perhaps doing this in a 'democratic-manner' here is not the way.

 

Merged - https://github.com/armbian/build/pull/5270

 

As above your preferences can be altered when you build!

1
Igor

Igor

Posted
Posted
  On 7/1/2023 at 5:55 PM, jquagga said:

orangepi has a 6.1 kernel tree out there with different dts for the Orange Pi Zero 2.

Expand  


With many patches taken directly from Armbian 6.1.y, but there are few more so its worth investigating.

0

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.

Guest
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.

×
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept