kexec Posted February 3, 2020 Share Posted 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 0 Quote Link to comment Share on other sites More sharing options...
Aleksandar Posted February 4, 2020 Share Posted 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 0 Quote Link to comment Share on other sites More sharing options...
martinayotte Posted February 4, 2020 Share Posted 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. 0 Quote Link to comment Share on other sites More sharing options...
jcaron Posted February 4, 2020 Share Posted 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. 0 Quote Link to comment Share on other sites More sharing options...
martinayotte Posted February 4, 2020 Share Posted 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 ! 0 Quote Link to comment Share on other sites More sharing options...
martinayotte Posted February 4, 2020 Share Posted 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 0 Quote Link to comment Share on other sites More sharing options...
jcaron Posted February 4, 2020 Share Posted 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? 0 Quote Link to comment Share on other sites More sharing options...
jcaron Posted February 4, 2020 Share Posted 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... 0 Quote Link to comment Share on other sites More sharing options...
jernej Posted February 4, 2020 Share Posted 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. 0 Quote Link to comment Share on other sites More sharing options...
martinayotte Posted February 4, 2020 Share Posted 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 ... 0 Quote Link to comment Share on other sites More sharing options...
jernej Posted February 4, 2020 Share Posted 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. 0 Quote Link to comment Share on other sites More sharing options...
martinayotte Posted February 4, 2020 Share Posted February 4, 2020 1 minute ago, jernej said: port A and B are routed internally to AC200 co-packaged IC Right ! 0 Quote Link to comment Share on other sites More sharing options...
Aleksandar Posted February 4, 2020 Share Posted February 4, 2020 Thank you all. Yes, there is edge on pins with letter L in pin name (354, 355, 362, 360 etc.) 0 Quote Link to comment Share on other sites More sharing options...
jstefanop Posted February 14, 2020 Share Posted February 14, 2020 Was the PCIE port ever fixed on this? Has anyone tried a PCIE SSD on it? 0 Quote Link to comment Share on other sites More sharing options...
martinayotte Posted February 14, 2020 Share Posted 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. 0 Quote Link to comment Share on other sites More sharing options...
haajee Posted February 18, 2020 Share Posted 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? 0 Quote Link to comment Share on other sites More sharing options...
Werner Posted February 18, 2020 Share Posted 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. 0 Quote Link to comment Share on other sites More sharing options...
greg798 Posted February 18, 2020 Share Posted February 18, 2020 If the temperature is above 60, the processor resets the frequency to 1.5Ghz, active cooling will give stability. 0 Quote Link to comment Share on other sites More sharing options...
haajee Posted February 19, 2020 Share Posted 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 0 Quote Link to comment Share on other sites More sharing options...
Werner Posted February 19, 2020 Share Posted 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.... 0 Quote Link to comment Share on other sites More sharing options...
Werner Posted February 19, 2020 Share Posted 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 0 Quote Link to comment Share on other sites More sharing options...
GeraltOfTrivia Posted February 20, 2020 Share Posted 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. 1 Quote Link to comment Share on other sites More sharing options...
Werner Posted February 20, 2020 Share Posted 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. 0 Quote Link to comment Share on other sites More sharing options...
GeraltOfTrivia Posted February 20, 2020 Share Posted 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. 0 Quote Link to comment Share on other sites More sharing options...
Werner Posted February 20, 2020 Share Posted 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. 0 Quote Link to comment Share on other sites More sharing options...
Werner Posted February 22, 2020 Share Posted 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. 0 Quote Link to comment Share on other sites More sharing options...
martinayotte Posted February 23, 2020 Share Posted 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 ... 1 Quote Link to comment Share on other sites More sharing options...
haajee Posted February 23, 2020 Share Posted 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? 0 Quote Link to comment Share on other sites More sharing options...
haajee Posted February 24, 2020 Share Posted 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. 0 Quote Link to comment Share on other sites More sharing options...
Werner Posted February 25, 2020 Share Posted 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. 0 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.