Hi Srikant I will try to continue your explanation below to explain the parts I do not understand:
On Mar 31, 3:56 pm, Srikant <[email protected]> wrote: > Briefly the call flow here: > > The bootCommand() function in RecoverySystem.java calls the > pm.reboot() with the user passed argument as "recovery". > > The pm.reboot() is implemented in PowerManager.java, where it calls > the mService.reboot() with the reason code as "recovery". > > The mService.reboot() is implemented in PowerManagerService.java, > where it calls ShutdownThread.reboot(mContext, finalReason, false); > > The PowerManagerService.java communicates with the recovery.c through > JNI, where the reboot() is called with reason code. > > The __reboot system call > __reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, > LINUX_REBOOT_CMD_RESTART2, "recovery"); > is called in init.c > The __reboot sys call enters to the Kernel from sys.c, where the cmds > are passed to the Kernel and kernel_restart() function gets called. > kernel_restart_prepare(cmd); and machine_restart(cmd); are called > futher from here based on the linux reboot arguments. Reboot syscall is defined in kernel/sys.c as: SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned int, cmd, void __user *, arg) where kernel_restart() is called with the reboot reason ("recovery"). kernel_restart() calls kernel_restart_prepare() and machine_restart(), both with the "recovery" command. (As you have explained.) kernel_restart_prepare() passes on the recovery command to every element in the reboot notifier list. machine_restart() passes on the restart option to architecture specific code, in my case (and most android cases I guess) it is arm. Eventually arch_reset() is called, again with the recovery command, in my case the implementation is in arch/arm/plat-mxc/system.c, and nowhere in this function is the "recovery" command parameter used. So, I guess either I need to modify arch/arm/plat-mxc/system.c to store this command value for the bootloader (which I guess is not easy, as I assume at this point all drivers are finalised.) Another solution would be to implement a reboot notifier to do the same, which would happen earlier in the shutdown process, and I should be able to access the block devices at that point(?) Maybe such a notifier is already present, and I have just been unable to find it? > There are some methods which update/pass the commands to the > bootloader in firmware.c and bootloader.c Yes, I assume you are referring to the ones that live in devices/htc/ common/updater (on the android-2.3.1_r1 branch). I guess it will require some work to include that code in the kernel, do you believe that would be the right approach? > Hope this helps and let us discuss/know if you have any furhter info. Thanks a lot. :) /Bjarke -- unsubscribe: [email protected] website: http://groups.google.com/group/android-porting
