• 1
  • 26
  • 27
  • 28(current)
  • 29
  • 30
  • 111
OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 1
(2015-02-04, 19:22)PeaceMkr Wrote: @ Milhouse could you please have a look at this and maybe add these overlays to your next testbuilds?
Would be nice to use gpio-tsop again.


http://forum.kodi.tv/showthread.php?tid=...pid1915093

As far as I'm aware, my builds already contain the overlays - let me know if not. OpenELEC 5.0.1 is missing the overlays (should be fixed in their next official release).
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
New OpenELEC I****** build #0204: RPi / RPi2
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 3.18.5 #1 PREEMPT Wed Feb 4 21:03:43 GMT 2015 armv6l GNU/Linux

# vcgencmd version
Jan 30 2015 18:25:11
Copyright (c) 2012 Broadcom
version d6e004c61a7a749897c482c860d0b2c28196437e (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20150204210254-r20202-gdc87b24 [Build #0204]

# vcdbg log msg 2>&1 | grep DTOK
001523.968: Kernel trailer DTOK property says yes

# Kernel device tree status: Enabled

Based on tip of OpenELEC master (dc87b242, changelog) and tip of XBMC master (3817f094, changelog) with the following modifications: Build Highlights:
  1. Kernel update - possible fix for USB/network failure
  2. Temporarily reverted curl from 7.40.0 to 7.37.1
Build Details:
  1. OpenELEC:
    • vdr-wirbelscan: update to vdr-wirbelscan-0.0.9 (PR:3859, 1 commit, 5 files changed)
    • Amd bisect master (PR:3864, 2 commits, 2 files changed)
    • Mesa: Fix the performance regression in an upstream conform way (PR:3870, 1 commit, 2 files changed)
    • vdr: update to vdr-2.1.8 (6a0fa18e)
    • wetek_play: build non preemptible kernel. (67e32594)
    • new package: libsquish (3c2a33e6)
    • vdr-addon: bump (4.3.7) (fa82a48f)
    • Kodi: Backport PR6312 PR6311 PR 6295 (aef94c02)
  2. XBMC:
    • [RFC] Remove FEH (PR:6010, 1 commit, 6 files changed)
    • Dropped libyajl 1.x (PR:5158, 1 commit, 6 files changed)
    • fixed indentation and style (PR:6336, 1 commit, 1 file changed)
    • Separate actor name and role (PR:5953, 2 commits, 2 files changed)
    • webserver: image resizing (PR:6202, 5 commits, 12 files changed)
    • [gui] fix list control couldn't get the focus after introducing #5804 (PR:6338, 1 commit, 1 file changed)
    • dvdplayer: consider audio stream stalled if queue ran dry (PR:6337, 1 commit, 1 file changed)
    • Fix for font corruption seen on Windows (PR:6342, 1 commit, 1 file changed)
    • [pvr] fix segfault when changing channels via json-rpc (PR:6341, 1 commit, 1 file changed)
    • [core] Support mixed media types in playlists (PR:6332, 1 commit, 1 file changed)
  3. kernel 3.18.y-rebase:
    • New commits in this build:
      • dwc_otg: fixup read-modify-write in critical paths (2e995492)
      • config: Add USBIP (ed1636ed)
  4. Additional commits/pull requests/changes not yet merged upstream:
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2015-02-05, 01:17)Milhouse Wrote: New OpenELEC I****** build #0204:
  • [gui] fix list control couldn't get the focus after introducing #5804 (PR:6338, 1 commit, 1 file changed)
Thanks, it works.

P.s
Some notes about the experimental splash video.
It doesn't work fine for me: during boot up there is a cut in the final part of animation - you remember?
Ok, I've found that the problem is related to core overclocking.

Take a look at these scenarios:

1 - arm_freq=950
over_voltage=6
force_turbo = 0
# core_freq at default

Splash animation works fine.

2 -
arm_freq=950
core_freq=275
over_voltage=6
force_turbo = 0

The splash animation is not completed.
This behavior only occurs at boot time: if I do `systemctl stop kodi; systemctl start kodi` all works fine.

No differences with 'force_turbo=1' and lowering the 'arm_freq'. So, the problem is: i can't touch core_freq.

Note that my model B runs stable at 950/500 - no crash, hangs, etc.

This is my `cat /proc/cmdline`:
Code:
root=/dev/ram0 rdinit=/init BOOT_IMAGE=/kernel.img usbcore.autosuspend=-1 dma.dmachans=0x7f35 bcm2708_fb.fbwidth=1824 bcm2708_fb.fbheight=984 bcm2708.boardrev=0x100000e bcm2708.serial=0xabbce687 smsc95xx.macaddr=B8:27:EB:BC:E6:87 bcm2708_fb.fbswap=1 sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000  boot=LABEL=SYSTEM disk=LABEL=Storage bcm2708.bcm2835_mmc=1 quiet ssh smsc95xx.turbo_mode=N

That's all.
Thanks for watching and, again, sorry for my bad 'gøøgled' English .
(2015-02-03, 20:26)Milhouse Wrote: For anyone looking to upgrade a Pi1 installation for use with Pi2, while using the Pi1, upgrade with the RPi2 tar. Once the upgrade is complete, the system will reboot to a rainbow boot screen (as you're now booting the ARMv7 kernel). Shutdown (pull the power) and transfer the SD card into your Pi2, which will boot normally.

To go back to the Pi1: While using the Pi2, upgrade with the RPi tar. Once the upgrade is complete, the system will reboot to a rainbow boot screen (as you're now using the ARMv6 kernel). Shutdown (pull the power) and transfer the SD card into your Pi1, which will boot normally.

Thank you for posting that, as I've no joy with the (correct, 501) Pi2 image so far, not getting beyond the 4 colour screen.

However, I suggest if anyone finds this update method doesn't progress beyond the initial rainbow, check the existing overclock settings in config.txt, & edit or remove them, otherwise the result may be ARM register dumps for one or more cores, & frame pointer errors, etc. (I edited cmdline.txt to remove "quiet" so I could see boot progress)

It's working fine now thanks.
(2015-02-05, 09:57)slack3r Wrote: Thanks, it works.

Ah yes, forgot to ping you on that one!

(2015-02-05, 09:57)slack3r Wrote: No differences with 'force_turbo=1' and lowering the 'arm_freq'. So, the problem is: i can't touch core_freq.

What about core_freq=500, as 275 is a bit of an unusual core overclock (I believe it prefers to work in multiples of some value).

Also, don't forget you may need to bump over_voltage_sdram when overclocking, particularly when increasing core frequency which may end up driving the SDRAM a bit harder (at least on the Pi1, possibly not so much on the Pi2).

(2015-02-05, 10:09)tvjon Wrote: Thank you for posting that, as I've no joy with the (correct, 501) Pi2 image so far, not getting beyond the 4 colour screen.

However, I suggest if anyone finds this update method doesn't progress beyond the initial rainbow, check the existing overclock settings in config.txt, & edit or remove them, otherwise the result may be ARM register dumps for one or more cores, & frame pointer errors, etc. (I edited cmdline.txt to remove "quiet" so I could see boot progress)

It's working fine now thanks.

Thanks, yes, it's worth noting that a Pi1 overclock isn't guaranteed to work on a Pi2 (and vice versa). I'll mention that in the first post where I've added a migration section.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2015-02-05, 10:20)Milhouse Wrote:
(2015-02-05, 09:57)slack3r Wrote: Thanks, it works.
Ah yes, forgot to ping you on that one!
I saw your and popcornmix posts on github discussion: many thanks for your time.

Quote:What about core_freq=500, as 275 is a bit of an unusual core overclock (I believe it prefers to work in multiples of some value).

Any suggestions about the initial value for core_freq? For example, there is no difference at 280.
(2015-02-05, 10:20)Milhouse Wrote:
(2015-02-05, 09:57)slack3r Wrote: Thanks, it works.

.....

Also, don't forget you may need to bump over_voltage_sdram when overclocking, particularly when increasing core frequency which may end up driving the SDRAM a bit harder (at least on the Pi1, possibly not so much on the Pi2).

(2015-02-05, 10:09)tvjon Wrote: Thank you for posting that, as I've no joy with the (correct, 501) Pi2 image so far, not getting beyond the 4 colour screen.

However, I suggest if anyone finds this update method doesn't progress beyond the initial rainbow, check the existing overclock settings in config.txt, & edit or remove them, otherwise the result may be ARM register dumps for one or more cores, & frame pointer errors, etc. (I edited cmdline.txt to remove "quiet" so I could see boot progress)

It's working fine now thanks.

Thanks, yes, it's worth noting that a Pi1 overclock isn't guaranteed to work on a Pi2 (and vice versa). I'll mention that in the first post where I've added a migration section.

I was a bit worried actually about any consequences of the rather higher overvolt settings for core & sdram, than those suggested for Pi2! However, Raspbian stills boots & appears to work fine, as well as Kodi. It's reassuring, because, for example, as a Raspbian SD image (made for Pi2) works fine in B, B+, & of course, Pi2, it's easy to inadvertently insert a SD card with inappropriate overvolt settings into any RPi. If kodi eventually has dual Arch kernels, the same scenario would apply.

I see you've already updated Post 1; a very comprehensive post, thanks.
(2015-02-04, 22:15)allan87 Wrote:
(2015-02-04, 22:05)da-anda Wrote: Milhouse, in order to test the PVR startup improvement PR on the PI2 we would need a PI2 build without this PR for comparison Wink
You can test against the stock OpenELEC 5.0.1 build.
sure, but how do you know if it's not any of the other changes in Millhouse's build that speeded up something? IMO it should be the very same build with and without that PR
(2015-02-05, 10:58)slack3r Wrote: Any suggestions about the initial value for core_freq? For example, there is no difference at 280.

Not sure what you mean by "initial" value - the default value is 250.

For Pi1, these are the recommended overclocks:

Code:
None:   700MHz ARM, 250MHz core, 400MHz SDRAM, 0 overvolt
Modest: 800MHz ARM, 300MHz core, 400MHz SDRAM, 0 overvolt
Medium: 900MHz ARM, 333MHz core, 450MHz SDRAM, 2 overvolt
High:   950MHz ARM, 450MHz core, 450MHz SDRAM, 6 overvolt
Turbo: 1000MHz ARM, 500MHz core, 500MHz SDRAM, 6 overvolt

This thread is probably more appropriate for this kind of discussion.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2015-02-05, 11:40)da-anda Wrote: sure, but how do you know if it's not any of the other changes in Millhouse's build that speeded up something? IMO it should be the very same build with and without that PR

I've uploaded #0204b test builds, based on #0204 but without PR6246:

RPi
RPi2
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2015-02-05, 09:57)slack3r Wrote:
(2015-02-05, 01:17)Milhouse Wrote: New OpenELEC I****** build #0204:
  • [gui] fix list control couldn't get the focus after introducing #5804 (PR:6338, 1 commit, 1 file changed)
Thanks, it works.

P.s
Some notes about the experimental splash video.
It doesn't work fine for me: during boot up there is a cut in the final part of animation - you remember?
Ok, I've found that the problem is related to core overclocking.

Take a look at these scenarios:

1 - arm_freq=950
over_voltage=6
force_turbo = 0
# core_freq at default

Splash animation works fine.

2 -
arm_freq=950
core_freq=275
over_voltage=6
force_turbo = 0

The splash animation is not completed.
This behavior only occurs at boot time: if I do `systemctl stop kodi; systemctl start kodi` all works fine.

No differences with 'force_turbo=1' and lowering the 'arm_freq'. So, the problem is: i can't touch core_freq.

Note that my model B runs stable at 950/500 - no crash, hangs, etc.

This is my `cat /proc/cmdline`:
Code:
root=/dev/ram0 rdinit=/init BOOT_IMAGE=/kernel.img usbcore.autosuspend=-1 dma.dmachans=0x7f35 bcm2708_fb.fbwidth=1824 bcm2708_fb.fbheight=984 bcm2708.boardrev=0x100000e bcm2708.serial=0xabbce687 smsc95xx.macaddr=B8:27:EB:BC:E6:87 bcm2708_fb.fbswap=1 sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000  boot=LABEL=SYSTEM disk=LABEL=Storage bcm2708.bcm2835_mmc=1 quiet ssh smsc95xx.turbo_mode=N

That's all.
Thanks for watching and, again, sorry for my bad 'gøøgled' English .

I get similar results with RPI 2 build #204

Animation crashes (black screen) on boot but works ok if subsequently rebooted via ssh


arm_freq=900
over_voltage=6
force_turbo=1
Location UK; Media server Windows 7 with ArgusTV 2.3 with TBS6981 DVB-S2 x4 and DVB-T x 2:All network connections cabled on 1Gb router Raspberry Pi2 1GB x 2; RPI 3 x1; PiB+512MB x 3; TV Samsung 55" C8000; AV Denon AVR X2200W
Where has the PPTP VPN client option gone?
(2015-02-05, 15:32)evanspae Wrote: I get similar results with RPI 2 build #204

Animation crashes (black screen) on boot but works ok if subsequently rebooted via ssh


arm_freq=900
over_voltage=6
force_turbo=1

K, thank you for reply.

@Milhouse

I did more tests with all overclock presets, but nothing to do: "touching" core_freq causes the animation issue.
something is wrong starting with #0202 cant mount btrfs storage.... kernel keeps trying f2fs ....
happens on rpi1 and rpi2
Cant see no improvement opening timeline epg with live tv running in background on rpi 2 vs rpi
  • 1
  • 26
  • 27
  • 28(current)
  • 29
  • 30
  • 111

Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 112