[WiP / Orange Pi One] Support for the upcoming Orange Pi One?

[zurueck]

 

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]

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]

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]

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)

[zurueck]

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]

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

1. adjusting script.bin as outlined in the linux-sunxi wiki to remain always on the lower voltage
2. adjusting MAX_SPEED=1104000 in /etc/default/cpufrequtils (alternatively walking through the cpufreq-ljt-stress-test mentioned above) 
3. let H3 wear a protective helmet

[Igor]

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]

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]

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]

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]

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]

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]

Images updated I also added Ubuntu desktop for ONE ... rest in the evening.

[tkaiser]

 

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

What about reading from script.bin ? It's defined which eth type is used.

[tkaiser]

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]

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]

@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]

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]

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.