[02/12] ARM: OMAP3: Store reboot mode in scratchpad on OMAP34xx

Commit Message

Tony Lindgren March 10, 2009, 9:03 p.m. UTC

From: Juha Yrjola <[e-mail]>

The reboot mode can be communicated to a bootloader (or the
kernel itself) with a scratchpad register. This functionality
is especially useful, if userspace is allowed to change
the reboot mode.

Patch updated by Tony to also define the BOODMOD registers.

Signed-off-by: Juha Yrjola <[e-mail]>
Acked-by: Kevin Hilman <[e-mail]>
Signed-off-by: Tony Lindgren <[e-mail]>
---
 arch/arm/mach-omap2/prcm.c                |   14 ++++++++++++--
 arch/arm/plat-omap/include/mach/control.h |    9 +++++++++
 2 files changed, 21 insertions(+), 2 deletions(-)


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Russell King - ARM Linux March 15, 2009, 3:51 p.m. UTC | #1

On Tue, Mar 10, 2009 at 02:03:33PM -0700, Tony Lindgren wrote:
> From: Juha Yrjola <[e-mail]>
> 
> The reboot mode can be communicated to a bootloader (or the
> kernel itself) with a scratchpad register. This functionality
> is especially useful, if userspace is allowed to change
> the reboot mode.

The reason for this being...
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Juha Yrjola March 16, 2009, 4:07 p.m. UTC | #2

Russell King - ARM Linux wrote:

>> The reboot mode can be communicated to a bootloader (or the
>> kernel itself) with a scratchpad register. This functionality
>> is especially useful, if userspace is allowed to change
>> the reboot mode.
> 
> The reason for this being...

If my other patch [1] is applied, we are able to let user space tell the 
bootloader which mode to boot to.

On the Nokia Linux mobile devices, flashing is done mostly by the 
bootloader. If a USB host is connected at bootup, we enter a USB loop 
with a certain timeout. The timeout is disabled when the first flashing 
command arrives. This is no problem for Linux, but some unluckier 
operating systems are not able to even load their drivers quickly enough.

Hence, we need a way to let the bootloader know when to safely disable 
the timeout (when the user explicitly wants to perform flashing, that is).

Cheers,
Juha

[1] http://article.gmane.org/gmane.linux.ports.arm.kernel/53837
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Russell King - ARM Linux March 16, 2009, 5:10 p.m. UTC | #3

On Mon, Mar 16, 2009 at 06:07:07PM +0200, Juha Yrjola wrote:
> Russell King - ARM Linux wrote:
>>> The reboot mode can be communicated to a bootloader (or the
>>> kernel itself) with a scratchpad register. This functionality
>>> is especially useful, if userspace is allowed to change
>>> the reboot mode.
>>
>> The reason for this being...
>
> If my other patch [1] is applied, we are able to let user space tell the  
> bootloader which mode to boot to.
>
> On the Nokia Linux mobile devices, flashing is done mostly by the  
> bootloader. If a USB host is connected at bootup, we enter a USB loop  
> with a certain timeout. The timeout is disabled when the first flashing  
> command arrives. This is no problem for Linux, but some unluckier  
> operating systems are not able to even load their drivers quickly enough.
>
> Hence, we need a way to let the bootloader know when to safely disable  
> the timeout (when the user explicitly wants to perform flashing, that 
> is).

Right.  You are aware that there is already a mechanism for doing this
in the generic kernel (obviously not)?

sys_reboot() with LINUX_REBOOT_CMD_RESTART2 takes a string in addition
to the standard parameters.  This string is passed into machine_restart()
which we currently ignore.  If LINUX_REBOOT_CMD_RESTART is used, this
string is NULL.

We could change machine_restart() to pass this parameter through to
arm_pm_restart() and ultimately down to arch_reset().

That said, I don't see a version of reboot() which will pass a string
to the reboot() sysctl... there must be one around for the feature to
be present.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Juha Yrjola March 16, 2009, 5:40 p.m. UTC | #4

Russell King - ARM Linux wrote:

> Right.  You are aware that there is already a mechanism for doing this
> in the generic kernel (obviously not)?

I am. Unfortunately, glibc fails to support this mechanism, as you say. 
I didn't want to start making such intrusive changes for our trivial need.

> sys_reboot() with LINUX_REBOOT_CMD_RESTART2 takes a string in addition
> to the standard parameters.  This string is passed into machine_restart()
> which we currently ignore.  If LINUX_REBOOT_CMD_RESTART is used, this
> string is NULL.
> 
> We could change machine_restart() to pass this parameter through to
> arm_pm_restart() and ultimately down to arch_reset().

Sure. With RESTART2, I could've even used the reboot notifier chain with 
an OMAP3-specific driver to store the string.

Are you suggesting to get rid of reboot_mode altogether? If not, could 
we still have the sysfs mechanism? A one-character reboot_mode would be 
plenty enough for us.

Cheers,
Juha
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Russell King - ARM Linux March 16, 2009, 10:21 p.m. UTC | #5

On Mon, Mar 16, 2009 at 07:40:24PM +0200, Juha Yrjola wrote:
> Russell King - ARM Linux wrote:
>
>> Right.  You are aware that there is already a mechanism for doing this
>> in the generic kernel (obviously not)?
>
> I am. Unfortunately, glibc fails to support this mechanism, as you say.  
> I didn't want to start making such intrusive changes for our trivial 
> need.

Yes, glibc sucks with that - they hide the Linux reboot syscall.
Luckily, it is accessible via the syscall() interface:

#include <linux/reboot.h>

int sys_reboot(const char *cmd)
{
	return syscall(SYS_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2C,
			LINUX_REBOOT_CMD_RESTART2, cmd);
}

>> sys_reboot() with LINUX_REBOOT_CMD_RESTART2 takes a string in addition
>> to the standard parameters.  This string is passed into machine_restart()
>> which we currently ignore.  If LINUX_REBOOT_CMD_RESTART is used, this
>> string is NULL.
>>
>> We could change machine_restart() to pass this parameter through to
>> arm_pm_restart() and ultimately down to arch_reset().
>
> Sure. With RESTART2, I could've even used the reboot notifier chain with  
> an OMAP3-specific driver to store the string.

The notifier chain is called in any case.

> Are you suggesting to get rid of reboot_mode altogether? If not, could  
> we still have the sysfs mechanism? A one-character reboot_mode would be  
> plenty enough for us.

No, reboot mode tells _how_ to perform the reboot - whether that be
by hardware reset, gpio reset or a soft call via the reset address.
It's not supposed to tell the boot loader what to do.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Tony Lindgren March 18, 2009, 6:28 p.m. UTC | #6

* Russell King - ARM Linux <[e-mail]> [090316 15:22]:
> On Mon, Mar 16, 2009 at 07:40:24PM +0200, Juha Yrjola wrote:
> > Russell King - ARM Linux wrote:
> >
> >> Right.  You are aware that there is already a mechanism for doing this
> >> in the generic kernel (obviously not)?
> >
> > I am. Unfortunately, glibc fails to support this mechanism, as you say.  
> > I didn't want to start making such intrusive changes for our trivial 
> > need.
> 
> Yes, glibc sucks with that - they hide the Linux reboot syscall.
> Luckily, it is accessible via the syscall() interface:
> 
> #include <linux/reboot.h>
> 
> int sys_reboot(const char *cmd)
> {
> 	return syscall(SYS_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2C,
> 			LINUX_REBOOT_CMD_RESTART2, cmd);
> }
> 
> >> sys_reboot() with LINUX_REBOOT_CMD_RESTART2 takes a string in addition
> >> to the standard parameters.  This string is passed into machine_restart()
> >> which we currently ignore.  If LINUX_REBOOT_CMD_RESTART is used, this
> >> string is NULL.
> >>
> >> We could change machine_restart() to pass this parameter through to
> >> arm_pm_restart() and ultimately down to arch_reset().
> >
> > Sure. With RESTART2, I could've even used the reboot notifier chain with  
> > an OMAP3-specific driver to store the string.
> 
> The notifier chain is called in any case.
> 
> > Are you suggesting to get rid of reboot_mode altogether? If not, could  
> > we still have the sysfs mechanism? A one-character reboot_mode would be  
> > plenty enough for us.
> 
> No, reboot mode tells _how_ to perform the reboot - whether that be
> by hardware reset, gpio reset or a soft call via the reset address.
> It's not supposed to tell the boot loader what to do.

So if the reboot mode can't be used for this.. Should we change Juha's
sysfs interface patch to store something else like bootloader_mode?

I guess we cannot use kexec for this either?

Tony

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Russell King - ARM Linux March 18, 2009, 7:26 p.m. UTC | #7

On Wed, Mar 18, 2009 at 11:28:06AM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux <[e-mail]> [090316 15:22]:
> > On Mon, Mar 16, 2009 at 07:40:24PM +0200, Juha Yrjola wrote:
> > > Russell King - ARM Linux wrote:
> > >
> > >> Right.  You are aware that there is already a mechanism for doing this
> > >> in the generic kernel (obviously not)?
> > >
> > > I am. Unfortunately, glibc fails to support this mechanism, as you say.  
> > > I didn't want to start making such intrusive changes for our trivial 
> > > need.
> > 
> > Yes, glibc sucks with that - they hide the Linux reboot syscall.
> > Luckily, it is accessible via the syscall() interface:
> > 
> > #include <linux/reboot.h>
> > 
> > int sys_reboot(const char *cmd)
> > {
> > 	return syscall(SYS_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2C,
> > 			LINUX_REBOOT_CMD_RESTART2, cmd);
> > }
> > 
> > >> sys_reboot() with LINUX_REBOOT_CMD_RESTART2 takes a string in addition
> > >> to the standard parameters.  This string is passed into machine_restart()
> > >> which we currently ignore.  If LINUX_REBOOT_CMD_RESTART is used, this
> > >> string is NULL.
> > >>
> > >> We could change machine_restart() to pass this parameter through to
> > >> arm_pm_restart() and ultimately down to arch_reset().
> > >
> > > Sure. With RESTART2, I could've even used the reboot notifier chain with  
> > > an OMAP3-specific driver to store the string.
> > 
> > The notifier chain is called in any case.
> > 
> > > Are you suggesting to get rid of reboot_mode altogether? If not, could  
> > > we still have the sysfs mechanism? A one-character reboot_mode would be  
> > > plenty enough for us.
> > 
> > No, reboot mode tells _how_ to perform the reboot - whether that be
> > by hardware reset, gpio reset or a soft call via the reset address.
> > It's not supposed to tell the boot loader what to do.
> 
> So if the reboot mode can't be used for this.. Should we change Juha's
> sysfs interface patch to store something else like bootloader_mode?
> 
> I guess we cannot use kexec for this either?

Why not use the mechanism that's already there as I've already pointed
out?

Yes, glibc might be fscked in the head over the reboot() prototype but
that's easy to work-around as I've demonstrated.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Tony Lindgren March 18, 2009, 8:10 p.m. UTC | #8

* Russell King - ARM Linux <[e-mail]> [090318 12:26]:
> On Wed, Mar 18, 2009 at 11:28:06AM -0700, Tony Lindgren wrote:
> > * Russell King - ARM Linux <[e-mail]> [090316 15:22]:
> > > On Mon, Mar 16, 2009 at 07:40:24PM +0200, Juha Yrjola wrote:
> > > > Russell King - ARM Linux wrote:
> > > >
> > > >> Right.  You are aware that there is already a mechanism for doing this
> > > >> in the generic kernel (obviously not)?
> > > >
> > > > I am. Unfortunately, glibc fails to support this mechanism, as you say.  
> > > > I didn't want to start making such intrusive changes for our trivial 
> > > > need.
> > > 
> > > Yes, glibc sucks with that - they hide the Linux reboot syscall.
> > > Luckily, it is accessible via the syscall() interface:
> > > 
> > > #include <linux/reboot.h>
> > > 
> > > int sys_reboot(const char *cmd)
> > > {
> > > 	return syscall(SYS_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2C,
> > > 			LINUX_REBOOT_CMD_RESTART2, cmd);
> > > }
> > > 
> > > >> sys_reboot() with LINUX_REBOOT_CMD_RESTART2 takes a string in addition
> > > >> to the standard parameters.  This string is passed into machine_restart()
> > > >> which we currently ignore.  If LINUX_REBOOT_CMD_RESTART is used, this
> > > >> string is NULL.
> > > >>
> > > >> We could change machine_restart() to pass this parameter through to
> > > >> arm_pm_restart() and ultimately down to arch_reset().
> > > >
> > > > Sure. With RESTART2, I could've even used the reboot notifier chain with  
> > > > an OMAP3-specific driver to store the string.
> > > 
> > > The notifier chain is called in any case.
> > > 
> > > > Are you suggesting to get rid of reboot_mode altogether? If not, could  
> > > > we still have the sysfs mechanism? A one-character reboot_mode would be  
> > > > plenty enough for us.
> > > 
> > > No, reboot mode tells _how_ to perform the reboot - whether that be
> > > by hardware reset, gpio reset or a soft call via the reset address.
> > > It's not supposed to tell the boot loader what to do.
> > 
> > So if the reboot mode can't be used for this.. Should we change Juha's
> > sysfs interface patch to store something else like bootloader_mode?
> > 
> > I guess we cannot use kexec for this either?
> 
> Why not use the mechanism that's already there as I've already pointed
> out?

Sorry I misunderstood, I thought you did not want to use reboot_mode
for this at all..

To recap, so we change machine_restart() like you described above, and then
this patch is still valid, except to update the description.

Juha, does that sound OK to you?

> Yes, glibc might be fscked in the head over the reboot() prototype but
> that's easy to work-around as I've demonstrated.

Yeah sounds good to me.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Tony Lindgren March 18, 2009, 8:15 p.m. UTC | #9

* Tony Lindgren <[e-mail]> [090318 13:09]:
> * Russell King - ARM Linux <[e-mail]> [090318 12:26]:
> > On Wed, Mar 18, 2009 at 11:28:06AM -0700, Tony Lindgren wrote:
> > > * Russell King - ARM Linux <[e-mail]> [090316 15:22]:
> > > > On Mon, Mar 16, 2009 at 07:40:24PM +0200, Juha Yrjola wrote:
> > > > > Russell King - ARM Linux wrote:
> > > > >
> > > > >> Right.  You are aware that there is already a mechanism for doing this
> > > > >> in the generic kernel (obviously not)?
> > > > >
> > > > > I am. Unfortunately, glibc fails to support this mechanism, as you say.  
> > > > > I didn't want to start making such intrusive changes for our trivial 
> > > > > need.
> > > > 
> > > > Yes, glibc sucks with that - they hide the Linux reboot syscall.
> > > > Luckily, it is accessible via the syscall() interface:
> > > > 
> > > > #include <linux/reboot.h>
> > > > 
> > > > int sys_reboot(const char *cmd)
> > > > {
> > > > 	return syscall(SYS_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2C,
> > > > 			LINUX_REBOOT_CMD_RESTART2, cmd);
> > > > }
> > > > 
> > > > >> sys_reboot() with LINUX_REBOOT_CMD_RESTART2 takes a string in addition
> > > > >> to the standard parameters.  This string is passed into machine_restart()
> > > > >> which we currently ignore.  If LINUX_REBOOT_CMD_RESTART is used, this
> > > > >> string is NULL.
> > > > >>
> > > > >> We could change machine_restart() to pass this parameter through to
> > > > >> arm_pm_restart() and ultimately down to arch_reset().
> > > > >
> > > > > Sure. With RESTART2, I could've even used the reboot notifier chain with  
> > > > > an OMAP3-specific driver to store the string.
> > > > 
> > > > The notifier chain is called in any case.
> > > > 
> > > > > Are you suggesting to get rid of reboot_mode altogether? If not, could  
> > > > > we still have the sysfs mechanism? A one-character reboot_mode would be  
> > > > > plenty enough for us.
> > > > 
> > > > No, reboot mode tells _how_ to perform the reboot - whether that be
> > > > by hardware reset, gpio reset or a soft call via the reset address.
> > > > It's not supposed to tell the boot loader what to do.
> > > 
> > > So if the reboot mode can't be used for this.. Should we change Juha's
> > > sysfs interface patch to store something else like bootloader_mode?
> > > 
> > > I guess we cannot use kexec for this either?
> > 
> > Why not use the mechanism that's already there as I've already pointed
> > out?
> 
> Sorry I misunderstood, I thought you did not want to use reboot_mode
> for this at all..
> 
> To recap, so we change machine_restart() like you described above, and then
> this patch is still valid, except to update the description.

Hmm, after reading it one more time..

Russell you want to pass char *cmd in addition to reboot_mode, right?
And Juha's patch needs to be updated to use the cmd instead of reboot_mode?
 
> Juha, does that sound OK to you?
> 
> > Yes, glibc might be fscked in the head over the reboot() prototype but
> > that's easy to work-around as I've demonstrated.
> 
> Yeah sounds good to me.
> 
> Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Tony Lindgren March 24, 2009, 1:11 a.m. UTC | #10

* Tony Lindgren <[e-mail]> [090310 14:04]:
> From: Juha Yrjola <[e-mail]>
> 
> The reboot mode can be communicated to a bootloader (or the
> kernel itself) with a scratchpad register. This functionality
> is especially useful, if userspace is allowed to change
> the reboot mode.
> 
> Patch updated by Tony to also define the BOODMOD registers.

Dropping this from my upstream queue for now, it sounds like
we can apply it as a fix after it's been updated to use cmd
instead of mode.

Tony

 
> Signed-off-by: Juha Yrjola <[e-mail]>
> Acked-by: Kevin Hilman <[e-mail]>
> Signed-off-by: Tony Lindgren <[e-mail]>
> ---
>  arch/arm/mach-omap2/prcm.c                |   14 ++++++++++++--
>  arch/arm/plat-omap/include/mach/control.h |    9 +++++++++
>  2 files changed, 21 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
> index f945156..12c0e03 100644
> --- a/arch/arm/mach-omap2/prcm.c
> +++ b/arch/arm/mach-omap2/prcm.c
> @@ -19,6 +19,7 @@
>  #include <linux/io.h>
>  
>  #include <mach/common.h>
> +#include <mach/control.h>
>  #include <mach/prcm.h>
>  
>  #include "clock.h"
> @@ -43,9 +44,18 @@ void omap_prcm_arch_reset(char mode)
>  
>  	if (cpu_is_omap24xx())
>  		prcm_offs = WKUP_MOD;
> -	else if (cpu_is_omap34xx())
> +	else if (cpu_is_omap34xx()) {
> +		u32 l;
> +
>  		prcm_offs = OMAP3430_GR_MOD;
> -	else
> +		l = ('B' << 24) | ('M' << 16) | mode;
> +		/* Reserve the first word in scratchpad for communicating
> +		 * with the boot ROM. A pointer to a data structure
> +		 * describing the boot process can be stored there,
> +		 * cf. OMAP34xx TRM, Initialization / Software Booting
> +		 * Configuration. */
> +		omap_writel(l, OMAP343X_SCRATCHPAD + 4);
> +	} else
>  		WARN_ON(1);
>  
>  	prm_set_mod_reg_bits(OMAP_RST_DPLL3, prcm_offs, RM_RSTCTRL);
> diff --git a/arch/arm/plat-omap/include/mach/control.h b/arch/arm/plat-omap/include/mach/control.h
> index 269147f..1e1bcff 100644
> --- a/arch/arm/plat-omap/include/mach/control.h
> +++ b/arch/arm/plat-omap/include/mach/control.h
> @@ -189,6 +189,15 @@
>  #define OMAP2_PBIASLITEPWRDNZ0		(1 << 1)
>  #define OMAP2_PBIASLITEVMODE0		(1 << 0)
>  
> +/* CONTROL_IVA2_BOOTMOD bits */
> +#define OMAP3_IVA2_BOOTMOD_SHIFT	0
> +#define OMAP3_IVA2_BOOTMOD_MASK		(0xf << 0)
> +#define OMAP3_IVA2_BOOTMOD_IDLE		(0x1 << 0)
> +
> +#define OMAP343X_SCRATCHPAD_ROM		(OMAP343X_CTRL_BASE + 0x860)
> +#define OMAP343X_SCRATCHPAD		(OMAP343X_CTRL_BASE + 0x910)
> +#define OMAP343X_SCRATCHPAD_ROM_OFFSET	0x19C
> +
>  #ifndef __ASSEMBLY__
>  #if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
>  extern void __iomem *omap_ctrl_base_get(void);
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [e-mail]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index f945156..12c0e03 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -19,6 +19,7 @@ 
 #include <linux/io.h>
 
 #include <mach/common.h>
+#include <mach/control.h>
 #include <mach/prcm.h>
 
 #include "clock.h"
@@ -43,9 +44,18 @@  void omap_prcm_arch_reset(char mode)
 
 	if (cpu_is_omap24xx())
 		prcm_offs = WKUP_MOD;
-	else if (cpu_is_omap34xx())
+	else if (cpu_is_omap34xx()) {
+		u32 l;
+
 		prcm_offs = OMAP3430_GR_MOD;
-	else
+		l = ('B' << 24) | ('M' << 16) | mode;
+		/* Reserve the first word in scratchpad for communicating
+		 * with the boot ROM. A pointer to a data structure
+		 * describing the boot process can be stored there,
+		 * cf. OMAP34xx TRM, Initialization / Software Booting
+		 * Configuration. */
+		omap_writel(l, OMAP343X_SCRATCHPAD + 4);
+	} else
 		WARN_ON(1);
 
 	prm_set_mod_reg_bits(OMAP_RST_DPLL3, prcm_offs, RM_RSTCTRL);
diff --git a/arch/arm/plat-omap/include/mach/control.h b/arch/arm/plat-omap/include/mach/control.h
index 269147f..1e1bcff 100644
--- a/arch/arm/plat-omap/include/mach/control.h
+++ b/arch/arm/plat-omap/include/mach/control.h
@@ -189,6 +189,15 @@ 
 #define OMAP2_PBIASLITEPWRDNZ0		(1 << 1)
 #define OMAP2_PBIASLITEVMODE0		(1 << 0)
 
+/* CONTROL_IVA2_BOOTMOD bits */
+#define OMAP3_IVA2_BOOTMOD_SHIFT	0
+#define OMAP3_IVA2_BOOTMOD_MASK		(0xf << 0)
+#define OMAP3_IVA2_BOOTMOD_IDLE		(0x1 << 0)
+
+#define OMAP343X_SCRATCHPAD_ROM		(OMAP343X_CTRL_BASE + 0x860)
+#define OMAP343X_SCRATCHPAD		(OMAP343X_CTRL_BASE + 0x910)
+#define OMAP343X_SCRATCHPAD_ROM_OFFSET	0x19C
+
 #ifndef __ASSEMBLY__
 #if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
 extern void __iomem *omap_ctrl_base_get(void);