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

Reply via email to