Openelec Build for OPI PC and 2 now with HW decoding

tuttiFruttiPi

jeevasv replied at 2016-1-21 17:11
It seems like the current clock settings are  way above the acceptable level causing the SoC to over ...

For clock settings you may take a look at this http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=724&extra=page%3D1. Many Thanks for your builds.
PS - Maybe you can add to your builds script.bin versions for various screen resolutions.

jeevasv

Please find the down-clocked script.bin's at the below location. Replace the right one for your board and then rename and replace it as "script.bin". Please test and report so that these changes can be committed.


https://mega.nz/#F!Yx40iB5K!yZlGjLIffmDv0vc1t_eRIw

jeevasv

For the different resolutions and other settings, probably someone can write a windows/qt gui application so that anyone can point the location select the dfferent setting and click save. The application will convert slice and replace the existing file with right settings and convert it back to bin format. It will be nice mid-term project. No enthusiastic students in this group??

jernej

jeevasv replied at 2016-1-21 10:11
It seems like the current clock settings are  way above the acceptable level causing the SoC to over ...

Did you notice that following parameters are not used anymore:
- boot_clock
- [dram_para] (whole section)

These were used by Allwinner's version of U-Boot. This OpenELEC now uses mainline U-Boot which has hardcoded values.

If you are already at changing script.bin, you could also remove whole g2d section (doesn't exist on H3) and remove fbX_framebuffer_num parameters, because they also are not used in the kernel.

EDIT: Why do you think this values are way out of specs (except maybe for GPU)? They were taken out from recommended linux-sunxi fex: https://github.com/linux-sunxi/s ... ng_orange_pi_pc.fex

pagi

Could somebody help in my case? Is it possible to decode DTS-HD sound on external AV-receiver connected with OPiPC via HDMI?

nightflasher: your option is not working because sound source (OPi in this case) need external DTS hw decorer connected directly via HDMI.

jeevasv

jernej replied at 2016-1-22 04:23
Did you notice that following parameters are not used anymore:
- boot_clock
- [dram_para] (whole se ...

Thanks for rightly pointing this out. And this clearly explains why I am experiencing entirely different thermal behaviour when a same script.bin is tried with our openlec as well as with a regular distro.

But does that mean that the following are not used too? I did't change anything other than the script.bin ddr_freq settings

OpenELEC-opipc3:~ # cat /sys/devices/platform/sunxi-ddrfreq/devfreq/sunxi-ddrfreq/max_freq
480000
OpenELEC-opipc3:~ # cat /sys/devices/platform/sunxi-ddrfreq/devfreq/sunxi-ddrfreq/cur_freq
480000
OpenELEC-opipc3:~ # cat /sys/devices/platform/sunxi-ddrfreq/devfreq/sunxi-ddrfreq/scaling_max_freq
480000
OpenELEC-opipc3:~ # cat /sys/devices/platform/sunxi-ddrfreq/devfreq/sunxi-ddrfreq/scaling_min_freq
408000

I completely agree and accept the method and  findings by the linux-sunxi guys about the cpu/memory clock reliabilty. That is very valid for finding a data point considering only the operation of SoC and RAM. But in our case we don't need to push that hard. Our priorities can be slightly different with additional parameters like Low SoC temperature, Lower power consumption, Reliable Board and peripheral operation etc.

Even though the usb ports are wired straight out of the 5v bus I don't think the connect is really that strong and isolated.

With yesterday's test I'm seeing consistently reliable operation during high bitrate play back using WiFi and I don't think it is a placebo effect. Also I have seen the current consumption with just a  wifi dongle and usb remote fluctuating north of 1000mA with the default script.bin which is not a good sign.

Also I remember vaguely reading a blog post by olimex guys about their finding about the H3 heating issues in their blog post about the ddr_freq being one of the main contributing factor.

I can't find that exact blog post now, probably deleted.

But few info is there in their first blogpost and it's comments.

https://olimex.wordpress.com/201 ... ototypes-are-ready/

fordham

I have done build for OPiPlus this morning. But I am curious the file size is too small.

gz file  size : 710KB (How come such small?
img file : 548MB

Is this correct size? I am out today so need to wait for testing.
Just want to make sure. this is correct result or not. Please see the attached.

jeevasv

fordham replied at 2016-1-22 12:04
I have done build for OPiPlus this morning. But I am curious the file size is too small.

gz file  s ...

Nops. It should be in the range of ~100MB.  Check the build log. Something would have failed during the gzip operation.

lymon

jeevasv replied at 2016-1-22 10:10
Thanks for rightly pointing this out. And this clearly explains why I am experiencing entirely dif ...

Íf you are worried about any thermal/powerconsumption issues, you could also just use a different CPU governor.
Currently it is set to the performance governor, but I am using the ondemand governor, which works fine with this Openelec build and CPU temps hover at around 30-35C at idle, since the kswapd bug was solved.

jernej

jeevasv replied at 2016-1-22 03:10
Thanks for rightly pointing this out. And this clearly explains why I am experiencing entirely dif ...

The best way to check if parameter is used in the kernel is to search through kernel and Allwinner's U-Boot source code. Maybe an U-Boot update is also needed. In the newest code, SDRAM clock is lowered to 624 MHz. Additional thermal improvement would be to use ondemand governor instead of performance.

Please be sure that everything works. Try some 4k videos. Kodi with my patch currently doesn't support 4k resolution but maybe I will add it so someone can test this as the most demanding test. Currently, 4k image is downsized to 1080 in all cases.

EDIT: lymon, you beat me