Orangepi 3 h6 allwiner chip

kexec · February 3, 2020

5 hours ago, jcaron said:

Just upgraded to the latest Armbian 20.05 with kernel 5.5.0 final. It seems to be working well, however I'm still having issues with Panfrost/T720, just wondering if it's just me (messed up compilation or configuration somewhere) or if others have the same issue.


jc@orangepi3:~$ glmark2 --validate
=======================================================
    glmark2 2017.07
=======================================================
    OpenGL Information
    GL_VENDOR:     Panfrost
    GL_RENDERER:   Mali T720 (Panfrost)
    GL_VERSION:    2.1 Mesa 20.0.0-devel (git-f09c466732)
=======================================================
[build] use-vbo=false:[  570.822429] Purging 8519680 bytes
 Validation: Failure
[build] use-vbo=true: Validation: Success
[texture] texture-filter=nearest: Validation: Failure
[texture] texture-filter=linear: Validation: Success
Segmentation fault

jc@orangepi3:~$ glmark2-es2 --validate
=======================================================
    glmark2 2017.07
=======================================================
    OpenGL Information
    GL_VENDOR:     Panfrost
    GL_RENDERER:   Mali T720 (Panfrost)
    GL_VERSION:    OpenGL ES 2.0 Mesa 20.0.0-devel (git-f09c466732)
=======================================================
[build] use-vbo=false: Validation: Failure
[build] use-vbo=true: Validation: Success
[texture] texture-filter=nearest: Validation: Failure
[texture] texture-filter=linear: Validation: Success
[texture] texture-filter=mipmap: Validation: Failure
[shading] shading=gouraud: Validation: Failure
[shading] shading=blinn-phong-inf: Validation: Failure
[shading] shading=phong: Validation: Failure
[shading] shading=cel: Validation: Unknown
[bump] bump-render=high-poly: Validation: Failure
[bump] bump-render=normals: Validation: Failure
[bump] bump-render=height: Validation: Failure
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: Validation: Failure
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: Validation: Failure
[pulsar] light=false:quads=5:texture=false: Validation: Failure
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: Validation: Failure
[desktop] effect=shadow:windows=4: Validation: Failure
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: Validation: Failure
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: Validation: Success
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: Validation: Success
[ideas] speed=duration: Validation: Unknown
[jellyfish] <default>: Validation: Unknown
[terrain] <default>: Validation: Unknown
[shadow] <default>: Validation: Unknown
[refract] <default>: Validation: Unknown
[conditionals] fragment-steps=0:vertex-steps=0: Validation: Failure
[conditionals] fragment-steps=5:vertex-steps=0: Validation: Failure
[conditionals] fragment-steps=0:vertex-steps=5: Validation: Failure
[function] fragment-complexity=low:fragment-steps=5: Validation: Failure
[function] fragment-complexity=medium:fragment-steps=5: Validation: Success
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: Validation: Success
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: Validation: Success
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: Validation: Success

i have also compiled 5.5 image and was not able to make mesa work. on 5.4 kernel it works but quite unstable, extremetuxracer game somehow finished to the end, but as I am lazy one i have tired of geting my as up and reboot device on each fail.

even with all sysctl kernel panic parameters set to 1 , not always got device rebooted automaticly

Aleksandar · February 4, 2020

Hello,

I'm using orangepi3 with latest Armbian 20.02

Why there is no egde file in /sys/class/gpio/gpioXXX/ like on the raspberrypi

root@orangepi3:/sys/class/gpio/gpio117# ls -lh
total 0
-rw-r--r-- 1 root root 4.0K Feb  4 13:59 active_low
lrwxrwxrwx 1 root root    0 Feb  4 13:59 device -> ../../../gpiochip1
-rw-r--r-- 1 root root 4.0K Feb  4 13:57 direction
drwxr-xr-x 2 root root    0 Feb  4 13:40 power
lrwxrwxrwx 1 root gpio    0 Feb  4 13:40 subsystem -> ../../../../../../../class/gpio
-rw-r--r-- 1 root root 4.0K Feb  4 13:40 uevent
-rw-r--r-- 1 root root 4.0K Feb  4 13:40 value

martinayotte · February 4, 2020

47 minutes ago, Aleksandar said:

Why there is no egde file in /sys/class/gpio/gpioXXX/ like on the raspberrypi

Most probably a custom implementation of "edge interrupt" made on raspberrypi but never submitted to Mainline kernel.

jcaron · February 4, 2020

2 hours ago, Aleksandar said:

Hello,

I'm using orangepi3 with latest Armbian 20.02

Why there is no egde file in /sys/class/gpio/gpioXXX/ like on the raspberrypi

According to https://www.kernel.org/doc/Documentation/gpio/sysfs.txt

Quote

"edge" ... reads as either "none", "rising", "falling", or "both". Write these strings to select the signal edge(s) that will make poll(2) on the "value" file return. This file exists only if the pin can be configured as an interrupt generating input pin.

gpio117 either cannot generate an interrupt, or this is not known to the kernel/driver. Trying to find the info in the H6 manual. Are you tied to this specific pin?

Note that edge correctly appears for gpio40 for instance.

martinayotte · February 4, 2020

1 hour ago, jcaron said:

Trying to find the info in the H6 manual.

Interesting ... On all my H6, "edge" is effectively not present, but is present on all my H3 or H5 ...

I need to look deeper since it highlight my curiosity !

martinayotte · February 4, 2020

I've asked on chat, and @jernej answered me :

Quote

H6 has interrupts on port F, G, H, L and M according to manual

So, previous trials on port C didn't worked, but on port F, example PF2, it is working and "edge" is present...

Conclusion, reading manual is always a good thing to do

jcaron · February 4, 2020

24 minutes ago, martinayotte said:

Interesting ... On all my H6, "edge" is effectively not present, but is present on all my H3 or H5 ...

I need to look deeper since it highlight my curiosity !

Can't find anything saying that some GPIOs would not allow interrupts in the doc, but I only looked relatively quickly. It's probably something in the DTB which tells the kernel whether the GPIO has interrupts or not, but I'm not quite familiar with their structure or contents...

Another possibility could that the pin is believed by the kernel to be used for another function and thus interrupts are disabled, maybe? If I'm not mistaken GPIO117 is PD21, and PD21 is used by UART2?

jcaron · February 4, 2020

1 minute ago, martinayotte said:

I've asked on chat, and @jernej answered me :

H6 has interrupts on port F, G, H, L and M according to manual

So, old trial on port C didn't worked, but on port F, example PF2, it is working and "edge" is present...

Conclusion, reading manual is always a good thing to do

Ah indeed, a few dozen pages further it becomes clear...

jernej · February 4, 2020

8 minutes ago, jcaron said:

Can't find anything saying that some GPIOs would not allow interrupts in the doc, but I only looked relatively quickly.

Take a look into GPIO controller register description. You will find interrupt settings only for port F, G, H, L and M.

martinayotte · February 4, 2020

6 minutes ago, jcaron said:

GPIO117 is PD21, and PD21 is used by UART2?

Right, but only if UART2 is enabled ... But anyway D port is not part of the list of ports where interrupt could be used.

As I said, RTFM ... GIC Table shows B, F, G, H, L and M ...

@jernej you forgot the B one ...

jernej · February 4, 2020

3 minutes ago, martinayotte said:

@jernej you forgot the B one ...

True, but port A and B are routed internally to AC200 co-packaged IC and not useful for outside world. Information about port A and B is not even in manual.

martinayotte · February 4, 2020

1 minute ago, jernej said:

port A and B are routed internally to AC200 co-packaged IC

Right !

Aleksandar · February 4, 2020

Thank you all.

Yes, there is edge on pins with letter L in pin name (354, 355, 362, 360 etc.)

jstefanop · February 14, 2020

Was the PCIE port ever fixed on this? Has anyone tried a PCIE SSD on it?

martinayotte · February 14, 2020

7 minutes ago, jstefanop said:

Was the PCIE port ever fixed on this? Has anyone tried a PCIE SSD on it?

Quote from https://linux-sunxi.org/H6 :

Quote

Errata

The PCIe implementation is broken.

Allwinner H6 has a quirky PCIe controller that doesn't map the PCIe address space properly (only 64k accessible at one time) to CPU, and accessing the PCIe config space, I/O space or memory space will need to be wrapped. As Linux doesn't wrap PCIe memory space access, it's not possible to do a proper PCIe controller driver for H6. The BSP kernel modifies the driver to wrap the access, so it's also not generic, and only devices with modified driver will work.

As you can read, it is an hardware issue, nothing about Armbian images.

I doubt anyone spend time to hack existing SATA or SSD drivers to make it work with H6 PCIe address space limitation.

haajee · February 18, 2020

My Orange Pi One Plus H6 with the latest update to Armbian 20.02.1 and 5.4.20 kernel is the max CPU speed i can choose 1.48GHz. Before i could also select 1.8GHz. Is this implemented with a reason?

Werner · February 18, 2020

45 minutes ago, haajee said:

My Orange Pi One Plus H6 with the latest update to Armbian 20.02.1 and 5.4.20 kernel is the max CPU speed i can choose 1.48GHz. Before i could also select 1.8GHz. Is this implemented with a reason?

AFAIK for some people the H6 did non run stable with full speed. Therefore it has been limited to stable 1,5GHz.

greg798 · February 18, 2020

If the temperature is above 60, the processor resets the frequency to 1.5Ghz, active cooling will give stability.

haajee · February 19, 2020

13 hours ago, greg798 said:

If the temperature is above 60, the processor resets the frequency to 1.5Ghz, active cooling will give stability.

Hmm, mines is continuously around 38 degrees with active cooling.

18 hours ago, Werner said:

AFAIK for some people the H6 did non run stable with full speed. Therefore it has been limited to stable 1,5GHz.

Thnx for your info. Maybe is it placebo but it feels like the pi works faster! So i hope

Werner · February 19, 2020

As for myself I keep my One Plus on kernel 5.3.x which did not include the cpu cap yet. It works decent on full 1.8GHz speed. That is also the reason why I could not understand why this has been implemented for quite a while. Later I realized due to the occuring discussion that there seem quite some manufacturing tolerances in the components which may cause the instability on some boards....

Werner · February 19, 2020

Just took a look. The 1+ running on 5.3.7. I archived some old images.

https://laet.pw/index.php/s/M2eXJKll5sdnlBN?path=%2F_archive%2F1810

Feel free to test and check if the CPU speed raises up to 1.8 GHz

GeraltOfTrivia · February 20, 2020

The reason that the OPi1+ doesn't clock higher than 1,48 GHz with the recent kernel versions isnt (just) the cpu opp table itself,

the entries for 1,8 GHz (and even 1,6 GHz in 5.4.20) exist.

The problem is that in the DTB, the max microvolt value for dcdca or vdd-cpu is lower than what's needed for the cpu to switch to 1,6 GHz or higher.

dcdca {
		regulator-always-on;
        regulator-min-microvolt = <0xc5c10>;
        regulator-max-microvolt = <0x107ac0>; (1080 mV)
        regulator-name = "vdd-cpu";
        phandle = <0x6>;
}

 opp@1640000000 {
                        opp-hz = <0x0 0x61c06a00>;
                        opp-microvolt = <0x11b340 0x11b340 0x11b340>; (1160 mV)
                        clock-latency-ns = <0x3b9b0>;
                };

                opp@1800000000 {
                        clock-latency-ns = <0x3b9b0>;
                        opp-hz = <0x0 0x6b49d200>;
                        opp-microvolt-speed0 = <0x11b340>;
                        opp-microvolt-speed1 = <0x10c8e0>; (1100 mV)
                        opp-microvolt-speed2 = <0x10c8e0>;
                };

I tried this myself with my OPi1+ with kernel 5.5.0 by raising regulator-max-microvolt to 0x11b340 (1160 mV) and it successfully clocked to 1,8 GHz. YMMV. Sorry if this has already been mentioned elsewhere.

Werner · February 20, 2020

17 minutes ago, GeraltOfTrivia said:
The reason that the OPi1+ doesn't clock higher than 1,48 GHz with the recent kernel versions isnt (just) the cpu opp table itself,

the entries for 1,8 GHz (and even 1,6 GHz in 5.4.20) exist.

The problem is that in the DTB, the max microvolt value for dcdca or vdd-cpu is lower than what's needed for the cpu to switch to 1,6 GHz or higher.
dcdca {
		regulator-always-on;
        regulator-min-microvolt = <0xc5c10>;
        regulator-max-microvolt = <0x107ac0>; (1080 mV)
        regulator-name = "vdd-cpu";
        phandle = <0x6>;
}
 opp@1640000000 {
                        opp-hz = <0x0 0x61c06a00>;
                        opp-microvolt = <0x11b340 0x11b340 0x11b340>; (1160 mV)
                        clock-latency-ns = <0x3b9b0>;
                };

                opp@1800000000 {
                        clock-latency-ns = <0x3b9b0>;
                        opp-hz = <0x0 0x6b49d200>;
                        opp-microvolt-speed0 = <0x11b340>;
                        opp-microvolt-speed1 = <0x10c8e0>; (1100 mV)
                        opp-microvolt-speed2 = <0x10c8e0>;
                };
I tried this myself with my OPi1+ with kernel 5.5.0 by raising regulator-max-microvolt to 0x11b340 (1160 mV) and it successfully clocked to 1,8 GHz. YMMV. Sorry if this has already been mentioned elsewhere.

It would be awesome if you could provide a patch and put it to sunxi-dev

and later backport it to current as soon as it is known to run stable enough.

GeraltOfTrivia · February 20, 2020

13 minutes ago, Werner said:

It would be awesome if you could provide a patch and put it to sunxi-dev

I'd gladly do that, but unfortunately my git skills leave much to be desired. I could try to learn though

However, I'm not sure the armbian team would appreciate the extra influx of people complaining about instability issues because of the higher clocks+bad PSUs.

Werner · February 20, 2020

11 minutes ago, GeraltOfTrivia said:

extra influx of people complaining about instability

That is the reason why I suggested to push it to dev first and then see what happens. If end-user using dev images which can be broken at any time it is their fault.

Werner · February 22, 2020

On 2/20/2020 at 7:34 PM, GeraltOfTrivia said:
The reason that the OPi1+ doesn't clock higher than 1,48 GHz with the recent kernel versions isnt (just) the cpu opp table itself,

the entries for 1,8 GHz (and even 1,6 GHz in 5.4.20) exist.

The problem is that in the DTB, the max microvolt value for dcdca or vdd-cpu is lower than what's needed for the cpu to switch to 1,6 GHz or higher.
dcdca {
		regulator-always-on;
        regulator-min-microvolt = <0xc5c10>;
        regulator-max-microvolt = <0x107ac0>; (1080 mV)
        regulator-name = "vdd-cpu";
        phandle = <0x6>;
}
 opp@1640000000 {
                        opp-hz = <0x0 0x61c06a00>;
                        opp-microvolt = <0x11b340 0x11b340 0x11b340>; (1160 mV)
                        clock-latency-ns = <0x3b9b0>;
                };

                opp@1800000000 {
                        clock-latency-ns = <0x3b9b0>;
                        opp-hz = <0x0 0x6b49d200>;
                        opp-microvolt-speed0 = <0x11b340>;
                        opp-microvolt-speed1 = <0x10c8e0>; (1100 mV)
                        opp-microvolt-speed2 = <0x10c8e0>;
                };
I tried this myself with my OPi1+ with kernel 5.5.0 by raising regulator-max-microvolt to 0x11b340 (1160 mV) and it successfully clocked to 1,8 GHz. YMMV. Sorry if this has already been mentioned elsewhere.

Just confirmed it works. 1.64 and 1.80 GHz frequencies became available.

For others that want to "live patch" their One Plus just use the dtc tool to decompile the sun50i-h6-orangepi-one-plus.dtb, adjust the voltage (double check to edit at the correct spot and triple check the edited value!) and recompile it with the same tool. Replace the old dtb and reboot. Check with something like cpufreq-info if it works.

This is just very minor tested, the SBC still can get unstable for unknown reasons through this.

@martinayotte maybe you wanna take a note on this one.

martinayotte · February 23, 2020

22 hours ago, Werner said:

@martinayotte maybe you wanna take a note on this one.

I'm currently busy on switching sunxi-dev to 5.6.y, but if any PR is provided, I'm ready to merge it ...

haajee · February 23, 2020

I have also with Armbian Buster 5.4.20 that every time when i start armbian-config he reload all the packages for armbian-config?

haajee · February 24, 2020

Hmm, yesterday back to kernel 5.3.something and now after apt upgrade back on 5.4.20 stable. Just with the continuously load of files when i trie to start armbian-config. When i try to switch to kernel 4.19.104 i got an error. The rest is just working fine.

Werner · February 25, 2020

On 2/20/2020 at 8:05 PM, GeraltOfTrivia said:

I'd gladly do that, but unfortunately my git skills leave much to be desired. I could try to learn though

However, I'm not sure the armbian team would appreciate the extra influx of people complaining about instability issues because of the higher clocks+bad PSUs.

Patch has been pushed to current.

Sign In

Orangepi 3 h6 allwiner chip

Recommended Posts

kexec

Aleksandar

martinayotte

jcaron

martinayotte

martinayotte

jcaron

jcaron

jernej

martinayotte

jernej

martinayotte

Aleksandar

jstefanop

martinayotte

haajee

Werner

greg798

haajee

Werner

Werner

GeraltOfTrivia

Werner

GeraltOfTrivia

Werner

Werner

martinayotte

haajee

haajee

Werner

Join the conversation

Similar Content

Forums

My Activity Streams

Download

Store

Important Information