Jump to content
  • 0

Orangepi 3 h6 allwiner chip


constantius
 Share

Question

Recommended Posts

  • 0

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

Armbian is a community driven open source project. Do you like to contribute your code?

  • 0
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

  • 0
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

  • 0
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

  • 0
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

  • 0
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

  • 0

 

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

  • 0
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

  • 0

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

  • 0

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

  • 0
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

  • 0
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

  • 0
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

  • 0
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

  • 0

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

  • 0
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

  • 0

I hope I can ask here (I'm new so it won't let me post a question on the main H6 page).

 

What's the difference between the images for Orange Pi 3 and Orange Pi Lite 2?

I have both boards, downloaded both images. The Lite 2 image (Armbian_20.02.1_Orangepilite2_buster_current_5.4.20.img) works on both boards, flawlessly (well as flawlessy as Armbian and Orange Pi ever do). Both boards boot just fine with that image.

However the OPi3 does not display anything with the 3 image (Armbian_20.02.1_Orangepi3_buster_current_5.4.20.img). I can connect to the board via serial console and I can see it booting fine and I can interact with it, but it does not display anything at all.  So there's some difference between those images that prevents the OPi3 from displaying anything.

 

I haven't yet tried to boot the Lite2 with the OPi3 image, will get to that later.

Edited by Anna Vahtera
wrong filename
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
Answer this question...

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

×
×
  • Create New...