49 49
constantius

Orangepi 3 h6 allwiner chip

Recommended Posts

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

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 !

Share this post


Link to post
Share on other sites

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 :P

Share this post


Link to post
Share on other sites
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?

 

Share this post


Link to post
Share on other sites
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 :P

 

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 ... :P

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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?                 

Share this post


Link to post
Share on other sites

 

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Loading...
49 49