[RFC] Need help deciphering reboot modes!

[RFC] Need help deciphering reboot modes!

[Will Deacon]

Hello,

As part of my kexec work, I've been looking at the machine_restart path on ARM
and, more specifically, the use of the reboot_mode character that gets passed
around and ultimately ignored.

It seems that the following mode characters are used:

0	-> Currently used by kexec as a dummy argument given that it is
	   ignored anyway.

'h'	-> The default assignment to reboot_mode and that used by
	   machine_restart. For some reason, reboot_mode can also be
	   overridden on the command line. I would guess that this means
	   "hard".

's'	-> A supported option by mioa701 (mach-pxa) and mach-s3c24xx. I
	   would guess that this means "soft".

'g'	-> A supported option by spitz and tosa (both mach-pxa). I can't
	   begin to imagine what it might stand for.

I would like to update this so that only 'h' and 's' are used, with the
following definitions:

- A hard reboot is made by poking something like a power controller and
  results in a complete platform reset. For this, we need to keep
  kernelspace mapped so that we can access the killer peripheral.

- A soft reboot is made by turning off the MMU and branching to some
  reset code (for example, the kexec reboot buffer). For this, we need
  to identity map as much memory as possible, including some of
  kernelspace.

Anyway, if anybody can enlighten me on the 'g' option, the reboot= parameter
and/or point out holes in my plan, please do! Failing that, I'll start
working on an RFC patch series next week.

Cheers,

Will

[RFC] Need help deciphering reboot modes!

[Will Deacon]

On Fri, Sep 30, 2011 at 01:57:25PM +0100, Will Deacon wrote:
> 'g'	-> A supported option by spitz and tosa (both mach-pxa). I can't
> 	   begin to imagine what it might stand for.

Aha! Some digging revealed this is a reset via GPIO and is specific to
mach-pxa. Maybe we can eliminate it with something like below:

Signed-off-by: Will Deacon <will.deacon@arm.com>

diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index 832888d..e85d31e 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -107,6 +107,9 @@ extern void __show_regs(struct pt_regs *);
 extern int cpu_architecture(void);
 extern void cpu_init(void);
 
+#define ARM_REBOOT_MODE_HARD   'h'
+#define ARM_REBOOT_MODE_SOFT   's'
+
 void arm_machine_restart(char mode, const char *cmd);
 extern void (*arm_pm_restart)(char str, const char *cmd);
diff --git a/arch/arm/mach-pxa/reset.c b/arch/arm/mach-pxa/reset.c
index 01e9d64..18556da 100644
--- a/arch/arm/mach-pxa/reset.c
+++ b/arch/arm/mach-pxa/reset.c
@@ -9,6 +9,7 @@
 #include <linux/gpio.h>
 #include <linux/io.h>
 #include <asm/proc-fns.h>
+#include <asm/system.h>
 
 #include <mach/regs-ost.h>
 #include <mach/reset.h>
@@ -54,8 +55,6 @@ out:
  */
 static void do_gpio_reset(void)
 {
-	BUG_ON(reset_gpio == -1);
-
 	/* drive it low */
 	gpio_direction_output(reset_gpio, 0);
 	mdelay(2);
@@ -69,8 +68,6 @@ static void do_gpio_reset(void)
 	mdelay(10);
 
 	WARN_ON(1);
-	/* fallback */
-	do_hw_reset();
 }
 
 static void do_hw_reset(void)
@@ -86,15 +83,14 @@ void arch_reset(char mode, const char *cmd)
 	clear_reset_status(RESET_STATUS_ALL);
 
 	switch (mode) {
-	case 's':
+	case ARM_REBOOT_MODE_SOFT:
 		/* Jump into ROM at address 0 */
 		cpu_reset(0);
 		break;
-	case 'g':
-		do_gpio_reset();
-		break;
-	case 'h':
+	case ARM_REBOOT_MODE_HARD:
 	default:
+		if (reset_gpio != -1)
+			do_gpio_reset();
 		do_hw_reset();
 		break;
 	}
diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c
index 438c7b5..34be135 100644
--- a/arch/arm/mach-pxa/spitz.c
+++ b/arch/arm/mach-pxa/spitz.c
@@ -925,7 +925,7 @@ static inline void spitz_i2c_init(void) {}
  ******************************************************************************/
 static void spitz_poweroff(void)
 {
-	arm_machine_restart('g', NULL);
+	arm_machine_restart(ARM_REBOOT_MODE_HARD, NULL);
 }
 
 static void spitz_restart(char mode, const char *cmd)
diff --git a/arch/arm/mach-pxa/tosa.c b/arch/arm/mach-pxa/tosa.c
index 9f69a26..e118933 100644
--- a/arch/arm/mach-pxa/tosa.c
+++ b/arch/arm/mach-pxa/tosa.c
@@ -905,7 +905,7 @@ static struct platform_device *devices[] __initdata = {
 
 static void tosa_poweroff(void)
 {
-	arm_machine_restart('g', NULL);
+	arm_machine_restart(ARM_REBOOT_MODE_HARD, NULL);
 }
 
 static void tosa_restart(char mode, const char *cmd)

[RFC] Need help deciphering reboot modes!

[Russell King - ARM Linux]

On Fri, Sep 30, 2011 at 01:57:25PM +0100, Will Deacon wrote:
> As part of my kexec work, I've been looking at the machine_restart path
> on ARM and, more specifically, the use of the reboot_mode character that
> gets passed around and ultimately ignored.

It gets ignored because platform maintainers are a lazy bunch of people
and don't want to write any more code than they absolutely have to.

Overall, it is meant as a hint to the platform code about what reboot
method to use.

> It seems that the following mode characters are used:
> 
> 0	-> Currently used by kexec as a dummy argument given that it is
> 	   ignored anyway.

No idea what that means, afaik it's never been used.

> 'h'	-> The default assignment to reboot_mode and that used by
> 	   machine_restart. For some reason, reboot_mode can also be
> 	   overridden on the command line. I would guess that this means
> 	   "hard".

It does mean 'hard' and it tells platforms which have the option (the
early ones do!) to use some hardware method to provoke the machine into
rebooting.

> 's'	-> A supported option by mioa701 (mach-pxa) and mach-s3c24xx. I
> 	   would guess that this means "soft".

This means to reboot by vectoring through the reset vector - so it is
'soft'.

> 'g'	-> A supported option by spitz and tosa (both mach-pxa). I can't
> 	   begin to imagine what it might stand for.

'gpio', using a gpio signal to cause the reboot rather than setting up
a watchdog or something to cause it.

Note that as I say above, it is only a hint - if you pass 's' for soft,
a platform can still elect to do a hard reboot if it knows that soft
reboots just don't work on the platform.

[RFC] Need help deciphering reboot modes!

[Will Deacon]

Hi Russell,

Thanks for getting back to me.

On Fri, Sep 30, 2011 at 08:18:48PM +0100, Russell King - ARM Linux wrote:
> On Fri, Sep 30, 2011 at 01:57:25PM +0100, Will Deacon wrote:
> > As part of my kexec work, I've been looking at the machine_restart path
> > on ARM and, more specifically, the use of the reboot_mode character that
> > gets passed around and ultimately ignored.
> 
> It gets ignored because platform maintainers are a lazy bunch of people
> and don't want to write any more code than they absolutely have to.
> 
> Overall, it is meant as a hint to the platform code about what reboot
> method to use.

Right, ok.

> > It seems that the following mode characters are used:
> > 
> > 0	-> Currently used by kexec as a dummy argument given that it is
> > 	   ignored anyway.
> 
> No idea what that means, afaik it's never been used.

I think it's just a lazy kexec implementation. Passing 's' would make more
sense.

> > 'h'	-> The default assignment to reboot_mode and that used by
> > 	   machine_restart. For some reason, reboot_mode can also be
> > 	   overridden on the command line. I would guess that this means
> > 	   "hard".
> 
> It does mean 'hard' and it tells platforms which have the option (the
> early ones do!) to use some hardware method to provoke the machine into
> rebooting.

So in terms of setup_mm_for_reboot (which takes the reboot mode as a
parameter), the 'h' mode should ensure that we don't remap kernelspace
as 1:1 because we need to poke hardware (alternatively we could poke the
hardware using its physical address).

> > 's'	-> A supported option by mioa701 (mach-pxa) and mach-s3c24xx. I
> > 	   would guess that this means "soft".
> 
> This means to reboot by vectoring through the reset vector - so it is
> 'soft'.

And in this case we want to identity map as much as possible so the MMU-off
path works properly.

> > 'g'	-> A supported option by spitz and tosa (both mach-pxa). I can't
> > 	   begin to imagine what it might stand for.
> 
> 'gpio', using a gpio signal to cause the reboot rather than setting up
> a watchdog or something to cause it.

Can we get rid of this option in favour of 'h'? I'm not sure I see the
distinction and I think the platform can handle it itself. I posted a patch
here but I'm unable to test it:

http://lists.infradead.org/pipermail/linux-arm-kernel/2011-September/067560.html

> Note that as I say above, it is only a hint - if you pass 's' for soft,
> a platform can still elect to do a hard reboot if it knows that soft
> reboots just don't work on the platform.

Hmm, this could be problematic with the memory mapping bits I mentioned
above. Going from 's' -> 'h' will only work if physical addresses are used
to access the hardware and going from 'h' -> 's' will only work if the
physical address of the reset code is less than PAGE_OFFSET. We could
introduce a new flag for setup_mm_for_reboot, but that feels slightly
redundant given that we already have the mode option.

What do you reckon?

Cheers,

Will