New Power/startup issue
I'm seeing a symptom not yet described on the page.
The Red PWR led is on. The (normally) green led for OK is not, except for a tiny green dot in the center of the led. Or is this point 1.2?
In my case the board does not boot at all (no video, no flickering leds). According to Farnell there might be an issue with a recent series of boards that all seem to have this behaviour. But this still needs to be confirmed.
I still have to test some other distro's and SD cards to exclude a few failure modes.
I (Ian) created the New Power/startup issue (above) by putting the image into the partition instead of the whole device ie I did: dd bs=1M if=~/debian6-19-04-2012/debian6-19-04-2012.img of=/dev/sdd1
it should be dd bs=1M if=~/debian6-19-04-2012/debian6-19-04-2012.img of=/dev/sdd
DVI Interference occuring after firmware upgrade
Hi, I just got my raspberry Pi today and was playing with it fine on the firmware that came with the image download with clear picture and no interference with both the standard config.txt and with overscan disabled, but when updating to the newer firmware with Hexxeh's rpi-update command, the interference issue described on this page started occurring (although with red dots rather than green like the picture). It did go away when setting the config_hdmi_boost to 4 - but it might help others to note that this could be caused by a firmware update, and not necessarily mean that something is broken. Although, I do find it strange if the "defaults" were changed as it causes this problem. Adammw 09:53, 14 June 2012 (UTC)
For example I've got this one. I figured out on my own that the keyboard is tripping it up. But what can I do about it ? It's as vanilla a cheap Chinese USB keyboard as can be had!
Kernel Panic on boot Text appears on screen, but then hangs with debug messages. This can be caused by USB devices such as keyboards. Try again with nothing in the USB.
--Dreamgear 01:18, 23 June 2012 (UTC)
New bootloader worked for me
I downloaded the new bootcode file https://github.com/raspberrypi/firmware/blob/234c19de7cbaaf4997671d61df20a05759066295/boot/bootcode.bin referenced in the article. This made my RaspBerry Pi boot up. I have a model B board, a SanDisk SHDC 4 GB card (specific model unknown), and used the latest squeeze image from the downloads page (debian6-19-04-2012.img)
Same for me, same SD card, worked only with the new bootcode.bin, otherwise the red led would not blink nor was there any video signal.
Why is arm240_start.elf a better choice?
From the text: "the arm224_start.elf is usually the wrong choice." In keeping with the educational goals of the Raspberry Pi, I think an explanation of this statement would be beneficial.
Crashes occur with high network load
Only happens with USB-WiFi sticks (tested with 2) for me.
wiki: "...try adding to /boot/cmdline.txt smsc95xx.turbo_mode=N"
I thought it was the reason, but again. High traffic (copying files WiFi sftp) -> pi gets offline.
With the latest firmware and linux-image-3.2.23-rpi1+_1_armel.deb, the system runs stable, also at high network traffic. Can anyone confirm this please?
Looking at the Model B rev 2 (512MB) Pi there are three green LEDs. That seems to have changed in that revision from what is reported on the troubleshooting page. On that board the color coding of the LEDs is as follows:
100M - yellow / orange
LNK - green
FDX - green
PWR - red
ACT - green
The error reporting refers only to "green LED", but it might be helpful to specify which one that is as it is no longer obvious.
Hello, my name is Chris.
On start-up, the internet works perfectly in Linux, wired (no radio) via my router, I can ping forever, no problems. The Pi appears in the DCHP list on the PC, which is also wired to the router.
As soon as I enter the Desktop, the entry in the DCHP list disappears and there is no more internet, so the browser (Midori) does nothing.
Logging out of the Desktop and returning to Linux shows the Pi returning to the DCHP list and I can once again ping to my heart's content.
It says somewhere that the problem could be because the drivers in my version of the firmware are out of date and I need to update it. I've checked the version number and sure enough it is well behind the times!
And now, the main problem of today. I have followed the 'pi-update' instructions on these pages in order to update the Pi. First problem - the certificates don't match. Also, some things seem to have moved. I have tried downloading using '-- no-certificate' or whatever it was (it has scrolled off the top of the Pi screen now).
Then there is an error message about being unable to resolve host address 'usr', which I don't understand.
Finally, when I type 'sudo rpi-update' it says that it can't find the command.
Where can I obtain the up-to-date, fully-working instructions, plus the certificates, locations, new host addresses if necessary, etc?
I am desperate to get my Pi running, and I have been thwarted at every step when trying to sort this problem out. I have probably had the Pi too long now to send it back, despite the fact that the fault has existed since new. The Foundation have not replied to my requests for help.
I have since read on here that my sound output is probably rubbish too, and that I won't be able to do a thing about it even though it was also faulty from the start.
Please help, or I might just throw the whole lot in the bin and buy an Arduino!
|Thread title||Replies||Last modified|
|Model-Specific Differences||1||09:14, 31 December 2014|
Last edit: 09:14, 31 December 2014
This troubleshooting guide currently doesn't mention the model B+, so I guess that when it says something like:
Check that you have correctly written a Raspberry Pi image ... browse for the following files: * bootcode.bin * fixup.dat * start.elf amongst others
Does it mean a good NOOBS Micro SD card that came with a new RPi B+ might be allowed to not have start.elf while it does have bootcode.bin and other files/dirs?? Or are there specific things to do with these cards before they can be used? Are there other places this page needs updating for the newer models?
There are other places. The red LED is no longer directly connected to the 3.3v rail, but driven by the RST output of an APX803 supervisory circuit. As a consequence, a blinking red LED on the B+ is not a direct consequence of a brownout, but a warning that the 5v power rail is dropping below 4.63v. I'll add a sentence to that effect.