Hi Bjarke, You are on the right track.
But unfortunately pointing out "one-place" or "one-file" is not possible right now, as we do not know the device/architecture you are working on. Things are further complicated by the fact that we do not know which bootloader you are going to use on your device. *So, let me illustrate with an example:* [1.] Consider you are working on a omap-board. [2.] The architecture-specific code is *arch_reset*,* *present in File:* arch/arm/plat-omap/include/play/system.h* http://android.git.kernel.org/?p=kernel/linux-2.6.git;a=blob;f=arch/arm/plat-omap/include/plat/system.h [3.] The final call to *arch_reset* is present in *arm_machine_restart( )* File:* **arch/arm/kernel/process.c * http://android.git.kernel.org/?p=kernel/linux-2.6.git;a=blob;f=arch/arm/kernel/process.c [4.] We will now implement a new function *set_reboot_recovery_mode*. We use *omap_writel( unused_SAR_reg_addr, special-hex-pattern )* SAR (or save-and-restore) registers retain their value after a warm-reset. [5.] In *arch_reset*, check the param *mode* being passed to it. Call *set_reboot_recovery_mode* here if *mode *is "recovery". -- Execution along reboot-path continues -- -- Device reboots here. ( warm-reset ) -- [6.] After warm-reset, in the bootloader code, check the value in * unused_SAR_reg_addr*. If it contains *special-hex-pattern* then in bootloader, code it so that the kernel is loaded and point it to the recovery-fs (instead of the regular-fs partition). As you can see the process of implementing recovery mode is* VERY* specific to the device we are using. There may not be an exact "one-place" where we do this. More info about your particular device will definitely help in deciding the *right* way to implement recovery-fs feature. Regards CVS -- unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting