•   
  • 1
  • 72
  • 73
  • 74(current)
  • 75
  • 76
  • 174
  •   
  Thread Closed
OpenELEC Testbuilds for RaspberryPi
(2013-01-28, 14:01)MilhouseVH Wrote:
(2013-01-28, 13:11)pplucky Wrote: Any downside of moving these files manually (other than MD5 not being checked)?

You'll also need to also extract the third-party binaries (bootcode.bin, start_elf, fixup.dat), in addition to KERNEL/kernel.img and SYSTEM.
If it is updating, it means the partition already contains it. In that case, do I also need to do that? Where should I extract it from then?
(2013-01-28, 14:04)pplucky Wrote: If it is updating, it means the partition already contains it. In that case, do I also need to do that? Where should I extract it from then?

Yes, as they sometimes change from one release to the next (for instance in the last few days, updated thirdparty binaries were included in all OpenELEC releases).

If you let OpenELEC update itself, these third party binaries will be extracted from within the new SYSTEM file.

If you are updating manually, you need to copy them yourself to the SD card. If you are downloading the tar.bz2 file, they should be in a folder called 3rdparty/bootloader (not sure about the zip packages, but probably similar).
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.
(2013-01-28, 13:06)rbej Wrote: My new custom build.

http://www.mediafire.com/?10456ccz13ard

...

That's a really good job, working perfectly on my 512Mb Pi!
Thanks for that!
Would you be able to produce a build including an mpd server? I had a look on tutos for creating an add-on or modifying openelec sources, but I don't understand anything..
(2013-01-28, 12:32)MilhouseVH Wrote: Not sure if those items are related, as with my own builds h264 returns to 0MHz after playback ends, though bogomips is calculated as 666 despite running a 1GHz overclock.
Weird the official RC2 from openelec.tv does not. Return to 0 that is. At any point. Builds up to RC2 did.
Oh well..
(2013-01-28, 13:11)pplucky Wrote:
(2013-01-28, 10:26)MilhouseVH Wrote:
(2013-01-28, 10:01)pplucky Wrote: Just like me. I fixed it by changing the whole STORAGE partition to an USB pen instead and I didn't have a single problem after that.

Yes, but even when using USB it's quite likely you'll be left with an unbootable system if you experience these mmc0 errors when your Pi boots in order to apply a software update (updates to the SD-based kernel.img, bootcode.bin etc.). The only solution (other than avoiding/eliminating the mmc0 errors) is to move /storage to USB/NFS, and apply SD-card based updates manually using a PC (ie. disable auto-update, and never allow the Pi to write to the SD card, basically).
Yes, that is exactly what happens to me... Corruption after each update!

Does this mean that if I either disable the overclock before updating (my past experience shows that this ALWAYS cause corruption in SD card) or manually move SYSTEM and KERNEL files to the SD SYSTEM partition (via PC), it should work?

Any downside of moving these files manually (other than MD5 not being checked)?

When using the USB, the only time the SD should be written to (with the risk of corruption) is when updating, so disabling the overclock before updating should be all that's required. I don't see any advantage in moving the files manually, as that still involves writing to the SD and therefore needs the overclock disabling first.

What I'd like to see ideally to make this less complex is an automated method where it disables the overclock, reboots (now not overclocked) and installs the updates, reboots again and re-enables the overclock and reboots a last time (now with the overclock re-enabled), to save the user having to do all this manually.
The problem being that the Pi may already be overclocked by the time it works out it needs to perform an update of the SD card (certainly if initial_turbo is specified) and would then have to modify config.txt in an overclocked state - thus writing to the SD card, and potentially corrupting config.txt - in order to disable overclocking for the next boot...

It seems that writing to the SD card is pretty safe provided that it has been initialised correctly, and the fact that it sometimes isn't initialised correctly is the crux of the problem. Automatically rebooting the Pi when the SD card isn't initialised properly is the workaround that works for me.
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.
(2013-01-28, 16:11)MilhouseVH Wrote: The problem being that the Pi may already be overclocked by the time it works out it needs to perform an update of the SD card (certainly if initial_turbo is specified) and would then have to modify config.txt in an overclocked state - thus writing to the SD card, and potentially corrupting config.txt - in order to disable overclocking for the next boot...
You can disable overclock at runtime by switching governor from ondemand to conservative.
Either suggest people with sdcard corruption problems avoid initial_turbo, or include a (up to 60 second) delay before updating firmware if initial_turbo is in config.txt.

(2013-01-28, 16:11)MilhouseVH Wrote: It seems that writing to the SD card is pretty safe provided that it has been initialised correctly, and the fact that it sometimes isn't initialised correctly is the crux of the problem. Automatically rebooting the Pi when the SD card isn't initialised properly is the workaround that works for me.
Have you changed the kernel, or the init script to do this? Can you post your change?
(2013-01-28, 16:17)popcornmix Wrote: Have you changed the kernel, or the init script to do this? Can you post your change?

Just the init script. The full patch is here (it should be in github too, but it's playing up for me right now). The patch also includes fixes for NFS and USB auto-update.

As for the anti-corruption check, it's a right old hack, but seems to reliably detect potential SD card problems.

Rather than rely on dmesg to detect SD problems (which isn't included by default in the initramfs build, and the relevant mmc0 messages appear too late anyway, see boot log), the modified init script (function media_check) times how long it takes to write a ~1MB file to the FAT partition, and reboots if it takes too long. This all happens before the ext4 partition is mounted, which usually ends up being corrupted if the SD card is misbehaving.

In normal circumstances writing a 1MB file to SD card should take about 1/10th of a second, but when the SD card is not initialised correctly (which I believe leads to later file and/or partition corruption), the same file takes up to 40 seconds to write. Whenever the write takes longer than 5000 milliseconds (which is the default value for iotimeout, change it in cmdline.txt, or disable the check entirely with iotimeout=0), then the Pi will reboot and keep rebooting until it can write the file in under 5 seconds (it normally only takes one boot, very occasionally I've seen it need two reboots).

When the SD card is working correctly, you'll not notice any difference in the boot sequence (you might notice "Media check - please wait..." flash on the screen), but on those occasions when the SD card is not working correctly you'll experience a 10-40 second delay, and an extra reboot, but at least your partition won't be trashed, and you can still auto-update with some degree of certainty that it will actually work.

It's obviously not an ideal solution, but that would be the elimination of the initialisation problem from happening in the first place!

Somewhat counter-intuitively the fix involves writing a file to the FAT partition, but this seems to be more resilient than ext4, although often the files that are written when the SD card is misbehaving - such as kernel.img, bootcode.bin, etc. - will be corrupt, fortunately I'm not really interested in the integrity of the 1MB test file, only how long it takes to write.
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.
(2013-01-28, 16:11)MilhouseVH Wrote: The problem being that the Pi may already be overclocked by the time it works out it needs to perform an update of the SD card (certainly if initial_turbo is specified) and would then have to modify config.txt in an overclocked state - thus writing to the SD card, and potentially corrupting config.txt - in order to disable overclocking for the next boot...

It seems that writing to the SD card is pretty safe provided that it has been initialised correctly, and the fact that it sometimes isn't initialised correctly is the crux of the problem. Automatically rebooting the Pi when the SD card isn't initialised properly is the workaround that works for me.

Ah, I forgot the overclock settings are stored in a file on the SD Confused Maybe this should be moved to the ext4 partition on the USB then, which would allow the overclock to be enabled/disabled without writing/corrupting the SD.

(2013-01-28, 16:17)popcornmix Wrote:
(2013-01-28, 16:11)MilhouseVH Wrote: The problem being that the Pi may already be overclocked by the time it works out it needs to perform an update of the SD card (certainly if initial_turbo is specified) and would then have to modify config.txt in an overclocked state - thus writing to the SD card, and potentially corrupting config.txt - in order to disable overclocking for the next boot...
You can disable overclock at runtime by switching governor from ondemand to conservative.
Either suggest people with sdcard corruption problems avoid initial_turbo, or include a (up to 60 second) delay before updating firmware if initial_turbo is in config.txt.

So if I don't have initial_turbo in my config.txt, what does that do? Does it mean the overclock only kicks in once XBMC has loaded and as the updating process is all done before XBMC loads, that the updating/writing will all be done with the overclock disabled? If initial_turbo is in config.txt, how would delaying for 60s before updating help as surely the overclock would be enabled from boot (and how would we tell it to delay for 60s before updating but not when there's no update to do anyway?)

As for disabling overclock at runtime by switching governor from ondemand to conservate, I'm not sure what you mean by "runtime" but presuming you mean whilst XBMC is running I'm not sure that would help avoid corruption during the updating process, as surely when it reboots to do the update it will re-enable the overclock based on the config.txt.
Switching to the conservative governor would make sense when performing an update, though that wouldn't prevent the ext4 partition from being trashed which is the other piece of the puzzle (though not so much if you're booting from USB/NFS).

I don't know what or why the mmc0 errors are occurring, but if you boot with an overclock, experience the mmc0 errors, then switch to the conservative governor does that magically mean the SD card is behaving itself (until you switch back to the ondemand governor)?

Ultimately, preventing the mmc0 errors in the first place is the only solution.
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.
(2013-01-28, 16:46)doveman2 Wrote: So if I don't have initial_turbo in my config.txt, what does that do? Does it mean the overclock only kicks in once XBMC has loaded and as the updating process is all done before XBMC loads, that the updating/writing will all be done with the overclock disabled?

Would also like to understand this, please...
(2013-01-28, 17:42)pplucky Wrote:
(2013-01-28, 16:46)doveman2 Wrote: So if I don't have initial_turbo in my config.txt, what does that do? Does it mean the overclock only kicks in once XBMC has loaded and as the updating process is all done before XBMC loads, that the updating/writing will all be done with the overclock disabled?

Would also like to understand this, please...

I believe(*) the ondemand governor is the default on OpenELEC. So the first few seconds of boot will be at 700MHz, then the ondemand governor is enabled and the clock frequency becomes dynamic and will switch up to (e.g.) 900MHz whenever its busy. This is during kernel boot, and well before xbmc is launched.

This is different from raspian which defaults to the conservative governor and switches to the ondemand governor (assuming shift key is not pressed) from an init script.

(*) not checked this.
(2013-01-28, 16:38)MilhouseVH Wrote: Rather than rely on dmesg to detect SD problems (which isn't included by default in the initramfs build, and the relevant mmc0 messages appear too late anyway, see boot log), the modified init script (function media_check) times how long it takes to write a ~1MB file to the FAT partition, and reboots if it takes too long. This all happens before the ext4 partition is mounted, which usually ends up being corrupted if the SD card is misbehaving.

I must say I'm not so keen on writing a file to detect filsystem corruption. Although you may not care whether the contents of the file are corrupted, it seems quite possible that the FAT will get corrupted rendering start.elf/kernel.img unreadable.

From the log, which message guarantees you are in corrupting state? We seem to have:
<6>[ 4.428548] mmc0: missed completion of cmd 18 DMA (512/512 [1]/[1]) - ignoring it
<6>[ 4.428592] mmc0: DMA IRQ 6 ignored - results were reset
<3>[ 4.913573] mmc0: final write to SD card still running
<3>[ 14.920858] mmc0: Timeout waiting for hardware interrupt - cmd12.
<3>[ 14.922006] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900

The real solution is finding what part of rebooting gets it into a good state. Presumably some sort of sdhost or sdcard reset. Can the kernel perform this reset without a reboot? (or even with a reboot)
Here's a the log (pastebin) of OpenELEC without force_turbo/initial_turbo and it does indeed switch to ondemand early in the boot process. As long as the user hasn't enabled force_turbo then it should be possible (much later in the boot process) to switch to the conservative governor (assuming this causes SD cards to behave, at least temporarily) however switching governors won't work for force_turbo users.
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.
(2013-01-28, 19:14)MilhouseVH Wrote: however switching governors won't work for force_turbo users.

This might work:
propline=`cat /boot/config.txt |grep -v "^#"|grep initial_turbo|tail -1`
[ ! -z "$propline" ] && declare $propline && sleep $initial_turbo

to guarantee initial_turbo has finished.
As described in the update procedure I put the SYSTEM file in the Update folder manually.
This file contains the third party binaries..!?? So why putting files from 3rdparty/bootloader files also to the SD card??

(2013-01-28, 14:10)MilhouseVH Wrote:
(2013-01-28, 14:04)pplucky Wrote: If it is updating, it means the partition already contains it. In that case, do I also need to do that? Where should I extract it from then?

Yes, as they sometimes change from one release to the next (for instance in the last few days, updated thirdparty binaries were included in all OpenELEC releases).

If you let OpenELEC update itself, these third party binaries will be extracted from within the new SYSTEM file.

If you are updating manually, you need to copy them yourself to the SD card. If you are downloading the tar.bz2 file, they should be in a folder called 3rdparty/bootloader (not sure about the zip packages, but probably similar).

  •   
  • 1
  • 72
  • 73
  • 74(current)
  • 75
  • 76
  • 174
  •   
  Thread Closed
 
Thread Rating:
  • 12 Vote(s) - 4.58 Average



Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi4.5812