Forum

I am a newbie and recently acquired Raspberry Pi 2.0 - Model B (512MB) device. I have loaded xbian 1.0 Alpha 5 code and using Navi 3.7.5. It was working fairly well and had originally experienced few system freezing / hang etc. So when I saw Navi updated to 3.7.7. I went ahead and updated hoping that this might solve freezing problem. However, after reboot all I see is xbian logo with loading bar moving extremly slowly, and after 10 minutes later and no change I rebooted again and samething. I believe that code load was corrupted so I reloaded the SW all over again and decided to stick with 3.7.5. But now when I power the system off completely and later power it back on, I see that system just gets stuck on xbian logo and only way to make it work is t load SW from scratch again. Since this is happening very consistently, I also replaced the SD card just to be sure but still same issue. I would truly appreciate any help you can provide to help solve this issue

What SD cards are you using?

You can try the following.
Reload the clean image again to your SD card. Browse it in your computer (after loading the image you might have to remove and stick it in you computer again to be able to browse it). Search for the file config.txt and open this, change 'core_freq=375' to 'core_freq=250'.
Now stick it in you RPi and try again.

Thank you Fred for your reply. I am using Kingston 8GB SDHC Class 4 cards. I will make changes as you have recommended and will try for couple of days to see if this problem goes away and will report back....

Also, I forgot to mention that one of my Kingston card and second generic brand (Professional SDHC Class 10) SD cards appears to be permanently locked (Write protected). After 3 or 4th reload, I am unable to format or write xbian image. Both cards are micro card with Adapter. I have moved the micro card to another adapter card just to be sure that write switch is not the issue and still unable to format it. When I plug the cards in to the PC, it recognizes the cards and shows the files installed, but I cannot do anything else with it. I have been using SD cards for ever on many devices and have not come across this issue and wondering if anyone has come across similar issues and may know how to fix it....

I went ahead and reloaded new image and changed the Core freq from 375 to 250 but that did not change the outcome and I still see "Xbian - loading" screen which appears to be frozen and I have to power the device off and on again. After a reboot, outcome is still unchanged and only solution is to reload all over again.

So in summary, everytime I turn the device on, I have to reload the image which is getting to be very annoying, so any assistance to resolve this problem would be very much appreciated.

You have tried multple sd cards? Do you have anything attached to the usb ports?
Which power adapter do you use?

For Raspberry Pi, I am using motorola adapter which was recommended in the tested hardware list in Raspberry pi site. As for 2 USB built in ports, I have hooked up external 7 port USB Hub with its own power supply to be able to attach thum drive, and wireless KBD.

Yes, I have used different SD cards, albeit same MFG (Kingston) but same issues. Please keep in mind, that my setup has been the same from first day and never had this problem before. So not sure what exactly is going on. I have ordered a new Belkin USB Hub today to eliminate a current HUB since it is cheap no name brand hub to ensure that is not causing some sort of issues...I am also thinking about downgrading Xbian to 4 to see if that changes anything... If you have any other idea's please let me know and I will take a shot at it...I will report back as I am making changed to see if anything works....

That's the 0.85A right? Seems pretty low to me.
I would try running without the USB hub to see if that works.

Fred,
Just to give quick update, I took the USB hub off and ran rasberry pi without it and still same issues as previously stated. However, I loaded new image (xbian 5) and than I changed core_freq from 375 to 250 as recommended and than installed in raspberry pi, and things seem to be running better. Meaning, that when I power the device off and power it back on, I have not had a need to reload code in the last 4 days which is a relieve. But I did notice that when I power up the device, it takes approx 3-5 minutes for xbian logo on the screen before it is ready. Also as I go thru the menus, I do see a delay that I don't recall experiencing before...''

Fred, can you please also explain why we changed core_freq 375 to 250 and it effects? Thank you for your time..

If you have any recommendation or feedback would be very much appreciated...

Can't explain exactly why changing the core_freq lowers chance of corruption. All I know is that for lots of SanDisk sd cards (like I have) it will not work with anything higher then 250. And it makes kind of sense to me that if you set it up to work faster, the chance of errors increases.

Change your cmdline.txt to this to disable the splash screen and show all messages to your attached tv/monitor. Now you can see what is going on instead of only knowing the booting takes a very long time. I guess it will be fsck that is fixing the corrupted root partition.


Also you can try a clean install and set both core_freq and arm_freq to defaults (250 and 700), to see if that helps.

But this is all fighting symptoms I guess. You said you have tried multiple sd cards but they are from the same kind/make? I would start with trying a different kind/make of sd card.
Search the web, there is a list of working sd cards on the RPi wiki. That list is however outdated and not tested for overclocking but it's the best I found (it also lists sandisks which I would not recommend based on my own experience).
I personally tried 3 different sd cards. First 2 did not work, third was a SanDisk that worked perfect for a while as long as you keep your core_freq at 250. Now my SanDisk sometimes doesn't boot anymore, but when it boots all is okay.

I ended up moving my root partition to an external usb disk so I could overlock, which also turned out to be faster.

or better than looking on RPi wiki for tested HW check our wiki
http://wiki.xbian.org/view/Recommended_and_supported_hardware

Nice, did not know that .
But I see a couple of SanDisks in there, also exactly the one I have which does not work when the core_freq is overclocked. I'll change it.

Maybe it's also a good idea to add a list with hardware known not to work?

(9th Jun, 2013 11:36 PM)Fred Wrote: [ -> ]Nice, did not know that .
But I see a couple of SanDisks in there, also exactly the one I have which does not work when the core_freq is overclocked. I'll change it.

Maybe it's also a good idea to add a list with hardware known not to work?

which Sandisk ? I have two Sandisk cards and both works like a charm with all OC settings up to Turbo with overvolt(I do use high OC, just default XBian OC but I have tested all)

When I got these issues I searched the web and found out that there were more people having issues with SanDisks and overlocking core_freq. Can't find that forum anymore.

(10th Jun, 2013 12:02 AM)Fred Wrote: [ -> ]

Code:

SanDisk Ultra SDHC Class 10 16GB 30MB/s (SDSDU-016G-U46)

When I got these issues I searched the web and found out that there were more people having issues with SanDisks and overlocking core_freq. Can't find that forum anymore.

hmm, bit odd as one of my card is exactly same and I have no issues at all
SanDisk Extreme Pro SDHC UHS-I 8GB
SanDisk Ultra 30MB/s SDHC 16GB

I would say that this might be related to the version of RPi as you know that there are two types of SoC's used and also this might be the combination of SD card with some dodgy PSU's (not saying any PSU is bad but with more expensive PSU's you may get a better experience). I paid £16 for my PSU what might be a lot of money but since I have it I have had no issues at all what so ever

Never tried another PSU, maybe I should do that. I bought a PSU that was recommended at rsonline (where I also bought the RPi), so never thought that could be the problem.