Red LED on Faint Green LED

@dom

You will have to update your firmware:
http://elinux.org/R-Pi_Troubleshooting# ... g_firmware

(then replace with my start.elf).

I'm using the current production Debian image and the most recent kernel and firmware from https://github.com/raspberrypi/firmware/tree/2c095047fe54ae25a6b67f5b20308cdac4ff3bd5/boot. Should I go back to the production firmware?

[dom]

I'd like you to update firmware with rpi-update as described in link.
Currently you have mismatched start.elf and /opt/vc/lib, which is why anything that communicates with GPU (which will also include 3D and video) will fail.

@dom

A transcript:

root@raspberrypi:~# rpi-update
Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS
Performing self-update
Autodetecting memory split
Using ARM/GPU memory split of 224MB/32MB
We're running for the first time
Setting up firmware (this will take a few minutes)
Using SoftFP libraries
/opt/vc/sbin/vcfiled: error while loading shared libraries: libvchiq_arm.so: cannot open shared object file: No such file or directory
If no errors appeared, your firmware was successfully setup
A reboot is needed to activate the new firmware

(libvchiq_arm.so is present in /opt/vc/lib)

root@raspberrypi:~# rpi-update
Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS
Performing self-update
Autodetecting memory split
Using ARM/GPU memory split of 224MB/32MB
Updating firmware (this will take a few minutes)
Your firmware is already up to date

(rebooted)

root@raspberrypi:~# /opt/vc/bin/vcgencmd otp_dump
error=1 error_msg="Command not registered"
root@raspberrypi:~# /opt/vc/bin/vcgencmd version
Jun 17 2012 13:30:15
Copyright (c) 2012 Broadcom
version 320121 (release)

[dom]

You missed this bit:

(then replace with my start.elf).

@dom
You're right: I screwed up. Results of /opt/vc/bin/vcgencmd otp_dump:

08:00000000
09:00000000
10:00000000
11:00000000
12:00000000
13:00000000
14:00000000
15:00000000
16:00280000
17:1020000a
18:1020000a
19:ffffffff
20:ffffffff
21:ffffffff
22:ffffffff
23:ffffffff
24:ffffffff
25:ffffffff
26:ffffffff
27:0000c2c2
28:3994ada4
29:c66b525b
30:00000002
31:00000000
32:00000000
33:00000000
34:00000000
35:00000000
36:00000000
37:00000000
38:00000000
39:00000000
40:00000000
41:00000000
42:00000000
43:00000000
44:00000000
45:00000000
46:00000000
47:00000000
48:00000000
49:00000000
50:00000000
51:00000000
52:00000000
53:00000000
54:00000000
55:00000000
56:00000000
57:00000000
58:00000000
59:00000000
60:00000000
61:00000000
62:00000000
63:00000000
64:00000000

For me, the culprit was a bent pin in my µSD -> SD adapter:

[dom]

17:1020000a
18:1020000a

This is interesting bit. 18 is a redundant copy of 17. Bit 3 is enable pullups. Your OTP is fine.

If you want to investigate further and have a scope, I'd be interested if you can see a any difference between "with external pull-up" and without.
I'm thinking specifically of a low glitch before any data is transferred.

dom writes:
> If you want to investigate further and have a scope,

Unfortunately my scope is not up to the task.

No other tests for using pull-ups were done yet ? I was feeling that the issue of using only some cards was important to the developers. Some let say official tests ?

Mine was working for 2-3 days

Managed to install CUPS and Samba and was happily serving my home. Then it suddenly hung and after not being able to reboot I realized that the SD card was completely gone - it was completely unrecognisable in any device.

And my RasPI has not been bootable since then on. I've tried 6 different SD cards of varying sizes and classes, 5 of them are from the "working" list and one is 4GB Kingston microSD in an adapter. With no luck.

I've checked the voltage - it's 5.1V. Also the resistance over polyfuses seems to be as requested. Probably time to return to RS. Too bad I had to wait for 4 months to have 2 days of fun

[dom]

@j.bachorik
Have you tried Wheezy build:
http://www.raspberrypi.org/archives/1435
The newer kernel should have better compatibility with sdcards.

Paul_L writes:

No other tests for using pull-ups were done yet ?

I wish someone would try it. With some confirmation this solution can be put on the Wiki. It also would be good if someone with a good scope would look at the SD card data lines as Dom suggested. Mine lacks the bandwidth to resolve the glitches that might be there.

@dom
Yes, today I've tried to use wheezy on Kingston 4GB class 4. Still a no-go
I am using even two different computers to write the images to be sure it is not caused by a faulty SD reader in one of them. But nothing works.

I am a bit afraid that the dead SD card can have something to do with this.

I'm getting the same. BUT.

My Pi arrived yesterday, I then took two trips to maplins before I got an SD card that would work (they kindly swapped the first one for me).

Spent the rest of the evening playing with my new toy. Worked great.

Got home tonight, turned it on and got page after page of INODE errors during boot. I now get the red power light and the pinprick green OK light and my SD card's trashed, can't access it from anything.

Over night the card had not been removed from the Pi or bumped or jiggled and now I have to explain to the nice man in Maplins 'again' that I have a duff card.

My concern now is that the card failure has also bricked the Pi. So i'm going to get into a cycle of new SD card - works - fails - bricks Pi - new Pi - new SD card ..... repeat.

The issue with SD cards really needs to get sorted.

Cheers....

[dom]

My concern now is that the card failure has also bricked the Pi. So i'm going to get into a cycle of new SD card - works - fails - bricks Pi - new Pi - new SD card ..... repeat.

I'm sure the card failure has not bricked the Pi. It's pretty much impossible to brick a Pi without physical damage.
The sdcard may be corrupted. I'd imagine reimaging the card would fix it. I'd recommend using the Debian Wheezy image which has better compatability with scdards:
http://www.raspberrypi.org/archives/1435
If it fails again it may be worth investigating the power supply:
http://elinux.org/R-Pi_Troubleshooting# ... r_problems
If that's okay, then try a different sdcard.

@dom
Yes, today I've tried to use wheezy on Kingston 4GB class 4. Still a no-go

Hooray! RP works again! The same 4GB SD card with arch linux. I just needed to unplug the PSU from the outlet - unplugging the RP from PSU didn't work. So it seems it is a some kind of weird PSU issue.

Having the same issue here. I'm using SanDisk Extreme HD Video 30MB/s SDHC I card (BI1205616252D)
I tried booting debian6-19-04-2012.img
Initially faced the problem of Red LED on + faint Green LED. After using rpi-updater in offline mode from my laptop, the Green LED remained always on. So far nothing. It is same as all of you are experiencing
Tried freezing, no effect.

However if I touch the solder pad of the connectors of the SD card slot, with my fingers (I'm just touching the soldered pads, NOT putting any mechanical force on the connector itself), the green LED starts flashing and I start seeing output on my monitor hooked up with a HDMI to DVI connector. It seems like the Pi is starting to read from the card and then gives up due to I/O errors. Here's a photograph that I had managed to take --


This indicates some electrical glitches on the data lines of the SD card. Touching the data lines, occasionally makes the thing work.
I do have access to high bandwidth scopes, but right now it is late night (almost early morning ) . Tomorrow, I can try probing the SD card data and clock lines and see if there's anything suspicious.
Meanwhile, it would be great, if someone can point out, if the Pi is using SPI or SD Bus ?

BotCyborg writes:

I do have access to high bandwidth scopes, but right now it is late night (almost early morning ) . Tomorrow, I can try probing the SD card data and clock lines and see if there's anything suspicious.

Please do so. It would also be very nice if you could try adding the pullup resistors. The value is not critical: anything between 10k and 100k should do.

Meanwhile, it would be great, if someone can point out, if the Pi is using SPI or SD Bus ?

Since they are using all the data lines, I assume SD.

Please do so. It would also be very nice if you could try adding the pullup resistors. The value is not critical: anything between 10k and 100k should do.

I connected the 20k pullups on the DAT0,1&2 lines.
Now it is starting to boot from the same card!

Here's a snapshot of the DAT0, while the rainbow screen is being displayed.


However once it starts reading the root partition, strange things start happening
The pulses on the DAT lines (all 3) go completely haywire!

Soon it shows kernel panic and everything freezes
Probing the clock line, it seems, that clock is much slower, before the kernel starts loading. (Note the scope timebase, 10us )

However it speeds up and everything gets distorted once the kernel is loaded and it tries reading the root partition. (note the scope timebase again, this time it is 200ns)


Going to get a class 4 SD card and see what happens!

My concern now is that the card failure has also bricked the Pi. So i'm going to get into a cycle of new SD card - works - fails - bricks Pi - new Pi - new SD card ..... repeat.

I'm sure the card failure has not bricked the Pi. It's pretty much impossible to brick a Pi without physical damage.
The sdcard may be corrupted. I'd imagine reimaging the card would fix it. I'd recommend using the Debian Wheezy image which has better compatability with scdards:
http://www.raspberrypi.org/archives/1435
If it fails again it may be worth investigating the power supply:
http://elinux.org/R-Pi_Troubleshooting# ... r_problems
If that's okay, then try a different sdcard.

Cheers.

I blagged another SD card from somehwere and joy of joy the PI came back. I've returned the bad card to Maplins (again, very tollerant staff, no quible refund) and ordered another from Amazon taht is on the 'works' list on the wiki. The card completely failed, couldn't open it, format it or do anything.

I'll be trying wheezy when the new card arrives.

My power is from a powered hub, plent of amps there.

Any way, seems sorted. SD cards, they ain't all made equal....

Going to get a class 4 SD card and see what happens!

Working fine with a Sandisk 4GB class 4 SD card and 2012-06-18-wheezy-beta.
Removed the 20k pull ups from the DAT lines and it still works perfectly

Probing the clock line, it seems, that clock is much slower, before the kernel starts loading.
However it speeds up and everything gets distorted once the kernel is loaded and it tries reading the root partition.

Does this mean, than the linux kernel's sd card driver, is trying to increase the SD Clk to get better speed if it detects a faster card, but the Pi's hardware is unable to cope with it ?
So if the Pi can successfully read the firmware and other files from the boot partition before the kernel is loaded, then in principle it should be possible to make sure that the kernel sdcard driver doesn't push things outside the hardware specs of the RasPi.
Is my reasoning correct?
Can someone, kindly shed some light on the details of the boot process of RasPi?

BotCyborg wrote:
Does this mean, than the linux kernel's sd card driver, is trying to increase the SD Clk to get better speed if it detects a faster card, but the Pi's hardware is unable to cope with it ?

Have you see change 1178c4db57 regarding setting the clock speed for the sdcard with init_emmc_clock=XXX in config.txt?

[dom]

@jhasler @BotCyborg and others.

Thanks for investigation. Looking more closely, it looks like the bootrom enables pullups. As does loader.bin and start.elf. However bootcode.bin doesn't appear to. I've updated it to do this now:
https://dl.dropbox.com/u/3669512/temp/bootcode.bin

Any better at booting without external pullups?

@dom, unfortunately, this did not help, I still get the rainbow square.

I *know* the RPi is able to read the SD card, I've tried combinations of having only bootcode.bin, bootcode.bin+loader.bin and bootcode.bin+loader.bin+start.elf and with the latest firmware from github and I do get the right combinations of flashing green lights indicating the appropriate failure condition.

It just does not seem to want to boot kernel.img, no matter what kernel/distro I try. I've been through about 6 or 7 SD cards, all name-brand bought from Staples (reputable office supply place in the US), about 4 power supplies and I have verified 5.04V between TP1 and TP2 with a multimeter (just now in fact with your patched bootcode.bin). I don't have access to a scope to look at the SD card access.

I really think the next step is to write some diagnostics to the serial port (I logged issue 56 in github about this), I have a FTDI serial/TTL breakout board and I have previously had the console working.

Maybe my RPi has failed, it did work perfectly for the first 2 weeks that I had it, but sometime last week it stopped working. I'm sure that Farnell would happily replace it, but I *know* it's able to load some stuff off the SD card, and I think until we can see the actual error it would be premature to give up on this particular board.

Is there any possibility that the recent init_emmc_clock changes have screwed something up when it goes to load the kernel?

Thanks.