jock

True, openelec for OrangePis is working really well. Anyway it would be nice to be able to run kodi on armbian too.

This should be useful to you:

Hello, I am runnign armbian 5.05 jessie server on an OrangePi One. I wish to test network audio streams so I installed pulseaudio to do some tests. As long as ALSA works fine with HDMI output, I thought that pulseaudio would work the same, but I was wrong. The basic pulseaudio installation (apt-get install pulseaudio) turned to be a non effective way to obtain pulseaudio support. Actually this is strange because if I set the default pulseaudio sink to analog audio, it works fine (I get no sound but just because the Opi One has no analog connector). When I set the default sink to hdmi audio, I get indiscernible short discharges instead of music and pulseaudio continously laments buffer underruns. This is the log of pulseaudio while trying to produce some output: I: [alsa-sink-SUNXI-HDMIAUDIO sndhdmi-0] alsa-sink.c: Starting playback. I: [pulseaudio] sink-input.c: Created input 1 "libao[ogg123] playback stream" on alsa_output.platform-sndhdmi.analog-stereo with sample spec s16le 2ch 44100Hz and channel map front-left,front-right I: [pulseaudio] sink-input.c: media.name = "libao[ogg123] playback stream" I: [pulseaudio] sink-input.c: application.name = "libao[ogg123]" I: [pulseaudio] sink-input.c: native-protocol.peer = "UNIX socket client" I: [pulseaudio] sink-input.c: native-protocol.version = "29" I: [pulseaudio] sink-input.c: application.process.id = "5921" I: [pulseaudio] sink-input.c: application.process.user = "paolo" I: [pulseaudio] sink-input.c: application.process.host = "orangepione" I: [pulseaudio] sink-input.c: application.process.binary = "ogg123" I: [pulseaudio] sink-input.c: application.language = "C" I: [pulseaudio] sink-input.c: application.process.machine_id = "89107ace91b54204bd18fe15ddd2684c" I: [pulseaudio] sink-input.c: application.process.session_id = "3" I: [pulseaudio] sink-input.c: module-stream-restore.id = "sink-input-by-application-name:libao[ogg123]" I: [pulseaudio] protocol-native.c: Requested tlength=250.00 ms, minreq=20.00 ms I: [pulseaudio] protocol-native.c: Final latency 250.01 ms = 105.01 ms + 2*20.00 ms + 105.00 ms I: [alsa-sink-SUNXI-HDMIAUDIO sndhdmi-0] alsa-sink.c: Underrun! I: [alsa-sink-SUNXI-HDMIAUDIO sndhdmi-0] alsa-sink.c: Increasing wakeup watermark to 30.00 ms I: [alsa-sink-SUNXI-HDMIAUDIO sndhdmi-0] alsa-sink.c: Underrun! I: [alsa-sink-SUNXI-HDMIAUDIO sndhdmi-0] alsa-sink.c: Increasing wakeup watermark to 40.00 ms I: [alsa-sink-SUNXI-HDMIAUDIO sndhdmi-0] alsa-sink.c: Underrun! I: [alsa-sink-SUNXI-HDMIAUDIO sndhdmi-0] alsa-sink.c: Increasing wakeup watermark to 50.00 ms I: [alsa-sink-SUNXI-HDMIAUDIO sndhdmi-0] alsa-sink.c: Underrun! I: [alsa-sink-SUNXI-HDMIAUDIO sndhdmi-0] alsa-sink.c: Increasing wakeup watermark to 60.00 ms I: [alsa-sink-SUNXI-HDMIAUDIO sndhdmi-0] alsa-sink.c: Underrun! I: [alsa-sink-SUNXI-HDMIAUDIO sndhdmi-0] alsa-sink.c: Increasing wakeup watermark to 70.00 ms I: [pulseaudio] sink-input.c: Freeing input 1 "libao[ogg123] playback stream" Still, if I uninstall pulseaudio completely, ALSA works perfectly with both analog or HDMI sound

I guess you're right. I checked the voltages against the 1V2S and the shielding of the TF card (I suppose it is grounded), and the voltage is 1.09v and 1.29v. Theorically this is correct, but the CPU idles at 53°C (1.09v) and 60°C (v1.29) at 480 Mhz, which is way higher than the PC, which idles at 30°C at 480 MHz (but at 0.980v) I guess the test point doesn't report the correct CPU voltage. Instead the GPIO configuration bit works. edit: I checked a bit the voltage regulator datasheet and tried to follow the circuit. I followed the LX pin of the AX3833, passed over the inductance, the two capacitors and finally I measured... 1.09 volts!

Tested the Orange PI PC and it looks stable at 1.2 Ghz with 1.150 volts. At 1.120 volts it boots but it is unstable, so either the H3 part of my One is a bit better than the H3 part of my PC or the linear regulator of the One is feeding a more stable current to the CPU. The H3 of the One reports a much higher temperature than the H3 of the PC, something like 15/20°C more. Testing conditions are almost the same, the PC has a slightly higher voltage (1.150v instead of 1.100v) but its temperature is way lower than the One, in fact I had to put a "heatsink" on the One to keep it cool.

Thanks for the hint, I changed /etc/default/cpufrequtils with a maximum frequency of 1200 Mhz. Still I don't understand why cpufreq-info proposes all the frequency steps, as long as the sunxi driver should report the frequencies given in the dvfs table...

Hello, I was tweaking the dvfs table on my OrangePI PC to find the maximum efficiency sweet spot. I noticed that no way I change the dvfs table, the maximum frequency is always 1296 Mhz. This is the very simple dvfs table I'm using now: [dvfs_table] pmuic_type = 2 extremity_freq = 1200000000 max_freq = 1200000000 min_freq = 480000000 LV_count = 2 LV1_freq = 1200000000 LV1_volt = 1240 LV2_freq = 480000000 LV2_volt = 980 but this is the result of an excerpt cpufreq-info command for cpu0: driver: cpufreq-sunxi CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 2.00 ms. hardware limits: 480 MHz - 1.20 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, interactive, performance current policy: frequency should be within 480 MHz and 1.30 GHz. The governor "interactive" may decide which speed to use within this range. current CPU frequency is 480 MHz. cpufreq stats: 60.0 MHz:0.00%, 120 MHz:0.00%, 240 MHz:0.00%, 312 MHz:0.00%, 408 MHz:0.00%, 480 MHz:72.35%, 504 MHz:0.00%, 600 MHz:0.03%, 648 MHz:0.02%, 720 MHz:0.00%, 816 MHz:0.00%, 912 MHz:0.00%, 1.01 GHz:1.66%, 1.10 GHz:0.07%, 1.20 GHz:1.52%, 1.30 GHz:24.33%, 1.34 GHz:0.00%, 1.44 GHz:0.00%, 1.54 GHz:0.00% (64) I don't understand why hardware limits are 480 Mhz - 1.2 Ghz but the CPU is allowed to do transitions up to 1.3 Ghz? Benchmarks confirm the CPU is running at 1.3Ghz as maximum frequency. I removed the 1296 Mhz reference from cooler_table and adjust it too, but nothing changed. Is there something I'm missing?

Well, actually it's not a real heatsink. It is an exhausted AA battery with some thermal paste applied on the cathode and placed on the H3 chip. It is pretty good for experiments and never gets so hot that it can explode. Anyway I'll try some voltage tricks on the Orange PI PC I have laying around to see if it behaves the same as the One.

Some tests shows that 5 minutes of cpuburn-a7 alone are able to push the H3 at 80°C. I have a "special" heatsink over it, and it is helping a lot, but there is no throttling and no downcoring. This is the rpi-monitor graph of the session: Openssl speed -multi 4 instead doesn't go over 65°C after several minutes of benchmarking.

I'll do the tests tomorrow as soon as I can. By the way the thingy survived "openssl speed -multi 4" which is much longer than the sole rsa test.

According to this http://linux-sunxi.org/Xunlong_Orange_Pi_One#CPU_clock_speed_limit the voltage level should be controlled by GPIO, and according to the following comment: # pmu_levelx: 0~9999: voltage(mV), 10000~90000:gpio0 state. voltage form high to low. pmu_level should be 5 decimals long, the first decimal controls the gpio state and the following four decimals define the reference voltage for the dvfs table. Default pmu_levels on the one are: pmu_level0 = 11300 # GPIO pin is set, hence 1.3v pmu_level1 = 1100 # GPIO pin is not set, hence 1.1v My deduction says that: pmu_level0 = 11300 -> GPIO is set (first "1" = high voltage) and reference voltage for the dvfs table entries is 1300 mV pmu_level1 = 1100 -> equals to 01100 (first "0" = low voltage) and reference voltage is 1100 mV Using my dvfs table I'm not allowing the GPIO to be set, so the voltage is staying always low. I just forced the governor to performance @1.2 Ghz and measured the voltage on the One: it says 1.09v so I guess that my deduction is correct.

Hello all guys, I tested my orange pi one and it is free from the overvoltage "defect" related to the CPU voltage regulator. The multimeter reports the expected 1.1 and 1.3 voltages. I decided to do some tests to find the highest frequency it can run stable at its lowest voltage of 1.1 volts. I found something odd. This is the dvfs table I'm using now: [dvfs_table] pmuic_type = 1 pmu_gpio0 = port:PL06<1><1><2><1> pmu_level0 = 1100 pmu_level1 = 1100 extremity_freq = 1200000000 max_freq = 1200000000 min_freq = 648000000 LV_count = 2 LV1_freq = 1200000000 LV1_volt = 1100 LV2_freq = 648000000 LV2_volt = 1100 If you're skilled with script.fex, you'll notice that I locked the maximum voltage to 1.1 volts and frequency is free to switch between 648 Mhz and 1.2 Ghz. Well, I tested both Armbian 5.05 and Openelec distros with these settings and the One runs fine, without locks or errors! On armbian I run openssl speed test, which is great because it heats the CPU a lot and also gives some nice benchmark results, telling you if the thermal budget reduced the cores/speed: openssl speed rsa -multi 4 For reference, my One with the dvfs table above was able to do 15.3 signs/s (4096 bit keys) which is an expected value considering that the RPi 2 does 12 signs/s. Anyone noticed this behavior? It looks strange to me that such low voltage can run the One at maximum frequency.