[mp1111]

I just tried 0430 and see two new PVR addons added. Unfortunately, they are enabled on updating to 0430 and it temporarily borks things if you have another PVR addon (hts, in my case). I think they should come disabled by default. Is this a Kodi issue, OE issue, or OE testbuild issue?

Strange, they're disabled on my systems (but then I don't have PVR enabled at all). Not sure why they would be enabled by default.

Stalker was enabled by default.

I have disabled it and all is good now.

[Milhouse]

New OpenELEC Isengard build #0501: RPi / RPi2
(Supercedes previous build)

Code:

# uname -a
Linux rpi512 4.0.1 #1 Fri May 1 22:21:11 BST 2015 armv6l GNU/Linux

# vcgencmd version
May  1 2015 18:56:06
Copyright (c) 2012 Broadcom
version f5f5ba5f2423c3dff6ccd4ca4b832264cd33f12a (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20150501221749-#0501-g774f426 [Build #0501]

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

# Kernel device tree status: Enabled

Based on tip of OpenELEC master (774f4262, changelog) and tip of XBMC master (71a45cf1, changelog) with the following modifications:

• Includes newclock4 patches
  
• Excludes the OpenELEC fernetmenta patches due to conflicts with newclock4
  
• Excludes the OpenELEC linux-01-RPi_support patch in favour of sourcing these and possibly more recent patches directly from kernel branch rpi-4.0.y
  
• Default setting for "Show RSS Feed" changed to disabled (new installs only) [patch details]
  
• Disabled "Total Duration" in Confluence (see build #0221 for details)
  
• Includes latest dcadec master (9eca5f65)
  
• Includes libcec master (707bd51c)
  
• Includes latest libnfs master (77e3d80f)
  
• Includes latest addons: audiodecoder.modplug (c7e8ca82), audiodecoder.nosefart (c77e5a12), audiodecoder.sidplay (f2e7d985), audiodecoder.snesapu (9fc775b1), audiodecoder.stsound (775c858d), audiodecoder.timidity (bf9ff93d), audiodecoder.vgmstream (0c3a51a2), audioencoder.flac (84acb141), audioencoder.lame (3eb59de9), audioencoder.vorbis (d556a687), audioencoder.wav (40aaedfa), kodi-platform (48bdd985), pvr.argustv (96ee8750), pvr.demo (64749530), pvr.dvblink (5d505b87), pvr.dvbviewer (bd2c01f5), pvr.filmon (413fe9ec), pvr.hts (4bf1a97a), pvr.iptvsimple (000ff75b), pvr.mediaportal.tvserver (6f8ca82e), pvr.mythtv (1ca8fbc1), pvr.nextpvr (1ecbf87c), pvr.njoy (fcd62943), pvr.pctv (0a0924eb), pvr.stalker (118b2efc), pvr.vbox (4449aa55), pvr.vdr.vnsi (3a28e39a), pvr.vuplus (d6abad38), pvr.wmc (37b4b292)
  
• Include patch: Add experimental splash video
  
• Include patch: Enable sdhost driver
  
• Include patch: Add dcadec package for DTS HD-MA support
  
• Include patch: Enable audiodecoder, audioencoder, pvr and visualization addons
  
• Include PR:6732: [pvr] fixed crash when multiple add-on instances get registered
  
• Include PR:6919: added: also hide thumbs for unwatched episodes if option to show plot is off
  
• Revert 02ffc575: ffmpeg/dcadec (performance issue)
  
• Revert 75dd5a44: kodi/dcadec (performance issue)
  
• Revert 78787437: dcadec package (performance issue)
  

Build Highlights:

1. WARNING: Pi1 users may experience very slow booting with this build and the "old" SD card driver
   
2. New firmware.
   
3. New kernel 4.0.1
   
4. Kodi 15.0 beta2
   
5. mmc fixes in 4.0.y
   
6. New experimental SD card driver. WARNING: Test with a fully backed up SD card (just in case!)
   

   When you create next build, can you try adding:
   

   Code:

   dtoverlay=sdhost

   to config.txt. This will use a whole new sdcard driver (it's actually a different peripheral - the one used by the VideoCore side).
   Now the driver is brand new - it works for me and Phil, so please only use it on a new (or backed up) sdcard.
   
   Possible benefits? It gives higher benchmark numbers.
   It won't suffer any of the sdcard corruption of the other driver.
   
   Downsides - not widely tested, so may be buggy.
   
   If it works okay for you, we can suggest brave testers try it.
   
   If you are using an overclock of core_freq and don't have force_turbo then it's recommended to run:
   

   Code:

   echo 1 > /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy

   otherwise the sdcard won't be running at full speed. If core_freq is fixed (either by not overclocking or using force_turbo) then this isn't needed.

   
   I've been using it for a couple of days with a NOOBS (Samsung) 8GB SD card on a RPi2, formatted with ext4, and not had any problems.
   
   Simplistic benchmark results:
   
   Code:

   Stop Kodi:   systemctl stop kodi
Write Test:  dd if=/dev/zero of=/storage/test.dat bs=1M count=1024 && rm test.dat && sync (repeated 3 times)
Read Test:   dd if=/storage/test.dat of=/dev/null bs=1M count=1024 (repeated 3 times)
hdparm Test: hdparm -t --direct /dev/mmcblk0p2 (repeated 3 times)

Results
=======
Standard driver:  Avg. Write 7.2 MB/s   Avg. Read 18.3 MB/s   Avg. hdparm 18.35 MB/s  (core_freq=500, force_turbo=1)
New SD driver:    Avg. Write 7.2 MB/s   Avg. Read 21.5 MB/s   Avg. hdparm 21.83 MB/s  (dtoverlay=sdhost, core_freq=500, force_turbo=1)
New SD driver:    Avg. Write 7.2 MB/s   Avg. Read 11.2 MB/s   Avg. hdparm 11.15 MB/s  (dtoverlay=sdhost, core_freq=500, force_turbo=0)
   
   Enabling force_turbo=1 (or "echo 1 > /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy" - add it to /storage/.config/autostart.sh) looks to be essential to get the best out of the new driver. Hopefully this setting will only be required temporarily and will be taken care of automatically in future, once this new driver becomes the default driver.
   

Build Details:

1. Firmware (May 1):
   • firmware: arm_loader: Set the new sdhost_freq DT parameter, if it exists firmware: sdcard: Move the handling of the clock and its divisor into sdhost
     
2. XBMC:
   • drop useless setting hw/sw decoding (PR:7034, 1 commit, 8 files changed)
     
   • [IMX] probe & push all resolutions we can use (PR:6996, 1 commit, 2 files changed)
     
   • dvdplayer: fixes for ff (PR:7041, 4 commits, 3 files changed)
     
   • bump to 15.0 beta2 (PR:7040, 1 commit, 2 files changed)
     
   • [resource.ui.sounds.confluence] Give it a destiguishing name (PR:6980, 1 commit, 2 files changed)
     
3. dcadec:
   • Makefile: Allow out-of-tree compilation. (19d54e1b)
     
   • Makefile: Add a 'lib' target to compile only the library. (297a2e16)
     
   • Document stream and waveout APIs. (29e1dfb8)
     
   • Clear transition mode array for all subbands. (9eca5f65)
     
4. newclock4:
   • New commits in this build:
     • fixed: broken rfft implementation used in audio visualizer api (50e46b06)
       
     • squash: Add rfft.cpp to utils lib (7f10ebda)
       
     • fixup! squash: Make screensavers use a generic framework. Add a couple more (8dab24c6)
       
5. kernel 4.0.y:
   • New commits in this build:
     • bcm2835-mmc: Add option to disable delays on some writeb calls (aa6b3e63)
       
     • bcm2835-mmc: warn on accesses without spinlock (39315a8e)
       
     • bcm2835-mmc: Add locks when accessing sdhost registers (547b7363)
       
     • squash: sdhost support for faster core clocks, and force-pio mode (fdc5e429)
       
   • Commits no longer in build:
     • vcsm: Use boolean as it cannot be built as module (0e189c13)
       
     • Merge pull request #935 from pranith/rpi-4.0.y (86662dfe)
       
     • fixup! Add 2709 platform for Raspberry Pi 2 (8a38de5a)
       
     • alsa: Ensure mutexes are released through error paths (07a5d16b)
       
     • alsa: Make interrupted close paths quieter (ed9e73db)
       
     • fixup! MMC: added alternative MMC driver (aba1c973)
       
     • fixup! bcm2708 framebuffer driver (07d2cffd)
       
     • fixup! 8192cu needs old wireless extensions (8d7a5a23)
       
     • Revert "Adding bcm2835-sdhost driver, and an overlay to enable it" (447841c3)
       
     • Revert "Add blk_pos parameter to mmc multi_io_quirk callback" (809f8156)
       
     • Merge pull request #945 from notro/dma (f7087bb5)
       
     • Squash: Make delay_after_stop a DT parameter, defaulting to zero (154a21d6)
       
     • Squash: Inlcude ARCH_BCM2835 in depends for bcm2835-sdhost (3140e4a5)
       
     • Merge pull request #947 from notro/mmc (6ee7bbc2)
       

[zaphod24]

I'm trying the new dtoverlay=sdhost but I don't overclock. Is there anything I should look for or see to confirm I'm using the new driver?

[Milhouse]

I'm trying the new dtoverlay=sdhost but I don't overclock. Is there anything I should look for or see to confirm I'm using the new driver?

Look in dmesg:

Old/Standard driver:

Code:

[    1.153071] mmc-bcm2835 3f300000.mmc: mmc_debug:0 mmc_debug2:0
[    1.153081] mmc-bcm2835 3f300000.mmc: DMA channels allocated

New SD driver:

Code:

[    1.176176] DMA channels allocated for the SDHost driver
[    1.220358] Load BCM2835 SDHost driver

So if you execute "dmesg | grep SDHost" and see the two lines immediately above, you're using the new SD driver. If you don't see any result, you're running the old driver.

If you've enabled "dtoverlay=sdhost" but don't see the dmesg entries, upload your vcdbg using "vcdbg log msg 2>&1 | pastebinit" and paste the link. "vcdbg log msg" should include the line "Loaded overlay 'sdhost'" when the overlay is loaded correctly, and should include a message when the load fails.

[jjslegacy]

Had a few minutes to give 501 a try.

At first from reading above I assumed sdhost would be enabled in the build but that doesn't seem to be the case.

Without it enabled the pi was painfully slow - took a good 3-5 minutes to boot.

I updated the config.txt and rebooted and seems back to normal now. This is on a Rpi (not a 2)

Will play some more and see what I get.

HDParm came in at 21.74mb
write test: 17.4MB/s


One thing I did notice:

001190.790: Loading 'kernel.img' from SD card
001509.087: Kernel trailer DTOK property says yes
001509.272: Loading 'bcm2708-rpi-b.dtb' from SD card
001533.361: Loaded overlay 'sdhost'
001557.833: dtparam: arm_freq=950000000
001558.602: Unknown param 'arm_freq' - ignored
001558.625: dtparam: sdhost_freq=450000000


What's up with: 001558.602: Unknown param 'arm_freq' - ignored

*edit - it does seem to take/work though:
# vcgencmd get_config arm_freq
arm_freq=950

[Milhouse]

At first from reading above I assumed sdhost would be enabled in the build but that doesn't seem to be the case.

Sorry if that wasn't clear - no it's not enabled by default, you have to enable it by adding "dtoverlay=sdhost" to /flash/config.txt.

Without it enabled the pi was painfully slow - took a good 3-5 minutes to boot.

I haven't seen slow performance with the "old" driver - are you able to repeat this slow behaviour by disabling "dtoverlay=sdhost"?

HDParm came in at 21.74mb
write test: 17.4MB/s

Your write performance is way better than mine and the 8GB NOOBS cards - for comparison, what is your write performance with the standard driver (assuming it's not chronically slow which is unusual behaviour). Also what make/model is your SD card, just out of interest.

What's up with: 001558.602: Unknown param 'arm_freq' - ignored

Can you paste the contents of your config.txt?

[jjslegacy]

Yes If I remove the dtoveral parameter with multiple reboots it's painfully slow - tried a few times. quite odd.

I will have to switch to an older build to test write performance as I don't think it will show to well with all the slowness.

The card is an Sandisk Extreme - was this: http://www.amazon.com/gp/product/B007M54...UTF8&psc=1
newest version would be here: http://www.amazon.com/SanDisk-Extreme-Me...b_title_ce


Config.txt was built with the kodi program rpi config something or other.

It looks like the arm_freq is changing so not sure why the message.

Config.txt: http://sprunge.us/LGMA

[Milhouse]

I will have to switch to an older build to test write performance as I don't think it will show to well with all the slowness.

#0428 doesn't have any of the new SD driver code. #0429 is when the new driver first appeared (but wasn't entirely safe to use).

I've been able to reproduce the very slow performance in #0501 with dtoverlay=sdhost disabled on a Pi1, however I'm not seeing the same slow performance on a Pi2, so this seems to be Pi1 specific. What's also weird, is that my Pi1 is only using the SD card for /flash, with /system mounted from a USB memory stick.

hdparm on the Pi1 indicates a read performance of 10.04MB/s with the old driver, 16.59MB/s with the new driver (Model B Pi1, 2GB Transcend microSD card in full-size adapter, no Class markings - might pre-date that system...).

Actually, dmesg doesn't look at all healthy on this Pi1 when booting #0501 with the old driver - this would explain the slow booting: http://sprunge.us/SBJO (config.txt, cmdline.txt)

dmesg is clean when booting with the new driver: http://sprunge.us/cQGN

It looks like the arm_freq is changing so not sure why the message.

I've tried booting a Pi1 and a Pi2 with your config.txt, and I can reproduce the "Unknown param 'arm_freq' - ignored" message with a Pi1, but not the Pi2. Odd.

[zaphod24]

I'm trying the new dtoverlay=sdhost but I don't overclock. Is there anything I should look for or see to confirm I'm using the new driver?

Look in dmesg:

Old/Standard driver:

Code:

[    1.153071] mmc-bcm2835 3f300000.mmc: mmc_debug:0 mmc_debug2:0
[    1.153081] mmc-bcm2835 3f300000.mmc: DMA channels allocated

New SD driver:

Code:

[    1.176176] DMA channels allocated for the SDHost driver
[    1.220358] Load BCM2835 SDHost driver

So if you execute "dmesg | grep SDHost" and see the two lines immediately above, you're using the new SD driver. If you don't see any result, you're running the old driver.

If you've enabled "dtoverlay=sdhost" but don't see the dmesg entries, upload your vcdbg using "vcdbg log msg 2>&1 | pastebinit" and paste the link. "vcdbg log msg" should include the line "Loaded overlay 'sdhost'" when the overlay is loaded correctly, and should include a message when the load fails.

Thanks, looks like I'm using the new driver:

[ 1.321028] DMA channels allocated for the SDHost driver
[ 1.366202] Load BCM2835 SDHost driver

[User 209257]

Here are my results...I haven't had any time with the latest Kodi yet, so I can't speak for stability yet.

Code:

Results
=======
Standard driver:  Avg. Write 15.2 MB/s   Avg. Read 16.4 MB/s   Avg. hdparm 18.02 MB/s  (core_freq=525, force_turbo=1, devel-20150426210607-#0426-g160dc2d)
New SD driver:    Avg. Write 15.47 MB/s   Avg. Read 17.2 MB/s   Avg. hdparm 19.37 MB/s  (dtoverlay=sdhost, core_freq=525, force_turbo=1, devel-20150501221805-#0501-g774f426)

RPI 2 + Patriot 16GB Class 10 -> http://www.patriotmemory.com/product/det...28&type=15 (This may or may not be the same card I'm using, I bought it several years ago and this is the only one on Patriot's site that matches the specs)

[DistantSynAck]

I did a soft reset on my RPi and noticed all the PVR clients are enabled by default.

[Milhouse]

I did a soft reset on my RPi and noticed all the PVR clients are enabled by default.

I wonder if it's this from #0426:

• XBMC:
  • Cleanup addon (un)installing and enabling/disabling (PR:6681, 4 commits, 28 files changed)
    

Edit: Nope, booting #0425 with a fresh .kodi results in all the PVR addons being enabled too. I've gone back as far as #0315 and that has them enabled too, so this is probably a long standing issue or more likely, "by design" as, to be honest, the PVR addons are not meant to be built with the rest of OpenELEC - I only build them to a) confirm the addons actually build and b) ensure the latest addons are available with each release since the upstream downloadable addons will often be out of date (resulting in problems unrelated to the changes being tested in these builds, and we'll lose a bunch of testers as I'm not going to support those upstream PVR addons as well).

I don't know if this is a bug or not - I can't think of a good reason why the PVR addons should be enabled by default - but without a fix coming from somewhere, my only option right now is to stop building all of the PVR addons, which I'm more than happy to do... but PVR users will be cut off.

If you can disable the PVR addons that would be great, as it will only be a problem on fresh installs, or whenever a new PVR addon is added to the build (which shouldn't be that often).

[Calcifer-73]

Hello Milhouse,

Certainly a dumb question but why are you writing "bump to 15.0 beta2" in the changelog meanwhile on the Kodi website beta 1 was just out.

[Heiko123]

Hello,

I would like test my sd-card, but after "Write Test: dd if=/dev/zero of=/storage/test.dat bs=1M count=1024 && rm test.dat && sync" it is deleted the "test.dat,
so I can not test "Read Test: dd if=/storage/test.dat of=/dev/null bs=1M count=1024"

1024+0 records in
1024+0 records out
1073741824 bytes (1.0GB) copied, 384.643601 seconds, 2.7MB/s

/dev/mmcblk0p2:
Timing O_DIRECT disk reads: 30 MB in 3.16 seconds = 9.48 MB/sec

[fab67]

Hello Milhouse,

Certainly a dumb question but why are you writing "bump to 15.0 beta2" in the changelog meanwhile on the Kodi website beta 1 was just out.

Because latest kodi commits belongs now to Beta2 -> https://github.com/xbmc/xbmc/commit/f946...f3bd2da1d7