Jump to content

Orangepi 3 h6 allwiner chip


constantius

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

Link to comment
Share on other sites

Armbian & Khadas are rewarding contributors

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

 

Link to comment
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.

Link to comment
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?

 

Link to comment
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...

Link to comment
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.

Link to comment
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.

Link to comment
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.

Link to comment
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 :)

Link to comment
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....

Link to comment
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.

Link to comment
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.

Link to comment
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.

Link to comment
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.

Link to comment
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.

Link to comment
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.

Link to comment
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.

Link to comment
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...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines