zurueck Posted February 17, 2016 Posted February 17, 2016 I'm starting to think that I recieve a defective board. Which distributive, uboot and script.bin you use? Please give me the links, I will compare with my device. By the way, it can be a problem with overheating because of not good quality power supply? Maybe I should try another.
tkaiser Posted February 17, 2016 Author Posted February 17, 2016 I have OPI ONE and CPU temp is 44C with no load (46C in start) When you're using the Armbian image then please see above. The thermal read-out is too low so in reality it will be a bit higher. But how do you know that the voltage is higher than 0.2V? See above. I use the very same image on Orange Pi PC (where we know that voltage regulation should work as expected) and Orange Pi One and only exchange script.bin in between. On the One I get both higher consumption and temperatures (the latter being wrong but that doesn't matter since it's a relative difference of about ~20°C!). The only real source for such a difference is Vcore voltage. And the possible solution if this is really the case would be to deactivate the higher voltage and to stay with the base voltage (not 1.1V as assumed but close to 1.3V instead). The last hour a couple of small heatsinks arrived so I might be able to try this out now. Compare with: http://linux-sunxi.org/Hardware_Reliability_Tests#Reliability_of_cpufreq_voltage.2Ffrequency_settings I just try the following out and it seems to work (staying at the lower voltage level regardless which cpufreq setting I use): [dvfs_table] pmuic_type = 1 pmu_gpio0 = port:PL06<1><1><2><1> pmu_level0 = 1270 pmu_level1 = 1270 max_freq = 1200000000 min_freq = 648000000 LV_count = 2 LV1_freq = 1200000000 LV1_volt = 1270 LV2_freq = 648000000 LV2_volt = 1270 If reliability at 1200 MHz can be confirmed then this is also a clear sign that Vcore voltage must be higher than 1.1V or let's better say pretty close to 1.3V!
tkaiser Posted February 17, 2016 Author Posted February 17, 2016 Ok, really bad news TL;DR: The voltage regulator on Orange Pi One can be switched through GPIO settings between just two Vcore voltages (the higher the voltage, the higher the possible clockspeed up to an limit by specs of 1.4V). According to Orange Pi forums the Vcore voltage should be switched between 1.1V and 1.3V for clockspeeds above 648 MHz. But the real voltages used seem more like ~1.3V and ~1.5V clearly exceeding the 1.4V maximum. I disabled the higher Vcore voltage with the following fex settings: [dvfs_table] pmuic_type = 1 pmu_gpio0 = port:PL06<1><1><2><1> pmu_level0 = 1270 pmu_level1 = 1270 max_freq = 1200000000 min_freq = 648000000 LV_count = 2 LV1_freq = 1200000000 LV1_volt = 1270 LV2_freq = 648000000 LV2_volt = 1270 Then I had to use a heatsink and fan since otherwise thermal throttling prevented testing the 1.2 GHz clockspeed. With fan I was able to test through all cpufreq settings and the test PASSED (which is a clear sign that Vcore voltage must be close to 1.3V and not 1.1V): root@orangepione:/var/lib/cpuburn-arm# ./cpufreq-ljt-stress-test The cjpeg and djpeg tools from libjpeg-turbo are not found. Trying to download and compile them. CPU stress test, which is doing JPEG decoding by libjpeg-turbo at different cpufreq operating points. Testing CPU 0 1536 MHz SKIPPED 1440 MHz SKIPPED 1344 MHz SKIPPED 1296 MHz SKIPPED 1200 MHz ............................................................ OK 1104 MHz ............................................................ OK 1008 MHz ............................................................ OK 912 MHz ............................................................ OK 816 MHz ............................................................ OK 720 MHz ............................................................ OK 648 MHz ............................................................ OK 600 MHz SKIPPED 504 MHz SKIPPED 480 MHz SKIPPED 408 MHz SKIPPED 312 MHz SKIPPED 240 MHz SKIPPED 120 MHz SKIPPED 60 MHz SKIPPED Testing CPU 1 1536 MHz SKIPPED 1440 MHz SKIPPED 1344 MHz SKIPPED 1296 MHz SKIPPED 1200 MHz ............................................................ OK 1104 MHz ............................................................ OK 1008 MHz ............................................................ OK 912 MHz ............................................................ OK 816 MHz ............................................................ OK 720 MHz ............................................................ OK 648 MHz ............................................................ OK 600 MHz SKIPPED 504 MHz SKIPPED 480 MHz SKIPPED 408 MHz SKIPPED 312 MHz SKIPPED 240 MHz SKIPPED 120 MHz SKIPPED 60 MHz SKIPPED Testing CPU 2 1536 MHz SKIPPED 1440 MHz SKIPPED 1344 MHz SKIPPED 1296 MHz SKIPPED 1200 MHz ............................................................ OK 1104 MHz ............................................................ OK 1008 MHz ............................................................ OK 912 MHz ............................................................ OK 816 MHz ............................................................ OK 720 MHz ............................................................ OK 648 MHz ............................................................ OK 600 MHz SKIPPED 504 MHz SKIPPED 480 MHz SKIPPED 408 MHz SKIPPED 312 MHz SKIPPED 240 MHz SKIPPED 120 MHz SKIPPED 60 MHz SKIPPED Testing CPU 3 1536 MHz SKIPPED 1440 MHz SKIPPED 1344 MHz SKIPPED 1296 MHz SKIPPED 1200 MHz ............................................................ OK 1104 MHz ............................................................ OK 1008 MHz ............................................................ OK 912 MHz ............................................................ OK 816 MHz ............................................................ OK 720 MHz ............................................................ OK 648 MHz ............................................................ OK 600 MHz SKIPPED 504 MHz SKIPPED 480 MHz SKIPPED 408 MHz SKIPPED 312 MHz SKIPPED 240 MHz SKIPPED 120 MHz SKIPPED 60 MHz SKIPPED Overall result : PASSED I let 4 threads cpuburn-a7 run and started then cpufreq-ljt-stress-test. It would be good if other users can confirm whether their overheat problems disappear and if people with access to the Orange Pi forums warn the users there in the few relevant threads (I won't look into it since forum/vendor suck too much) BTW: This is not about overclocking but overvolting. You need high Vcore voltage to let the SoC run reliably at high clockspeeds. But what we experience here is that we thought our boards are able to switch between two sane voltage settings but in reality the 'lower' one is already on an upper limit and the upper one clearly exceeds tolerable specifications if cpufreq is at 720MHz or higher with the common fex settings developed/used the last days.
tkaiser Posted February 17, 2016 Author Posted February 17, 2016 Yes, no screen console @moment. Armbian is using standard opensource u-boot which currently does not support HDMI console. Can confirm this. To check whether my display is working correctly I used loboris' Ubuntu 15.04 Mate image and connected it (with script.bin fixes for DVI applied). Worked flawlessly. Then I made his image 'hybrid': cd /tmp && wget http://kaiser-edv.de/tmp/4U4tkD/kernel_5.01_h3.tgz tar xf kernel_5.01_h3.tgz dpkg -i linux-headers-sun8i_5.01_armhf.deb linux-image-sun8i_5.01_armhf.deb mkimage -A arm -O linux -T kernel -C none -a 0x40008000 -e 0x40008000 -n "Armbian-sun8i-3.4.110" -d /boot/vmlinuz-3.4.110-sun8i /media/boot/uImage.armbian shutdown -r now And loaded our kernel in u-boot manually. Et voilà : HDMI works with '2011.09-rc1' and our latest kernel. And surprisingly the SoC's temperature is now also reported in the 'usual' range and not way off as when booting mainline u-boot (currently testing) 2
zurueck Posted February 18, 2016 Posted February 18, 2016 Even the use of low voltage at low frequencies leads to overheating(65-75 degrees in chromium and aptitude launched with upgrade). Much more powerful Atom Z3735F and qualcomm 801-810 are heated less. Awful to energy-efficient A7 heated so. I will think about replacing the radiator to a larger one.
tkaiser Posted February 18, 2016 Author Posted February 18, 2016 Awful to energy-efficient A7 heated so. We had to learn the last months that the primary source of H3 heat problems was overvolting (it seems H3 is made in a 40nm process like the A64 -- this seems to be the source of overheating problems). When these settings were fixed on Orange Pi Plus/2/PC then everything was ok (without a heatsink it was already a bit hard to trigger thermal throttling or to get close to 80°C or beyond). The voltage regulator accessible through I2C seemed to switch voltages correctly. With the One the situation changed: Here we have a new step-down converter used. Its Vout voltage can be adjusted using two resistors: Vout=0.6*(1+R1/R2). And the H3 seem to be able to switch between two states (U53 - SY8113b, Q5 - switching MOSFET on the PCB). Since the vendor doesn't comment on anything and didn't release schematic and no one took a Multimeter and measured the various testpoints on OPi One's PCB we can now just speculate about the values of these resistors and the real voltages used. But thermal and consumption values indicate that the voltages are way off and exceed 1.1/1.3V significantly. And this would explain why you're running in overheating situations. Yesterday I did a test with the same OS image (just exchanged script.bin in between) testing dual voltages on Orange Pi One, then only the lower voltage and then the same setup on Orange Pi PC where voltage switching works as it should: If you compare the thermal values for the same test (sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=4) then it's obvious that the lower voltage used on my Orange Pi One must already exceed the highest voltage on the Orange Pi PC. And if you activate voltage switching on the One it gets even worse. And there's an important thing to mention: Currently with Armbian we have a situation where the internal thermal readouts are a bit off (reported too low), so thermal throttling jumps in too late (or in other words: internal temperatures are already higher than reported). Igor just merged my last pull request and might already update the Armbian image for the One. In the meantime I strongly recommend adjusting script.bin as outlined in the linux-sunxi wiki to remain always on the lower voltage adjusting MAX_SPEED=1104000 in /etc/default/cpufrequtils (alternatively walking through the cpufreq-ljt-stress-test mentioned above) let H3 wear a protective helmet
Igor Posted February 18, 2016 Posted February 18, 2016 New images are recompiling and uploading ... less than one hour from now will be online. I only own Orange Pi+ and it's performing very good regarding temperature. (If using heat sink) Readings are more or less correct 30 - 31°C on idle, max reading while stressing was only 38°C with CPU clocking 0.480-1.3 GHz I am using only a small heat sink. Temperatures were measured with low cost Multimeter but it's accurate enough for our case.
tkaiser Posted February 18, 2016 Author Posted February 18, 2016 I only own Orange Pi+ and it's performing very good regarding temperature. (If using heat sink) Readings are more or less correct 30 - 31°C on idle, max reading while stressing was only 38°C with CPU clocking 0.480-1.3 GHz These values are a bit too low (you'll realize with RPi-Monitor easily since if you power on the board the temperature 20 seconds after a cold boot is reported as being below ambient temperature) and I doubt that measuring the surface of a heatsink has anything to do with the SoC's core. Unlike the older SoCs (A10/A20) where a thermal sensor was included more by accident these sensors are now there for a reason: Throttling. But you're right: With Plus/PC/2 it's not a problem when using our dvfs settings (and a heatsink when always running under full load). The Orange Pi One is affected since it seems that Vcore voltage is way too high, especially when we allow to use the upper voltage. I'm not that much concerned regarding Plus/PC but the One instead... And thx for uploading the images again!
Igor Posted February 18, 2016 Posted February 18, 2016 I know. My measurements are just little better than with thumb but it shows that we made a good job on boards with a proper voltage regulator. Some further fine tuning is expected. BTW. New images are up.
tkaiser Posted February 18, 2016 Author Posted February 18, 2016 BTW. New images are up. You've been too fast! Again! Since HDMI is still not working. And I found out why 15 minutes ago: All that's needed is just removing "disp.screen0_output_mode=1920x1080p60" from boot.cmd prior to creating boot.scr. Then HDMI works. There's still a bit to do. I'm already preparing h3disp (an utility that's only useful with 3.4.x since it will take script.bin and modify [hdmi_para] section to support different HDMI resolutions, patch the fex and convert back -- to be useable with Xunlong/loboris images too) but will first have a look into OpenELEC's/jernej's last patches that are display related since it would also be great to get fbset support to be able to use any display resolution possible. But (re-)releasing the images with working HDMI would be great since from my point of view with the applied fixes for Orange Pi One they're pretty useable already (especially to let people test advanced stuff like Mali/CedarX acceleration)
Igor Posted February 18, 2016 Posted February 18, 2016 Haha OK, well ... for screen I am willing to do this again at once. I'll add other two remaining boards too - I have a bit tight time scale so this might not be finished until evening.
tkaiser Posted February 18, 2016 Author Posted February 18, 2016 For anyone a bit experienced who wants to upgrade Igor's 3.4.110 test images for Orange Pi PC, Plus or One. It's necessary to install a new kernel and also replace script.bin! Just do the following as root: cd /tmp && wget http://kaiser-edv.de/tmp/4U4tkD/kernel_5.02_h3_unified.tgz tar xf kernel_5.02_h3_unified.tgz dpkg -i *5.01_armhf.deb Then choose the appropriate script.bin variant (see the md5sums section below) and on the Orange Pi One for example do a cd /boot/bin && wget http://kaiser-edv.de/tmp/4U4tkD/orangepione.bin ln -sf /boot/bin/orangepione.bin /boot/script.bin To get HDMI working (only necessary for 5.00 images and not 5.01/5.02 any more) edit /boot/boot.cmd and remove "disp.screen0_output_mode=1920x1080p60". Afterwards do a mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr Users of Orange Pi One should also adjust MAX_SPEED=1104000 in /etc/default/cpufrequtils After the following reboot you have almost all latest fixes, working HDMI (on 5.00 images) and are more safe regarding overvolting/overheating on the OPi One. MD5 sums: b5c4598e2065b7d054d295bd215adc0b kernel_5.01_h3_unified.tgz cae217b535a99234753199fa8a91334e kernel_5.02_h3_unified.tgz abc614039eb06e3d28465c22889b7eb4 orangepi2.bin ce89743c3d18e53419099e557d6566ee orangepilite.bin b8397d78f76f1517fd496fae7b4b7bc2 orangepione.bin 75730548ba436e0c02e02a71d6daa537 orangepipc.bin d8ee34263293ed14d4dce3f5baa5dce0 orangepiplus.bin
Igor Posted February 18, 2016 Posted February 18, 2016 Images updated I also added Ubuntu desktop for ONE ... rest in the evening.
tkaiser Posted February 18, 2016 Author Posted February 18, 2016 Anyone using a HDMI-to-DVI converter? Unless h3disp utility is ready please remember that we provide for every H3 based OrangePi also a script.bin setting that takes that into account: /boot/script.bin -> /boot/bin/orangepione_hdmi2dvi.bin EDIT: LOL, just realised that I cannot do anything with this desktop image since Orange Pi One refuses to recognise my keyboards and mice (all from Apple), other USB peripherals work flawlessly. And then after a while CPU utilisation increases to approx. 25% caused by these two processes: And then I had to realise how ineffective screensavers are: 2976 nobody 30 10 4244 2072 1192 R 46.7 0.4 2:31.64 fiberlamp 1307 root 20 0 44216 26244 4280 S 40.9 5.2 1:59.50 Xorg I hope someone more familiar with this desktop stuff than me might be able to help. My use case for Orange Pi One is clearly headless operation
Da Alchemist Posted February 18, 2016 Posted February 18, 2016 I just tested the new Image. HDMI Sound is only on two Channels, speaker-test -D hw:1 -c 8 gives some downmix on left and right, like on all other Kernels, i2s support is not available (found it first on this Image http://www.diyaudio.com/forums/pc-based/285427-i2s-connection-orange-dac-4.html#post4614528). This image is booting much faster than all Images i have tested before.. Regards
tkaiser Posted February 18, 2016 Author Posted February 18, 2016 HDMI Sound Thx, for the feedback. Nice to hear that Audio works somehow In case you want to see improvements in this area feel free to join development. Links to other OS images are rather useless. All we could deal with are clean, tested patches that can be added to our build system at the moment. It should also be noted that most of the core devs aren't that much focused on topics like Audio, video and desktop/GUI. So any help welcome from people familiar with this
Da Alchemist Posted February 18, 2016 Posted February 18, 2016 I am sorry but i am a noob to kernel developments, i just wanted to point out, what modules are missing, or better which i would like to see . (my main focus is on audio ...) I will check your improvements from time to time. So keep on with your excellent work. Regards
tkaiser Posted February 18, 2016 Author Posted February 18, 2016 I am sorry but i am a noob to kernel developments, i just wanted to point out, what modules are missing, or better which i would like to see . Being a kernel developer is absolutely no requirement to contribute. Since you know who has made improvements in the area you're interested in you could simply ask there what has been changed to get feature XY to work (it's a basic requirement to publish sources when someone publishes an image based on GPL). This alone makes it a lot easier to integrate stuff and to provide you with a test version (it's really that easy in the meantime with Armbian -- the other Armbian guys did a really great job). But please understand that we're neither able nor willing to register in any forum on this planet to search for solutions for other people's problems. Even the official 'Orange Pi forum' is too much for me now My motivation to bring Armbian to H3 in this state (relying on the old kernel until mainline support for H3 is ready) is simply to be able to use Orange Pi H3 boards without having to rely on OS images from the manufacturer or someone else ("AcidBurns's image that's based on Jacer's image that's based on loboris'..."). I want to be able to freely customize the OS environment I'm used too. And that's now possible. And there's still a lot of room for improvements BTW: Since I mentioned loboris above... Kudos to his great work even if I never liked his overclocking attempts. But without relying on his, ssvb's and yann|work's fixes Armbian@3.4.110 simply wouldn't be available for H3 devices yet.
Igor Posted February 18, 2016 Posted February 18, 2016 I'll make one extended config now that you will be able to use apple keyboard BTW, Have you try to boot those with internal PHY if patch is present? From first quick look this should be or it was designed to be selected from script.bin?
tkaiser Posted February 18, 2016 Author Posted February 18, 2016 Have you try to boot those with internal PHY if patch is present? From first quick look this should be or it was designed to be selected from script.bin? Just recompile the kernel without my reverse patch to be able to try out. Get back to you in a few minutes. There's also one interesting u-boot patch for all H3 Orange Pi != One: http://lists.denx.de/pipermail/u-boot/2016-February/245097.html After a cold boot the SY8106A uses 1.2V which is safe with u-boot's default 1008 MHz bootclock. But in case someone did a reboot with low dvfs settings in kernel then a rather low voltage might be set when u-boot is booting which might leading to stability problems in early boot stage (without this patch only the kernel can adjust voltage back to sane values which might never happen if u-boot fails)
tkaiser Posted February 18, 2016 Author Posted February 18, 2016 Just recompile the kernel without my reverse patch to be able to try out. Get back to you in a few minutes. Nope. Without the patch (Plus settings) and the following script.bin contents I get no network and boot time is rather long: [gmac0] gmac_used = 2 gmac_power1 = But what about Zador's idea to create an empty lib/patch/kernel/sun8i-default/orangepiplus/opi_pc_one_disable_gmac.patch? You're already thinking about upgrade procedures later?
zador.blood.stained Posted February 18, 2016 Posted February 18, 2016 But what about Zador's idea to create an empty lib/patch/kernel/sun8i-default/orangepiplus/opi_pc_one_disable_gmac.patch? You're already thinking about upgrade procedures later? It's more a temporary workaround for testing. If kernels require different set of patches, they should be separated to have different names, otherwise you won't be able to set up apt repository for upgrading.
Igor Posted February 18, 2016 Posted February 18, 2016 OK, then perhaps adjusting / fixing the driver if we got skill set / resources for doing it ... since temporally solutions are bringing new logic to the kernel families naming - kernel sub versions: sun8i, sun8i-gmac ... which somehow doesn't sound or look cool Edit: There's also one interesting u-boot patch for all H3 Orange Pi != One: http://lists.denx.de...ary/245097.html It's already part of 2016.01
zador.blood.stained Posted February 18, 2016 Posted February 18, 2016 OK, then perhaps adjusting / fixing the driver if we got skill set / resources for doing it Looking at the patch - quick and dirty solution would be adding module parameter and setting it in u-boot script (kernel command line) since this looks like a built-in module. Quick - because it's 3 4 lines of code. Dirty - because there are no schematics to confirm that it's the only thing that is needed and we don't have proper procedure for updating boot script yet.
Igor Posted February 18, 2016 Posted February 18, 2016 What about reading from script.bin ? It's defined which eth type is used.
tkaiser Posted February 18, 2016 Author Posted February 18, 2016 It's already part of 2016.01 [sY8106A u-boot patch] I don't think so since it's from a week ago and 'sources/u-boot/v2016.01# find . -name sy8106a.c' returns nothing. I just checked the GMAC thing again: http://irclog.whitequark.org/linux-sunxi/search?q=nick%3Ayann%7Cwork (script.bin changes were necessary to make the external PHY patch work but no one looked into -- except Zador now -- whether there's a single kernel binary solution) EDIT: Just looked into Jernej's repo. It seems he applies the GMAC patch for every board but his Kconfig differs: Plus vs. PC
zador.blood.stained Posted February 18, 2016 Posted February 18, 2016 Looking at fex files and patch code again: What if we add entry like this [gmac_phy_power] gmac_phy_power_en = port:PD06<1><default><default><0> with some unused GPIO and disable "opi_pc_one_disable_gmac.patch"? Currently GMAC driver probably doesn't like missing entry in script.bin and returns from geth_sys_request with error code. type = script_get_item("gmac_phy_power", "gmac_phy_power_en", &item); if (SCIRPT_ITEM_VALUE_TYPE_PIO != type) { pr_err("script_get_item return type err\n"); return -EFAULT; So driver wants GPIO - let's give something to it
Igor Posted February 18, 2016 Posted February 18, 2016 @Thomas [sY8106A u-boot patch] I don't think so since it's from a week ago and 'sources/u-boot/v2016.01# find . -name sy8106a.c' returns nothing. My bad. I guess it's time to go off for a while Patch is working with DEV branch ... add BOOTBRANCH="" to userpatches/lib.config that it u-boot will compile without TAG and try ... EDIT: Just looked into Jernej's repo. It seems he applies the GMAC patch for every board but his Kconfig differs: Plus vs. PC Just different solution. We still have must have two separate kernel bin. BTW: I am meeting Jernej next week. @Zador Let's try. I mean, Thomas should try it out ...
tkaiser Posted February 18, 2016 Author Posted February 18, 2016 Thomas should try it out ... Puh, still busy doing thermal measurements with the One as promised to ssvb yesterday. If you give me a GPIO setting to try with I will try but I refuse to read through pin assignments today BTW: BOOTBRANCH="" seems to work, thx. Let's see what it breaks later
zador.blood.stained Posted February 18, 2016 Posted February 18, 2016 If you give me a GPIO setting to try with I will try but I refuse to read through pin assignments today Something like PL08 or PL09 looks unused enough in all orange*.fex files and in H3 datasheet.
Recommended Posts