Safe Mode

[dom]

EDIT: This feature is removed from default firmware as of 18th March 2014. NOOBS still supports a safe mode, using the same gpio pins.


If you have the recent official raspbian image, or have updated your firmware since that was released, then the Pi supports a "safe mode".

You need to add a jumper between pins 5&6 of P1.



Uploaded with ImageShack.us

This results in config.txt being ignored (except for avoid_safe_mode). A default cmdline.txt is applied, and kernel_emergency.img is loaded (if not available, then just kernel.img).

It provides a means of recovering from, e.g.
* too high an overclock
* a typo in cmdline.txt
* an incorrect kernel=<filename> parameter
* an invalid display mode
without requiring a PC.
(Obviously it won't help if you've deleted start.elf...)

The busybox based kernel_emergency.img has /boot mounted, and vi installed so you can fix up config.txt or cmdline.txt.
(You can also mount /dev/mmcblk0p2 and fix up the rootfs if you have problems there that stop you booting).

Be very careful with where you insert the jumper. Some pins carry power, so shorting those would not be a good idea. Third row from the end.

[joan]

Might be worth highlighting the jumper on pins 5&6. A cursory look at the image made me think the jumper was the wire between tp1 and that chip.

[kadamski]

Works, great, thank you. I couldn't wait for this feature from the time I first heard you are working on this. Now I wont need to swap SD card 100 times a day when experimenting.

[reggie]

What happens to that pin once the pi has booted? Does it then become available for GPIO or is it permanently used for safe mode? Just thinking you would want to be fairly careful what you had connected to that pin, especially if you're using i2c devices.

[dom]

What happens to that pin once the pi has booted? Does it then become available for GPIO or is it permanently used for safe mode? Just thinking you would want to be fairly careful what you had connected to that pin, especially if you're using i2c devices.

All we do is read it once on bootup. It naturally has an external pullup resistor. If you connect external hardware to that pin, the worst that will happen is it falsely triggers safe mode. Hence the:
avoid_safe_mode=1
option.

[thektalin]

Hello,how do i mount /dev/mmcblk0p2 in safe mode? because if i type: df, i can find it .

Thank you.

[dom]

Hello,how do i mount /dev/mmcblk0p2 in safe mode? because if i type: df, i can find it .

mount /dev/mmcblk0p2 /mnt
If /mnt doesn't exist then "mkdir /mnt" first.

[bredman]

This is a great idea.

Is anybody willing to put a good description into the wiki?
http://elinux.org/RPI_safe_mode

For anybody who needs to use safe mode, remember that a metal paperclip is excellent a a temporary jumper.

[dom]

For anybody who needs to use safe mode, remember that a metal paperclip is excellent a a temporary jumper.

Pins 1 and 2 (i.e. two closest to sdcard end of board) are power (3.3V and 5V). Be careful not to touch those.

[morpheus80]

Dear dom,

can you please upload a picture that has a red (or blue) circle around the jumper on PINS 5+6 on P1.
Or please highlight the jumper any other way at the picture so that it can't be mistaken with the red wire between that chip and TP1, as joan sad previously.

Thanks a lot in advance because many people could think the wire is the jumper which was me too at the first moment I saw the picture

[dom]

can you please upload a picture that has a red (or blue) circle around the jumper on PINS 5+6 on P1.

Done.

[mahjongg]

Be very careful not to put the jumper between pins 1 and 2, as that will effectively destroy your PI the moment you turn it on (putting 5V on all the 3V3 chips).

[InnocentSam]

Thanks for posting this, will come in nifty in case I mess up

[plugh]

I suspect I've found, uh, a bug.

Just received my rev 2 board. To do a quick checkout, I threw the firmware files on a card, jumpered 5 & 6, and powered it up. Results not what I expected. Poked at it a while, concluded it was trying to load kernel.img, not kernel_emergency. Then the proverbial light bulb went off...

rev1 board
■SCL0 [BCM2835/GPIO1] routed to P1 pin 5
■SCL1 [BCM2835/GPIO3] routed to S5 pin 13
rev2 board
■SCL1 [BCM2835/GPIO3] routed to P1 pin 5
■SCL0 [BCM2835/GPIO1] routed to S5 pin 13

Is boot loader checking board rev so it knows what BCM GPIO line is actually connected to P1 pin 5 before testing 'pin 5 jumpered to pin 6' (ie pulled down)? Or are we now supposed to (try to) pull down S5 pin 13 for safe mode boots?

[jojopi]

Safe mode works on a Rev2 with the jumper in the same physical place. The firmware already corrects for the GPIO numbering. (Except, perhaps, if you use very old firmware, or your board has the wrong revision number programmed.)

[plugh]

Hmmm...

Used http://asbradbury.org/tmp/raspi/2012_10_30_boot.tar.gz from this thread.

Unit is 'Made in China', has mounting holes, purchased from MCM.

renamed kernel_emergency to kernel (since jumper 'not working'), /proc/cpuinfo gives
Hardware BCM2708
Revision 000f

Also, just now downloaded latest firmware from github (master branch) and gave it a whirl. Jumper still ignored. Also metered the jumper (just to be sure) and it checks out OK.

Suggestions?

[dom]

@plugh
what does:

Code: Select all

vcgencmd otp_dump |grep 30:

return?

[plugh]

It is not recognizing vcgencmd. Is it included in the emergency kernel file system?

I poked at this some more today. Tried various config and cmdline tweaks. For example replace config.txt with zero length file - the default one included clocking params. There were lines in console boot logging that indicated it processed them; but with jumper set only actionable config option is supposed to be 'avoid_safe_mode' (which isn't present). Also tried changing root spec in cmdline, which again was obviously being processed; but with jumper set should not be.

Also... renamed emergency, booted into it, and used /sys/class/gpio command against gpio3; reading the pin showed 0/1 as appropriate with jumper present/removed.

Finally... Eventually figured out a way to pull down S5-13 -- and eureka! safe mode boot!

This is with the 10-28 date files asb posted in his announce thread (ref my preceding post) and with the latest files pulled from github (master branch, latest commit, 11-26 file dates). Regression???

[dom]

It is not recognizing vcgencmd. Is it included in the emergency kernel file system?

No, you will need the standard kernel.

Finally... Eventually figured out a way to pull down S5-13 -- and eureka! safe mode boot!

I haven't understood what you did to boot into safe mode.

[plugh]

Finally... Eventually figured out a way to pull down S5-13 -- and eureka! safe mode boot!

I haven't understood what you did to boot into safe mode.

This was intended to be a 'quick checkout' of my newly acquired board... I borrowed an sd card (already fat formatted) copied the boot files to it, connected keyboard, monitor, jumper (to force emergency kernel, since there was no /root partition on the card) powered it up --- and it obviously did not boot into anything usable, complaining about no root partition, kernel panic, etc.

To get into the emergency kernel, I've been renaming it to kernel.img. To test if jumper 'works' I rename it back (and put stock kernel.img back). I have satisfied myself that GPIO3 (rev2 P1-5) is being electrically pulled down by the jumper and that the system sees the pin as a '0'. So today I figured out a way to 'get at' GPIO1 (rev2 S5-13) and pulled it down -- and kernel_emergency was loaded instead of stock kernel.

If the only way to further diagnose what is going on is to boot a full distro, then I'll have to get an sd card I can load an image onto (need to do this anyway since I have to return the borrowed card).

So, any other diagnosis I can do from the emergency kernel short term?

[plugh]

Ok, made a run to the store, bought an sd card, loaded 10-28 raspbian image...

Result of vcgencmd otp_dump ==> 30:00000002

And this tells us???

[dom]

Result of vcgencmd otp_dump ==> 30:00000002
And this tells us???

That's the "raw" board revision that's been programmed. 2 is a rev1 model B.

So, that seems wrong. Can you just confirm your board is new style (e.g. with two mounting holes?)
Does it say made in the UK?

[plugh]

It says 'Made in China'. It has mounting holes, P5 and P6 headers.
GPIO1 is connected to S5-13 and GPIO3 to P1-5

On back is sticker with FNXM121128729
It is one of the large batch MCM shipped out just before Thanksgiving.

So I (and possibly many others) have bad board? Is this fixable?
Is the otp write-ones or write-zeros? Can I write a 4 and thus change 2 into 6?

[dom]

It says 'Made in China'. It has mounting holes, P5 and P6 headers.
GPIO1 is connected to S5-13 and GPIO3 to P1-5

On back is sticker with FNXM121128729
It is one of the large batch MCM shipped out just before Thanksgiving.

So I (and possibly many others) have bad board? Is this fixable?
Is the otp write-ones or write-zeros? Can I write a 4 and thus change 2 into 6?

Yes. One of the manufacturers got the OTP programming wrong. Your 2 should be a 15.
We are aware of this, and are able to adjust it (because we can detect the 512M ram size, and otp=2 makes no sense).
That is why your Revision shows as 0xf rather than 0x2.

However the safe mode check occurs earlier in the code before this hack is done, so it thinks your board is a rev 1.
(Apart from safe mode, I don't think there is anything else behaving wrongly for you).

I think I'll change the firmware to actually program your otp to 15, rather than just consider it as 15. That should avoid the safe mode problem (and any future problems).

[plugh]

I think I'll change the firmware to actually program your otp to 15, rather than just consider it as 15. That should avoid the safe mode problem (and any future problems).

Are you talking about putting something into the mainstream firmware release? (imho fwiw, I'd say remove the current 'pretend' hack from the firmware and just release a fix-it app.)

Anyway... Do you have "bad" samples to test against (it IS a OneTP), or are you looking for a volunteer?