Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error

2013-02-18 Thread Shawn Guo 
On Mon, Feb 18, 2013 at 11:11:30PM -0500, Nicolas Pitre wrote:
> On Tue, 19 Feb 2013, Shawn Guo wrote:
> 
> > On Mon, Feb 18, 2013 at 12:06:32PM -0500, Nicolas Pitre wrote:
> > > Try the following instead.  It makes the code simpler and easier to 
> > > debug.
> > > 
> > It works now.  Thanks, Nico.  Care to send a patch for it?  I'd like
> > to apply it.
> 
> - >8
> 
> FRom: Nicolas Pitre 
> Date: Mon, 18 Feb 2013 12:06:32 -0500 (EST)
> Subject: ARM: mach-imx: move early resume code out of the .data section
> 
> Building the kernel with allyesconfig fails because the i.mx early
> resume code located in the .data section is unable to fixup the bl
> relocation as the branch target gets too far away.
> 
> The idea of having code in the .data section allows for easy access to 
> nearby data using relative addressing while the MMU is off. However it 
> is probably best to move the code back to the .text section where it 
> belongs and fixup the data access instead.  This solves the bl reloc
> issue (at least until this becomes a general problem) and simplifies
> the code as well.
> 
> Signed-off-by: Nicolas Pitre 

Applied as a fix for 3.9-rc, thanks.

Shawn

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error

2013-02-18 Thread Nicolas Pitre 
On Tue, 19 Feb 2013, Shawn Guo wrote:

> On Mon, Feb 18, 2013 at 12:06:32PM -0500, Nicolas Pitre wrote:
> > Try the following instead.  It makes the code simpler and easier to 
> > debug.
> > 
> It works now.  Thanks, Nico.  Care to send a patch for it?  I'd like
> to apply it.

- >8

FRom: Nicolas Pitre 
Date: Mon, 18 Feb 2013 12:06:32 -0500 (EST)
Subject: ARM: mach-imx: move early resume code out of the .data section

Building the kernel with allyesconfig fails because the i.mx early
resume code located in the .data section is unable to fixup the bl
relocation as the branch target gets too far away.

The idea of having code in the .data section allows for easy access to 
nearby data using relative addressing while the MMU is off. However it 
is probably best to move the code back to the .text section where it 
belongs and fixup the data access instead.  This solves the bl reloc
issue (at least until this becomes a general problem) and simplifies
the code as well.

Signed-off-by: Nicolas Pitre 
---

I'll probably convert other "code in .data" instances as well in the 
near future.

diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
index 7e49deb128..27bc06e910 100644
--- a/arch/arm/mach-imx/headsmp.S
+++ b/arch/arm/mach-imx/headsmp.S
@@ -73,16 +73,16 @@ ENDPROC(v7_secondary_startup)
 
 #ifdef CONFIG_PM
 /*
- * The following code is located into the .data section.  This is to
- * allow phys_l2x0_saved_regs to be accessed with a relative load
- * as we are running on physical address here.
+ * The following code must assume it is running from physical address
+ * where absolute virtual addresses to the data section have to be
+ * turned into relative ones.
  */
-   .data
-   .align
 
 #ifdef CONFIG_CACHE_L2X0
.macro  pl310_resume
-   ldr r2, phys_l2x0_saved_regs
+   adr r0, l2x0_saved_regs_offset
+   ldr r2, [r0]
+   add r2, r2, r0
ldr r0, [r2, #L2X0_R_PHY_BASE]  @ get physical base of l2x0
ldr r1, [r2, #L2X0_R_AUX_CTRL]  @ get aux_ctrl value
str r1, [r0, #L2X0_AUX_CTRL]@ restore aux_ctrl
@@ -90,9 +90,9 @@ ENDPROC(v7_secondary_startup)
str r1, [r0, #L2X0_CTRL]@ re-enable L2
.endm
 
-   .globl  phys_l2x0_saved_regs
-phys_l2x0_saved_regs:
-.long   0
+l2x0_saved_regs_offset:
+   .word   l2x0_saved_regs - .
+
 #else
.macro  pl310_resume
.endm
diff --git a/arch/arm/mach-imx/pm-imx6q.c b/arch/arm/mach-imx/pm-imx6q.c
index f7b0c2b1b9..f3791f980d 100644
--- a/arch/arm/mach-imx/pm-imx6q.c
+++ b/arch/arm/mach-imx/pm-imx6q.c
@@ -21,8 +21,6 @@
 #include 
 #include 
 
-extern unsigned long phys_l2x0_saved_regs;
-
 static int imx6q_suspend_finish(unsigned long val)
 {
cpu_do_idle();
@@ -55,18 +53,5 @@ static const struct platform_suspend_ops imx6q_pm_ops = {
 
 void __init imx6q_pm_init(void)
 {
-   /*
-* The l2x0 core code provides an infrastucture to save and restore
-* l2x0 registers across suspend/resume cycle.  But because imx6q
-* retains L2 content during suspend and needs to resume L2 before
-* MMU is enabled, it can only utilize register saving support and
-* have to take care of restoring on its own.  So we save physical
-* address of the data structure used by l2x0 core to save registers,
-* and later restore the necessary ones in imx6q resume entry.
-*/
-#ifdef CONFIG_CACHE_L2X0
-   phys_l2x0_saved_regs = __pa(_saved_regs);
-#endif
-
suspend_set_ops(_pm_ops);
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error

2013-02-18 Thread Shawn Guo 
On Mon, Feb 18, 2013 at 12:06:32PM -0500, Nicolas Pitre wrote:
> Try the following instead.  It makes the code simpler and easier to 
> debug.
> 
It works now.  Thanks, Nico.  Care to send a patch for it?  I'd like
to apply it.

Shawn

> diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
> index 7e49deb128..27bc06e910 100644
> --- a/arch/arm/mach-imx/headsmp.S
> +++ b/arch/arm/mach-imx/headsmp.S
> @@ -73,16 +73,16 @@ ENDPROC(v7_secondary_startup)
>  
>  #ifdef CONFIG_PM
>  /*
> - * The following code is located into the .data section.  This is to
> - * allow phys_l2x0_saved_regs to be accessed with a relative load
> - * as we are running on physical address here.
> + * The following code must assume it is running from physical address
> + * where absolute virtual addresses to the data section have to be
> + * turned into relative ones.
>   */
> - .data
> - .align
>  
>  #ifdef CONFIG_CACHE_L2X0
>   .macro  pl310_resume
> - ldr r2, phys_l2x0_saved_regs
> + adr r0, l2x0_saved_regs_offset
> + ldr r2, [r0]
> + add r2, r2, r0
>   ldr r0, [r2, #L2X0_R_PHY_BASE]  @ get physical base of l2x0
>   ldr r1, [r2, #L2X0_R_AUX_CTRL]  @ get aux_ctrl value
>   str r1, [r0, #L2X0_AUX_CTRL]@ restore aux_ctrl
> @@ -90,9 +90,9 @@ ENDPROC(v7_secondary_startup)
>   str r1, [r0, #L2X0_CTRL]@ re-enable L2
>   .endm
>  
> - .globl  phys_l2x0_saved_regs
> -phys_l2x0_saved_regs:
> -.long   0
> +l2x0_saved_regs_offset:
> + .word   l2x0_saved_regs - .
> +
>  #else
>   .macro  pl310_resume
>   .endm
> diff --git a/arch/arm/mach-imx/pm-imx6q.c b/arch/arm/mach-imx/pm-imx6q.c
> index f7b0c2b1b9..f3791f980d 100644
> --- a/arch/arm/mach-imx/pm-imx6q.c
> +++ b/arch/arm/mach-imx/pm-imx6q.c
> @@ -21,8 +21,6 @@
>  #include 
>  #include 
>  
> -extern unsigned long phys_l2x0_saved_regs;
> -
>  static int imx6q_suspend_finish(unsigned long val)
>  {
>   cpu_do_idle();
> @@ -55,18 +53,5 @@ static const struct platform_suspend_ops imx6q_pm_ops = {
>  
>  void __init imx6q_pm_init(void)
>  {
> - /*
> -  * The l2x0 core code provides an infrastucture to save and restore
> -  * l2x0 registers across suspend/resume cycle.  But because imx6q
> -  * retains L2 content during suspend and needs to resume L2 before
> -  * MMU is enabled, it can only utilize register saving support and
> -  * have to take care of restoring on its own.  So we save physical
> -  * address of the data structure used by l2x0 core to save registers,
> -  * and later restore the necessary ones in imx6q resume entry.
> -  */
> -#ifdef CONFIG_CACHE_L2X0
> - phys_l2x0_saved_regs = __pa(_saved_regs);
> -#endif
> -
>   suspend_set_ops(_pm_ops);
>  }
> 
> Nicolas

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error

2013-02-18 Thread Nicolas Pitre 
On Mon, 18 Feb 2013, Shawn Guo wrote:

> On Sat, Feb 16, 2013 at 12:14:49AM -0500, Nicolas Pitre wrote:
> > Something like this should work:
> > 
> > diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
> > index 7e49deb128..9de26f3edb 100644
> > --- a/arch/arm/mach-imx/headsmp.S
> > +++ b/arch/arm/mach-imx/headsmp.S
> > @@ -99,8 +99,11 @@ phys_l2x0_saved_regs:
> >  #endif
> >  
> >  ENTRY(v7_cpu_resume)
> > -   bl  v7_invalidate_l1
> > +   ldr ip, 2f
> > +   mov lr, pc
> > +1: add pc, pc, ip
> > pl310_resume
> > b   cpu_resume
> > +2: .word v7_invalidate_l1 - 1b - 8
> >  ENDPROC(v7_cpu_resume)
> >  #endif
> > 
> Yes, it works.
> 
> > 
> > However it is probably best to move all the code to the .text section 
> > where it belongs and fixup the data access instead.  I must plead guilty 
> > for introducing this idea of putting code in the .data section with the 
> > SA1100resume code over 10 years ago that everyone copied since.
> > 
> > So here's how I think it should look instead, and how I should have done 
> > the SA1100 code back then:
> > 
> > diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
> > index 7e49deb128..38a544a037 100644
> > --- a/arch/arm/mach-imx/headsmp.S
> > +++ b/arch/arm/mach-imx/headsmp.S
> > @@ -73,16 +73,16 @@ ENDPROC(v7_secondary_startup)
> >  
> >  #ifdef CONFIG_PM
> >  /*
> > - * The following code is located into the .data section.  This is to
> > - * allow phys_l2x0_saved_regs to be accessed with a relative load
> > - * as we are running on physical address here.
> > + * The following code must assume it is running from physical address
> > + * where absolute virtual addresses to the data section have to be
> > + * turned into relative ones.
> >   */
> > -   .data
> > -   .align
> >  
> >  #ifdef CONFIG_CACHE_L2X0
> > .macro  pl310_resume
> > -   ldr r2, phys_l2x0_saved_regs
> > +   adr r0, phys_l2x0_saved_ptr_offset
> > +   ldr r2, [r0]
> > +   add r2, r2, r0
> > ldr r0, [r2, #L2X0_R_PHY_BASE]  @ get physical base of l2x0
> > ldr r1, [r2, #L2X0_R_AUX_CTRL]  @ get aux_ctrl value
> > str r1, [r0, #L2X0_AUX_CTRL]@ restore aux_ctrl
> > @@ -90,9 +90,13 @@ ENDPROC(v7_secondary_startup)
> > str r1, [r0, #L2X0_CTRL]@ re-enable L2
> > .endm
> >  
> > +   .bss
> > .globl  phys_l2x0_saved_regs
> >  phys_l2x0_saved_regs:
> > -.long   0
> > +.space   4
> > +   .previous
> > +phys_l2x0_saved_ptr_offset:
> > +   .word   phys_l2x0_saved_regs - .
> >  #else
> > .macro  pl310_resume
> > .endm
> > 
> But this does not work.  It seems the execution jumps to the start of
> kernel on system resuming.

Try the following instead.  It makes the code simpler and easier to 
debug.

diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
index 7e49deb128..27bc06e910 100644
--- a/arch/arm/mach-imx/headsmp.S
+++ b/arch/arm/mach-imx/headsmp.S
@@ -73,16 +73,16 @@ ENDPROC(v7_secondary_startup)
 
 #ifdef CONFIG_PM
 /*
- * The following code is located into the .data section.  This is to
- * allow phys_l2x0_saved_regs to be accessed with a relative load
- * as we are running on physical address here.
+ * The following code must assume it is running from physical address
+ * where absolute virtual addresses to the data section have to be
+ * turned into relative ones.
  */
-   .data
-   .align
 
 #ifdef CONFIG_CACHE_L2X0
.macro  pl310_resume
-   ldr r2, phys_l2x0_saved_regs
+   adr r0, l2x0_saved_regs_offset
+   ldr r2, [r0]
+   add r2, r2, r0
ldr r0, [r2, #L2X0_R_PHY_BASE]  @ get physical base of l2x0
ldr r1, [r2, #L2X0_R_AUX_CTRL]  @ get aux_ctrl value
str r1, [r0, #L2X0_AUX_CTRL]@ restore aux_ctrl
@@ -90,9 +90,9 @@ ENDPROC(v7_secondary_startup)
str r1, [r0, #L2X0_CTRL]@ re-enable L2
.endm
 
-   .globl  phys_l2x0_saved_regs
-phys_l2x0_saved_regs:
-.long   0
+l2x0_saved_regs_offset:
+   .word   l2x0_saved_regs - .
+
 #else
.macro  pl310_resume
.endm
diff --git a/arch/arm/mach-imx/pm-imx6q.c b/arch/arm/mach-imx/pm-imx6q.c
index f7b0c2b1b9..f3791f980d 100644
--- a/arch/arm/mach-imx/pm-imx6q.c
+++ b/arch/arm/mach-imx/pm-imx6q.c
@@ -21,8 +21,6 @@
 #include 
 #include 
 
-extern unsigned long phys_l2x0_saved_regs;
-
 static int imx6q_suspend_finish(unsigned long val)
 {
cpu_do_idle();
@@ -55,18 +53,5 @@ static const struct platform_suspend_ops imx6q_pm_ops = {
 
 void __init imx6q_pm_init(void)
 {
-   /*
-* The l2x0 core code provides an infrastucture to save and restore
-* l2x0 registers across suspend/resume cycle.  But because imx6q
-* retains L2 content during suspend and needs to resume L2 before
-* MMU is enabled, it can only utilize register saving support and
-* have to take care of restoring on its own.

Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error

2013-02-18 Thread Nicolas Pitre 
On Mon, 18 Feb 2013, Shawn Guo wrote:

 On Sat, Feb 16, 2013 at 12:14:49AM -0500, Nicolas Pitre wrote:
  Something like this should work:
  
  diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
  index 7e49deb128..9de26f3edb 100644
  --- a/arch/arm/mach-imx/headsmp.S
  +++ b/arch/arm/mach-imx/headsmp.S
  @@ -99,8 +99,11 @@ phys_l2x0_saved_regs:
   #endif
   
   ENTRY(v7_cpu_resume)
  -   bl  v7_invalidate_l1
  +   ldr ip, 2f
  +   mov lr, pc
  +1: add pc, pc, ip
  pl310_resume
  b   cpu_resume
  +2: .word v7_invalidate_l1 - 1b - 8
   ENDPROC(v7_cpu_resume)
   #endif
  
 Yes, it works.
 
  
  However it is probably best to move all the code to the .text section 
  where it belongs and fixup the data access instead.  I must plead guilty 
  for introducing this idea of putting code in the .data section with the 
  SA1100resume code over 10 years ago that everyone copied since.
  
  So here's how I think it should look instead, and how I should have done 
  the SA1100 code back then:
  
  diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
  index 7e49deb128..38a544a037 100644
  --- a/arch/arm/mach-imx/headsmp.S
  +++ b/arch/arm/mach-imx/headsmp.S
  @@ -73,16 +73,16 @@ ENDPROC(v7_secondary_startup)
   
   #ifdef CONFIG_PM
   /*
  - * The following code is located into the .data section.  This is to
  - * allow phys_l2x0_saved_regs to be accessed with a relative load
  - * as we are running on physical address here.
  + * The following code must assume it is running from physical address
  + * where absolute virtual addresses to the data section have to be
  + * turned into relative ones.
*/
  -   .data
  -   .align
   
   #ifdef CONFIG_CACHE_L2X0
  .macro  pl310_resume
  -   ldr r2, phys_l2x0_saved_regs
  +   adr r0, phys_l2x0_saved_ptr_offset
  +   ldr r2, [r0]
  +   add r2, r2, r0
  ldr r0, [r2, #L2X0_R_PHY_BASE]  @ get physical base of l2x0
  ldr r1, [r2, #L2X0_R_AUX_CTRL]  @ get aux_ctrl value
  str r1, [r0, #L2X0_AUX_CTRL]@ restore aux_ctrl
  @@ -90,9 +90,13 @@ ENDPROC(v7_secondary_startup)
  str r1, [r0, #L2X0_CTRL]@ re-enable L2
  .endm
   
  +   .bss
  .globl  phys_l2x0_saved_regs
   phys_l2x0_saved_regs:
  -.long   0
  +.space   4
  +   .previous
  +phys_l2x0_saved_ptr_offset:
  +   .word   phys_l2x0_saved_regs - .
   #else
  .macro  pl310_resume
  .endm
  
 But this does not work.  It seems the execution jumps to the start of
 kernel on system resuming.

Try the following instead.  It makes the code simpler and easier to 
debug.

diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
index 7e49deb128..27bc06e910 100644
--- a/arch/arm/mach-imx/headsmp.S
+++ b/arch/arm/mach-imx/headsmp.S
@@ -73,16 +73,16 @@ ENDPROC(v7_secondary_startup)
 
 #ifdef CONFIG_PM
 /*
- * The following code is located into the .data section.  This is to
- * allow phys_l2x0_saved_regs to be accessed with a relative load
- * as we are running on physical address here.
+ * The following code must assume it is running from physical address
+ * where absolute virtual addresses to the data section have to be
+ * turned into relative ones.
  */
-   .data
-   .align
 
 #ifdef CONFIG_CACHE_L2X0
.macro  pl310_resume
-   ldr r2, phys_l2x0_saved_regs
+   adr r0, l2x0_saved_regs_offset
+   ldr r2, [r0]
+   add r2, r2, r0
ldr r0, [r2, #L2X0_R_PHY_BASE]  @ get physical base of l2x0
ldr r1, [r2, #L2X0_R_AUX_CTRL]  @ get aux_ctrl value
str r1, [r0, #L2X0_AUX_CTRL]@ restore aux_ctrl
@@ -90,9 +90,9 @@ ENDPROC(v7_secondary_startup)
str r1, [r0, #L2X0_CTRL]@ re-enable L2
.endm
 
-   .globl  phys_l2x0_saved_regs
-phys_l2x0_saved_regs:
-.long   0
+l2x0_saved_regs_offset:
+   .word   l2x0_saved_regs - .
+
 #else
.macro  pl310_resume
.endm
diff --git a/arch/arm/mach-imx/pm-imx6q.c b/arch/arm/mach-imx/pm-imx6q.c
index f7b0c2b1b9..f3791f980d 100644
--- a/arch/arm/mach-imx/pm-imx6q.c
+++ b/arch/arm/mach-imx/pm-imx6q.c
@@ -21,8 +21,6 @@
 #include mach/common.h
 #include mach/hardware.h
 
-extern unsigned long phys_l2x0_saved_regs;
-
 static int imx6q_suspend_finish(unsigned long val)
 {
cpu_do_idle();
@@ -55,18 +53,5 @@ static const struct platform_suspend_ops imx6q_pm_ops = {
 
 void __init imx6q_pm_init(void)
 {
-   /*
-* The l2x0 core code provides an infrastucture to save and restore
-* l2x0 registers across suspend/resume cycle.  But because imx6q
-* retains L2 content during suspend and needs to resume L2 before
-* MMU is enabled, it can only utilize register saving support and
-* have to take care of restoring on its own.  So we save physical
-* address of the data structure used by l2x0 core to save registers,
-* and later

Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error

2013-02-18 Thread Shawn Guo 
On Mon, Feb 18, 2013 at 12:06:32PM -0500, Nicolas Pitre wrote:
 Try the following instead.  It makes the code simpler and easier to 
 debug.
 
It works now.  Thanks, Nico.  Care to send a patch for it?  I'd like
to apply it.

Shawn

 diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
 index 7e49deb128..27bc06e910 100644
 --- a/arch/arm/mach-imx/headsmp.S
 +++ b/arch/arm/mach-imx/headsmp.S
 @@ -73,16 +73,16 @@ ENDPROC(v7_secondary_startup)
  
  #ifdef CONFIG_PM
  /*
 - * The following code is located into the .data section.  This is to
 - * allow phys_l2x0_saved_regs to be accessed with a relative load
 - * as we are running on physical address here.
 + * The following code must assume it is running from physical address
 + * where absolute virtual addresses to the data section have to be
 + * turned into relative ones.
   */
 - .data
 - .align
  
  #ifdef CONFIG_CACHE_L2X0
   .macro  pl310_resume
 - ldr r2, phys_l2x0_saved_regs
 + adr r0, l2x0_saved_regs_offset
 + ldr r2, [r0]
 + add r2, r2, r0
   ldr r0, [r2, #L2X0_R_PHY_BASE]  @ get physical base of l2x0
   ldr r1, [r2, #L2X0_R_AUX_CTRL]  @ get aux_ctrl value
   str r1, [r0, #L2X0_AUX_CTRL]@ restore aux_ctrl
 @@ -90,9 +90,9 @@ ENDPROC(v7_secondary_startup)
   str r1, [r0, #L2X0_CTRL]@ re-enable L2
   .endm
  
 - .globl  phys_l2x0_saved_regs
 -phys_l2x0_saved_regs:
 -.long   0
 +l2x0_saved_regs_offset:
 + .word   l2x0_saved_regs - .
 +
  #else
   .macro  pl310_resume
   .endm
 diff --git a/arch/arm/mach-imx/pm-imx6q.c b/arch/arm/mach-imx/pm-imx6q.c
 index f7b0c2b1b9..f3791f980d 100644
 --- a/arch/arm/mach-imx/pm-imx6q.c
 +++ b/arch/arm/mach-imx/pm-imx6q.c
 @@ -21,8 +21,6 @@
  #include mach/common.h
  #include mach/hardware.h
  
 -extern unsigned long phys_l2x0_saved_regs;
 -
  static int imx6q_suspend_finish(unsigned long val)
  {
   cpu_do_idle();
 @@ -55,18 +53,5 @@ static const struct platform_suspend_ops imx6q_pm_ops = {
  
  void __init imx6q_pm_init(void)
  {
 - /*
 -  * The l2x0 core code provides an infrastucture to save and restore
 -  * l2x0 registers across suspend/resume cycle.  But because imx6q
 -  * retains L2 content during suspend and needs to resume L2 before
 -  * MMU is enabled, it can only utilize register saving support and
 -  * have to take care of restoring on its own.  So we save physical
 -  * address of the data structure used by l2x0 core to save registers,
 -  * and later restore the necessary ones in imx6q resume entry.
 -  */
 -#ifdef CONFIG_CACHE_L2X0
 - phys_l2x0_saved_regs = __pa(l2x0_saved_regs);
 -#endif
 -
   suspend_set_ops(imx6q_pm_ops);
  }
 
 Nicolas

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error

2013-02-18 Thread Nicolas Pitre 
On Tue, 19 Feb 2013, Shawn Guo wrote:

 On Mon, Feb 18, 2013 at 12:06:32PM -0500, Nicolas Pitre wrote:
  Try the following instead.  It makes the code simpler and easier to 
  debug.
  
 It works now.  Thanks, Nico.  Care to send a patch for it?  I'd like
 to apply it.

- 8

FRom: Nicolas Pitre nicolas.pi...@linaro.org
Date: Mon, 18 Feb 2013 12:06:32 -0500 (EST)
Subject: ARM: mach-imx: move early resume code out of the .data section

Building the kernel with allyesconfig fails because the i.mx early
resume code located in the .data section is unable to fixup the bl
relocation as the branch target gets too far away.

The idea of having code in the .data section allows for easy access to 
nearby data using relative addressing while the MMU is off. However it 
is probably best to move the code back to the .text section where it 
belongs and fixup the data access instead.  This solves the bl reloc
issue (at least until this becomes a general problem) and simplifies
the code as well.

Signed-off-by: Nicolas Pitre n...@linaro.org
---

I'll probably convert other code in .data instances as well in the 
near future.

diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
index 7e49deb128..27bc06e910 100644
--- a/arch/arm/mach-imx/headsmp.S
+++ b/arch/arm/mach-imx/headsmp.S
@@ -73,16 +73,16 @@ ENDPROC(v7_secondary_startup)
 
 #ifdef CONFIG_PM
 /*
- * The following code is located into the .data section.  This is to
- * allow phys_l2x0_saved_regs to be accessed with a relative load
- * as we are running on physical address here.
+ * The following code must assume it is running from physical address
+ * where absolute virtual addresses to the data section have to be
+ * turned into relative ones.
  */
-   .data
-   .align
 
 #ifdef CONFIG_CACHE_L2X0
.macro  pl310_resume
-   ldr r2, phys_l2x0_saved_regs
+   adr r0, l2x0_saved_regs_offset
+   ldr r2, [r0]
+   add r2, r2, r0
ldr r0, [r2, #L2X0_R_PHY_BASE]  @ get physical base of l2x0
ldr r1, [r2, #L2X0_R_AUX_CTRL]  @ get aux_ctrl value
str r1, [r0, #L2X0_AUX_CTRL]@ restore aux_ctrl
@@ -90,9 +90,9 @@ ENDPROC(v7_secondary_startup)
str r1, [r0, #L2X0_CTRL]@ re-enable L2
.endm
 
-   .globl  phys_l2x0_saved_regs
-phys_l2x0_saved_regs:
-.long   0
+l2x0_saved_regs_offset:
+   .word   l2x0_saved_regs - .
+
 #else
.macro  pl310_resume
.endm
diff --git a/arch/arm/mach-imx/pm-imx6q.c b/arch/arm/mach-imx/pm-imx6q.c
index f7b0c2b1b9..f3791f980d 100644
--- a/arch/arm/mach-imx/pm-imx6q.c
+++ b/arch/arm/mach-imx/pm-imx6q.c
@@ -21,8 +21,6 @@
 #include mach/common.h
 #include mach/hardware.h
 
-extern unsigned long phys_l2x0_saved_regs;
-
 static int imx6q_suspend_finish(unsigned long val)
 {
cpu_do_idle();
@@ -55,18 +53,5 @@ static const struct platform_suspend_ops imx6q_pm_ops = {
 
 void __init imx6q_pm_init(void)
 {
-   /*
-* The l2x0 core code provides an infrastucture to save and restore
-* l2x0 registers across suspend/resume cycle.  But because imx6q
-* retains L2 content during suspend and needs to resume L2 before
-* MMU is enabled, it can only utilize register saving support and
-* have to take care of restoring on its own.  So we save physical
-* address of the data structure used by l2x0 core to save registers,
-* and later restore the necessary ones in imx6q resume entry.
-*/
-#ifdef CONFIG_CACHE_L2X0
-   phys_l2x0_saved_regs = __pa(l2x0_saved_regs);
-#endif
-
suspend_set_ops(imx6q_pm_ops);
 }
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error

2013-02-18 Thread Shawn Guo 
On Mon, Feb 18, 2013 at 11:11:30PM -0500, Nicolas Pitre wrote:
 On Tue, 19 Feb 2013, Shawn Guo wrote:
 
  On Mon, Feb 18, 2013 at 12:06:32PM -0500, Nicolas Pitre wrote:
   Try the following instead.  It makes the code simpler and easier to 
   debug.
   
  It works now.  Thanks, Nico.  Care to send a patch for it?  I'd like
  to apply it.
 
 - 8
 
 FRom: Nicolas Pitre nicolas.pi...@linaro.org
 Date: Mon, 18 Feb 2013 12:06:32 -0500 (EST)
 Subject: ARM: mach-imx: move early resume code out of the .data section
 
 Building the kernel with allyesconfig fails because the i.mx early
 resume code located in the .data section is unable to fixup the bl
 relocation as the branch target gets too far away.
 
 The idea of having code in the .data section allows for easy access to 
 nearby data using relative addressing while the MMU is off. However it 
 is probably best to move the code back to the .text section where it 
 belongs and fixup the data access instead.  This solves the bl reloc
 issue (at least until this becomes a general problem) and simplifies
 the code as well.
 
 Signed-off-by: Nicolas Pitre n...@linaro.org

Applied as a fix for 3.9-rc, thanks.

Shawn

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error

2013-02-17 Thread Shawn Guo 
On Sat, Feb 16, 2013 at 12:14:49AM -0500, Nicolas Pitre wrote:
> On Fri, 15 Feb 2013, Russell King - ARM Linux wrote:
> 
> > On Thu, Feb 14, 2013 at 11:47:50PM +0100, Arnd Bergmann wrote:
> > > Patch c08e20d24 "arm: Add v7_invalidate_l1 to cache-v7.S"
> > > moves the v7_invalidate_l1 symbol out of imx/headsmp.S,
> > > which seems to cause a link error because it is now
> > > too far away from v7_cpu_resume when building an
> > > allyesconfig kernel.
> > > 
> > > If we move the v7_cpu_resume function from the .data
> > > section to .text, that creates another link error
> > > for the reference to phys_l2x0_saved_regs, but we
> > > can move all of the above to .text.
> > > 
> > > I believe that this is not a correct bug fix but just
> > > a bad workaround, so I'm open to ideas from people
> > > who understand the bigger picture.
> > 
> > Unfortunately, this ends up with writable data in the .text section, which
> > is supposed to be read-only.  We should try to preserve that status, even
> > though we don't enforce it.
> > 
> > I guess the problem is that we end up with the .data segment soo far away
> > from the .text segment that these branches no longer work (and remember
> > that this code executes with the MMU off.)
> > 
> > The only solution I can think is that we need to do quite a bit of magic
> > here to jump to an absolute address, but taking account of the V:P offset.
> > That's not going to be particularly nice, and it's going to then also have
> > to jump back the other way - to the cpu_resume code which is also in the
> > .data section.
> 
> Something like this should work:
> 
> diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
> index 7e49deb128..9de26f3edb 100644
> --- a/arch/arm/mach-imx/headsmp.S
> +++ b/arch/arm/mach-imx/headsmp.S
> @@ -99,8 +99,11 @@ phys_l2x0_saved_regs:
>  #endif
>  
>  ENTRY(v7_cpu_resume)
> - bl  v7_invalidate_l1
> + ldr ip, 2f
> + mov lr, pc
> +1:   add pc, pc, ip
>   pl310_resume
>   b   cpu_resume
> +2:   .word v7_invalidate_l1 - 1b - 8
>  ENDPROC(v7_cpu_resume)
>  #endif
> 
Yes, it works.

> 
> However it is probably best to move all the code to the .text section 
> where it belongs and fixup the data access instead.  I must plead guilty 
> for introducing this idea of putting code in the .data section with the 
> SA1100resume code over 10 years ago that everyone copied since.
> 
> So here's how I think it should look instead, and how I should have done 
> the SA1100 code back then:
> 
> diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
> index 7e49deb128..38a544a037 100644
> --- a/arch/arm/mach-imx/headsmp.S
> +++ b/arch/arm/mach-imx/headsmp.S
> @@ -73,16 +73,16 @@ ENDPROC(v7_secondary_startup)
>  
>  #ifdef CONFIG_PM
>  /*
> - * The following code is located into the .data section.  This is to
> - * allow phys_l2x0_saved_regs to be accessed with a relative load
> - * as we are running on physical address here.
> + * The following code must assume it is running from physical address
> + * where absolute virtual addresses to the data section have to be
> + * turned into relative ones.
>   */
> - .data
> - .align
>  
>  #ifdef CONFIG_CACHE_L2X0
>   .macro  pl310_resume
> - ldr r2, phys_l2x0_saved_regs
> + adr r0, phys_l2x0_saved_ptr_offset
> + ldr r2, [r0]
> + add r2, r2, r0
>   ldr r0, [r2, #L2X0_R_PHY_BASE]  @ get physical base of l2x0
>   ldr r1, [r2, #L2X0_R_AUX_CTRL]  @ get aux_ctrl value
>   str r1, [r0, #L2X0_AUX_CTRL]@ restore aux_ctrl
> @@ -90,9 +90,13 @@ ENDPROC(v7_secondary_startup)
>   str r1, [r0, #L2X0_CTRL]@ re-enable L2
>   .endm
>  
> + .bss
>   .globl  phys_l2x0_saved_regs
>  phys_l2x0_saved_regs:
> -.long   0
> +.space   4
> + .previous
> +phys_l2x0_saved_ptr_offset:
> + .word   phys_l2x0_saved_regs - .
>  #else
>   .macro  pl310_resume
>   .endm
> 
But this does not work.  It seems the execution jumps to the start of
kernel on system resuming.

Shawn

root@freescale ~$ ./rtcwakeup.sh
rtcwakeup.out: wakeup from "mem" using rtc0 at Fri Jan  2 00:09:43 1970
PM: Syncing filesystems ... done.
PM: Preparing system for mem sleep
mmc0: card a8a5 removed
mmc1: card b368 removed
Freezing user space processes ... (elapsed 0.01 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
PM: Entering mem sleep
fec_stop : Graceful transmit stop did not complete !
PM: suspend of devices complete after 8.361 msecs
PM: suspend devices took 0.010 seconds
PM: late suspend of devices complete after 0.267 msecs
PM: noirq suspend of devices complete after 0.754 msecs
Disabling non-boot CPUs ...
CPU1: shutdown
CPU2: shutdown
CPU3: shutdown
Booting Linux on physical CPU 0x0
Linux version 3.8.0-rc7-next-20130215+ (r65073@S2101-09) (gcc version
4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #341 SMP Mon Feb 18 13:36:48 CST
2013

Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error

2013-02-17 Thread Shawn Guo 
On Sat, Feb 16, 2013 at 12:14:49AM -0500, Nicolas Pitre wrote:
 On Fri, 15 Feb 2013, Russell King - ARM Linux wrote:
 
  On Thu, Feb 14, 2013 at 11:47:50PM +0100, Arnd Bergmann wrote:
   Patch c08e20d24 arm: Add v7_invalidate_l1 to cache-v7.S
   moves the v7_invalidate_l1 symbol out of imx/headsmp.S,
   which seems to cause a link error because it is now
   too far away from v7_cpu_resume when building an
   allyesconfig kernel.
   
   If we move the v7_cpu_resume function from the .data
   section to .text, that creates another link error
   for the reference to phys_l2x0_saved_regs, but we
   can move all of the above to .text.
   
   I believe that this is not a correct bug fix but just
   a bad workaround, so I'm open to ideas from people
   who understand the bigger picture.
  
  Unfortunately, this ends up with writable data in the .text section, which
  is supposed to be read-only.  We should try to preserve that status, even
  though we don't enforce it.
  
  I guess the problem is that we end up with the .data segment soo far away
  from the .text segment that these branches no longer work (and remember
  that this code executes with the MMU off.)
  
  The only solution I can think is that we need to do quite a bit of magic
  here to jump to an absolute address, but taking account of the V:P offset.
  That's not going to be particularly nice, and it's going to then also have
  to jump back the other way - to the cpu_resume code which is also in the
  .data section.
 
 Something like this should work:
 
 diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
 index 7e49deb128..9de26f3edb 100644
 --- a/arch/arm/mach-imx/headsmp.S
 +++ b/arch/arm/mach-imx/headsmp.S
 @@ -99,8 +99,11 @@ phys_l2x0_saved_regs:
  #endif
  
  ENTRY(v7_cpu_resume)
 - bl  v7_invalidate_l1
 + ldr ip, 2f
 + mov lr, pc
 +1:   add pc, pc, ip
   pl310_resume
   b   cpu_resume
 +2:   .word v7_invalidate_l1 - 1b - 8
  ENDPROC(v7_cpu_resume)
  #endif
 
Yes, it works.

 
 However it is probably best to move all the code to the .text section 
 where it belongs and fixup the data access instead.  I must plead guilty 
 for introducing this idea of putting code in the .data section with the 
 SA1100resume code over 10 years ago that everyone copied since.
 
 So here's how I think it should look instead, and how I should have done 
 the SA1100 code back then:
 
 diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
 index 7e49deb128..38a544a037 100644
 --- a/arch/arm/mach-imx/headsmp.S
 +++ b/arch/arm/mach-imx/headsmp.S
 @@ -73,16 +73,16 @@ ENDPROC(v7_secondary_startup)
  
  #ifdef CONFIG_PM
  /*
 - * The following code is located into the .data section.  This is to
 - * allow phys_l2x0_saved_regs to be accessed with a relative load
 - * as we are running on physical address here.
 + * The following code must assume it is running from physical address
 + * where absolute virtual addresses to the data section have to be
 + * turned into relative ones.
   */
 - .data
 - .align
  
  #ifdef CONFIG_CACHE_L2X0
   .macro  pl310_resume
 - ldr r2, phys_l2x0_saved_regs
 + adr r0, phys_l2x0_saved_ptr_offset
 + ldr r2, [r0]
 + add r2, r2, r0
   ldr r0, [r2, #L2X0_R_PHY_BASE]  @ get physical base of l2x0
   ldr r1, [r2, #L2X0_R_AUX_CTRL]  @ get aux_ctrl value
   str r1, [r0, #L2X0_AUX_CTRL]@ restore aux_ctrl
 @@ -90,9 +90,13 @@ ENDPROC(v7_secondary_startup)
   str r1, [r0, #L2X0_CTRL]@ re-enable L2
   .endm
  
 + .bss
   .globl  phys_l2x0_saved_regs
  phys_l2x0_saved_regs:
 -.long   0
 +.space   4
 + .previous
 +phys_l2x0_saved_ptr_offset:
 + .word   phys_l2x0_saved_regs - .
  #else
   .macro  pl310_resume
   .endm
 
But this does not work.  It seems the execution jumps to the start of
kernel on system resuming.

Shawn

root@freescale ~$ ./rtcwakeup.sh
rtcwakeup.out: wakeup from mem using rtc0 at Fri Jan  2 00:09:43 1970
PM: Syncing filesystems ... done.
PM: Preparing system for mem sleep
mmc0: card a8a5 removed
mmc1: card b368 removed
Freezing user space processes ... (elapsed 0.01 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
PM: Entering mem sleep
fec_stop : Graceful transmit stop did not complete !
PM: suspend of devices complete after 8.361 msecs
PM: suspend devices took 0.010 seconds
PM: late suspend of devices complete after 0.267 msecs
PM: noirq suspend of devices complete after 0.754 msecs
Disabling non-boot CPUs ...
CPU1: shutdown
CPU2: shutdown
CPU3: shutdown
Booting Linux on physical CPU 0x0
Linux version 3.8.0-rc7-next-20130215+ (r65073@S2101-09) (gcc version
4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #341 SMP Mon Feb 18 13:36:48 CST
2013
CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine:

Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error

2013-02-15 Thread Nicolas Pitre 
On Fri, 15 Feb 2013, Russell King - ARM Linux wrote:

> On Thu, Feb 14, 2013 at 11:47:50PM +0100, Arnd Bergmann wrote:
> > Patch c08e20d24 "arm: Add v7_invalidate_l1 to cache-v7.S"
> > moves the v7_invalidate_l1 symbol out of imx/headsmp.S,
> > which seems to cause a link error because it is now
> > too far away from v7_cpu_resume when building an
> > allyesconfig kernel.
> > 
> > If we move the v7_cpu_resume function from the .data
> > section to .text, that creates another link error
> > for the reference to phys_l2x0_saved_regs, but we
> > can move all of the above to .text.
> > 
> > I believe that this is not a correct bug fix but just
> > a bad workaround, so I'm open to ideas from people
> > who understand the bigger picture.
> 
> Unfortunately, this ends up with writable data in the .text section, which
> is supposed to be read-only.  We should try to preserve that status, even
> though we don't enforce it.
> 
> I guess the problem is that we end up with the .data segment soo far away
> from the .text segment that these branches no longer work (and remember
> that this code executes with the MMU off.)
> 
> The only solution I can think is that we need to do quite a bit of magic
> here to jump to an absolute address, but taking account of the V:P offset.
> That's not going to be particularly nice, and it's going to then also have
> to jump back the other way - to the cpu_resume code which is also in the
> .data section.

Something like this should work:

diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
index 7e49deb128..9de26f3edb 100644
--- a/arch/arm/mach-imx/headsmp.S
+++ b/arch/arm/mach-imx/headsmp.S
@@ -99,8 +99,11 @@ phys_l2x0_saved_regs:
 #endif
 
 ENTRY(v7_cpu_resume)
-   bl  v7_invalidate_l1
+   ldr ip, 2f
+   mov lr, pc
+1: add pc, pc, ip
pl310_resume
b   cpu_resume
+2: .word v7_invalidate_l1 - 1b - 8
 ENDPROC(v7_cpu_resume)
 #endif


However it is probably best to move all the code to the .text section 
where it belongs and fixup the data access instead.  I must plead guilty 
for introducing this idea of putting code in the .data section with the 
SA1100resume code over 10 years ago that everyone copied since.

So here's how I think it should look instead, and how I should have done 
the SA1100 code back then:

diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
index 7e49deb128..38a544a037 100644
--- a/arch/arm/mach-imx/headsmp.S
+++ b/arch/arm/mach-imx/headsmp.S
@@ -73,16 +73,16 @@ ENDPROC(v7_secondary_startup)
 
 #ifdef CONFIG_PM
 /*
- * The following code is located into the .data section.  This is to
- * allow phys_l2x0_saved_regs to be accessed with a relative load
- * as we are running on physical address here.
+ * The following code must assume it is running from physical address
+ * where absolute virtual addresses to the data section have to be
+ * turned into relative ones.
  */
-   .data
-   .align
 
 #ifdef CONFIG_CACHE_L2X0
.macro  pl310_resume
-   ldr r2, phys_l2x0_saved_regs
+   adr r0, phys_l2x0_saved_ptr_offset
+   ldr r2, [r0]
+   add r2, r2, r0
ldr r0, [r2, #L2X0_R_PHY_BASE]  @ get physical base of l2x0
ldr r1, [r2, #L2X0_R_AUX_CTRL]  @ get aux_ctrl value
str r1, [r0, #L2X0_AUX_CTRL]@ restore aux_ctrl
@@ -90,9 +90,13 @@ ENDPROC(v7_secondary_startup)
str r1, [r0, #L2X0_CTRL]@ re-enable L2
.endm
 
+   .bss
.globl  phys_l2x0_saved_regs
 phys_l2x0_saved_regs:
-.long   0
+.space   4
+   .previous
+phys_l2x0_saved_ptr_offset:
+   .word   phys_l2x0_saved_regs - .
 #else
.macro  pl310_resume
.endm

And yet we could dispense with phys_l2x0_saved_regs 
altogether and use l2x0_saved_regs directly here instead.

That doesn't solve the issue of the kernel becoming too large for branch 
displacement fixup though.


Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error

2013-02-15 Thread Arnd Bergmann 
On Friday 15 February 2013, Russell King - ARM Linux wrote:
> > The .text section alone is just short of 32MB.
> 
> I suspect when it does go over that, we'll see a lot more link time
> failures due to the 'bl' instructions failing to encode their PC relative
> jumps.  The only solution then will be to switch everything to use the
> less efficient long jumps (load address from literal pool, bx) which'll
> also need much of the asm changed.  That also brings up the question
> whether we want to penalize the kernel performance just to make
> allyesconfig work... I guess we can make it a compile time option, which
> of course allyesconfig will automatically enable.  I suspect we'll see
> a lot of people mistakenly enabling it too though.

I'm not too worried about people accidentally enabling such a build option,
at least if it's appropriately labeled as something that nobody should
need.

Changing the inline assembly however sounds like a big pain to do, which
would cause performance and size overhead as well as regressions in
rarely executed code when we get it wrong. I've tried rebulding
the allyesconfig kernel with -O3 -funroll-all-loops to make it even
bigger on purpose, and got these errors:

arch/arm/kernel/built-in.o:(.fixup+0x8): relocation truncated to fit: 
R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x10): relocation truncated to fit: 
R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x18): relocation truncated to fit: 
R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x20): relocation truncated to fit: 
R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x28): relocation truncated to fit: 
R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x30): relocation truncated to fit: 
R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x38): relocation truncated to fit: 
R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x40): relocation truncated to fit: 
R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x48): relocation truncated to fit: 
R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x50): relocation truncated to fit: 
R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x58): additional relocation overflows 
omitted from the output

so the .fixup section is completely out of reach of the start of the .text 
section.

The size output for the partial link of vmlinux.o is

section size addr
.head.text   492   3221258240
.text   43889568   3221258752
.text.head 80
.rodata 11020608 4096
__bug_table   138636 11024704
.pci_fixup 0 11163340
.builtin_fw  684 11163340
.rio_ops   0 11164024
__ksymtab  53424 11164024
__ksymtab_gpl  43560 11217448
__ksymtab_unused   0 11261008
__ksymtab_unused_gpl   0 11261008
__ksymtab_gpl_future   0 11261008
__kcrctab  26712 11261008
__kcrctab_gpl  21780 11287720
__kcrctab_unused   0 11309500
__kcrctab_unused_gpl   0 11309500
__kcrctab_gpl_future   0 11309500
__ksymtab_strings 251888 11309500
__param33104 11561388
__modver1284 11594492
__ex_table  6288 11595776
.ARM.unwind_idx   907888 11602064
.ARM.unwind_tab  1362276 12509952
.notes36 13872228
.init.text685436 13873152
.exit.text124324 14558588
.init.arch.info 5396 14682912
.init.tagtable72 14688308
.init.smpalt 952 14688380
.init.pv_table  2232 14689332
.init.data649164 14691568
.exit.data   120 15340732
.data..percpu1460032 15343616
.data3370676 16809984
.tcm_start   332 20180660
.text_itcm 0   4294836224
.dtcm_start0 20180992
.data_dtcm 0   4294868992
.tcm_end   0 20180992
.bss 8007852 20180992
.comment  3144240
.ARM.attributes   500
.debug_line 191855650
.debug_info 617576490
.debug_abbrev58354570
.debug_aranges2994160
.debug_ranges   104820640
.debug_frame 46017680
.debug_str  374337320
.debug_loc  455782060
Total  257553155

I had the idea that turning off THUMB2 support in allyesconfig would help,
but then I found that it's

Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error

2013-02-15 Thread Russell King - ARM Linux 
On Fri, Feb 15, 2013 at 11:05:14AM +, Arnd Bergmann wrote:
> $ size  obj-tmp/vmlinux -A
> obj-tmp/vmlinux  :
> section  size addr
> .head.text504   3221258240
> .text32707336   3221258752
> .text.head  8   3253966088

Interesting... I wonder if that should be .head.text, or maybe just .text.
Looking at iMX, it's just the secondary startup, which is calling into
.head.text, so it would be much safer given the size of the .text segment
for it to be in .head.text.

> The .text section alone is just short of 32MB.

I suspect when it does go over that, we'll see a lot more link time
failures due to the 'bl' instructions failing to encode their PC relative
jumps.  The only solution then will be to switch everything to use the
less efficient long jumps (load address from literal pool, bx) which'll
also need much of the asm changed.  That also brings up the question
whether we want to penalize the kernel performance just to make
allyesconfig work... I guess we can make it a compile time option, which
of course allyesconfig will automatically enable.  I suspect we'll see
a lot of people mistakenly enabling it too though.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error

2013-02-15 Thread Russell King - ARM Linux 
On Thu, Feb 14, 2013 at 11:47:50PM +0100, Arnd Bergmann wrote:
> Patch c08e20d24 "arm: Add v7_invalidate_l1 to cache-v7.S"
> moves the v7_invalidate_l1 symbol out of imx/headsmp.S,
> which seems to cause a link error because it is now
> too far away from v7_cpu_resume when building an
> allyesconfig kernel.
> 
> If we move the v7_cpu_resume function from the .data
> section to .text, that creates another link error
> for the reference to phys_l2x0_saved_regs, but we
> can move all of the above to .text.
> 
> I believe that this is not a correct bug fix but just
> a bad workaround, so I'm open to ideas from people
> who understand the bigger picture.

Unfortunately, this ends up with writable data in the .text section, which
is supposed to be read-only.  We should try to preserve that status, even
though we don't enforce it.

I guess the problem is that we end up with the .data segment soo far away
from the .text segment that these branches no longer work (and remember
that this code executes with the MMU off.)

The only solution I can think is that we need to do quite a bit of magic
here to jump to an absolute address, but taking account of the V:P offset.
That's not going to be particularly nice, and it's going to then also have
to jump back the other way - to the cpu_resume code which is also in the
.data section.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error

2013-02-15 Thread Arnd Bergmann 
On Thursday 14 February 2013, Stephen Warren wrote:
> On 02/14/2013 03:47 PM, Arnd Bergmann wrote:
> > Patch c08e20d24 "arm: Add v7_invalidate_l1 to cache-v7.S"
> > moves the v7_invalidate_l1 symbol out of imx/headsmp.S,
> > which seems to cause a link error because it is now
> > too far away from v7_cpu_resume when building an
> > allyesconfig kernel.
> 
> Is the problem from the following in arch/arm/mach-imx/headsmp.S:
> 
> ENTRY(v7_cpu_resume)
> bl  v7_invalidate_l1
> 
> Isn't the range of bl +/- 32MiB (or +/- 16MibB in Thumb 2). Is the
> kernel really that big? Sorry, I'm having trouble understanding what
> causes the problem.


Well, it is an "allyesconfig" kernel, so things can get pretty big:

$ size  obj-tmp/vmlinux -A
obj-tmp/vmlinux  :
section  size addr
.head.text504   3221258240
.text32707336   3221258752
.text.head  8   3253966088
.rodata  14028722   3253968896
__bug_table127764   3267997624
.builtin_fw   684   3268125388
__ksymtab   53424   3268126072
__ksymtab_gpl   43560   3268179496
__kcrctab   26712   3268223056
__kcrctab_gpl   21780   3268249768
__ksymtab_strings  233706   3268271548
__param 33104   3268505256
__modver 4104   3268538360
__ex_table   4112   3268542464
.ARM.unwind_idx967784   3268546576
.ARM.unwind_tab   1452168   3269514360
.notes 36   3270966528
.init.text 677840   3270967296
.exit.text 125672   3271645136
.init.arch.info  5396   3271770808
.init.tagtable 72   3271776204
.init.smpalt  928   3271776276
.init.pv_table   1704   3271777204
.init.data 678108   3271778912
.exit.data119   3272457020
.data..percpu 1460032   3272458240
.data 3370068   3273924608
.tcm_start940   3277294676
.bss  8007724   3277295616
.comment   430
.ARM.attributes500
.debug_line  157803630
.debug_info  571921430
.debug_abbrev 57473740
.debug_aranges 2996080
.debug_ranges 54145920
.debug_frame  48017480
.debug_str70032820
.debug_loc   362374760
Total   196510790

THUMB2 support is obviously enabled (allyesconfig), and from the start of the
.head.text section to the end of .bss, it is 64,045,100 bytes, using yesterday's
linux-next kernel with my fixes. It will get bigger as we add more stuff
to multiplatform. The .text section alone is just short of 32MB.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error

2013-02-15 Thread Arnd Bergmann 
On Thursday 14 February 2013, Stephen Warren wrote:
 On 02/14/2013 03:47 PM, Arnd Bergmann wrote:
  Patch c08e20d24 arm: Add v7_invalidate_l1 to cache-v7.S
  moves the v7_invalidate_l1 symbol out of imx/headsmp.S,
  which seems to cause a link error because it is now
  too far away from v7_cpu_resume when building an
  allyesconfig kernel.
 
 Is the problem from the following in arch/arm/mach-imx/headsmp.S:
 
 ENTRY(v7_cpu_resume)
 bl  v7_invalidate_l1
 
 Isn't the range of bl +/- 32MiB (or +/- 16MibB in Thumb 2). Is the
 kernel really that big? Sorry, I'm having trouble understanding what
 causes the problem.


Well, it is an allyesconfig kernel, so things can get pretty big:

$ size  obj-tmp/vmlinux -A
obj-tmp/vmlinux  :
section  size addr
.head.text504   3221258240
.text32707336   3221258752
.text.head  8   3253966088
.rodata  14028722   3253968896
__bug_table127764   3267997624
.builtin_fw   684   3268125388
__ksymtab   53424   3268126072
__ksymtab_gpl   43560   3268179496
__kcrctab   26712   3268223056
__kcrctab_gpl   21780   3268249768
__ksymtab_strings  233706   3268271548
__param 33104   3268505256
__modver 4104   3268538360
__ex_table   4112   3268542464
.ARM.unwind_idx967784   3268546576
.ARM.unwind_tab   1452168   3269514360
.notes 36   3270966528
.init.text 677840   3270967296
.exit.text 125672   3271645136
.init.arch.info  5396   3271770808
.init.tagtable 72   3271776204
.init.smpalt  928   3271776276
.init.pv_table   1704   3271777204
.init.data 678108   3271778912
.exit.data119   3272457020
.data..percpu 1460032   3272458240
.data 3370068   3273924608
.tcm_start940   3277294676
.bss  8007724   3277295616
.comment   430
.ARM.attributes500
.debug_line  157803630
.debug_info  571921430
.debug_abbrev 57473740
.debug_aranges 2996080
.debug_ranges 54145920
.debug_frame  48017480
.debug_str70032820
.debug_loc   362374760
Total   196510790

THUMB2 support is obviously enabled (allyesconfig), and from the start of the
.head.text section to the end of .bss, it is 64,045,100 bytes, using yesterday's
linux-next kernel with my fixes. It will get bigger as we add more stuff
to multiplatform. The .text section alone is just short of 32MB.

Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error

2013-02-15 Thread Russell King - ARM Linux 
On Thu, Feb 14, 2013 at 11:47:50PM +0100, Arnd Bergmann wrote:
 Patch c08e20d24 arm: Add v7_invalidate_l1 to cache-v7.S
 moves the v7_invalidate_l1 symbol out of imx/headsmp.S,
 which seems to cause a link error because it is now
 too far away from v7_cpu_resume when building an
 allyesconfig kernel.
 
 If we move the v7_cpu_resume function from the .data
 section to .text, that creates another link error
 for the reference to phys_l2x0_saved_regs, but we
 can move all of the above to .text.
 
 I believe that this is not a correct bug fix but just
 a bad workaround, so I'm open to ideas from people
 who understand the bigger picture.

Unfortunately, this ends up with writable data in the .text section, which
is supposed to be read-only.  We should try to preserve that status, even
though we don't enforce it.

I guess the problem is that we end up with the .data segment soo far away
from the .text segment that these branches no longer work (and remember
that this code executes with the MMU off.)

The only solution I can think is that we need to do quite a bit of magic
here to jump to an absolute address, but taking account of the V:P offset.
That's not going to be particularly nice, and it's going to then also have
to jump back the other way - to the cpu_resume code which is also in the
.data section.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error

2013-02-15 Thread Russell King - ARM Linux 
On Fri, Feb 15, 2013 at 11:05:14AM +, Arnd Bergmann wrote:
 $ size  obj-tmp/vmlinux -A
 obj-tmp/vmlinux  :
 section  size addr
 .head.text504   3221258240
 .text32707336   3221258752
 .text.head  8   3253966088

Interesting... I wonder if that should be .head.text, or maybe just .text.
Looking at iMX, it's just the secondary startup, which is calling into
.head.text, so it would be much safer given the size of the .text segment
for it to be in .head.text.

 The .text section alone is just short of 32MB.

I suspect when it does go over that, we'll see a lot more link time
failures due to the 'bl' instructions failing to encode their PC relative
jumps.  The only solution then will be to switch everything to use the
less efficient long jumps (load address from literal pool, bx) which'll
also need much of the asm changed.  That also brings up the question
whether we want to penalize the kernel performance just to make
allyesconfig work... I guess we can make it a compile time option, which
of course allyesconfig will automatically enable.  I suspect we'll see
a lot of people mistakenly enabling it too though.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error

2013-02-15 Thread Arnd Bergmann 
On Friday 15 February 2013, Russell King - ARM Linux wrote:
  The .text section alone is just short of 32MB.
 
 I suspect when it does go over that, we'll see a lot more link time
 failures due to the 'bl' instructions failing to encode their PC relative
 jumps.  The only solution then will be to switch everything to use the
 less efficient long jumps (load address from literal pool, bx) which'll
 also need much of the asm changed.  That also brings up the question
 whether we want to penalize the kernel performance just to make
 allyesconfig work... I guess we can make it a compile time option, which
 of course allyesconfig will automatically enable.  I suspect we'll see
 a lot of people mistakenly enabling it too though.

I'm not too worried about people accidentally enabling such a build option,
at least if it's appropriately labeled as something that nobody should
need.

Changing the inline assembly however sounds like a big pain to do, which
would cause performance and size overhead as well as regressions in
rarely executed code when we get it wrong. I've tried rebulding
the allyesconfig kernel with -O3 -funroll-all-loops to make it even
bigger on purpose, and got these errors:

arch/arm/kernel/built-in.o:(.fixup+0x8): relocation truncated to fit: 
R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x10): relocation truncated to fit: 
R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x18): relocation truncated to fit: 
R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x20): relocation truncated to fit: 
R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x28): relocation truncated to fit: 
R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x30): relocation truncated to fit: 
R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x38): relocation truncated to fit: 
R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x40): relocation truncated to fit: 
R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x48): relocation truncated to fit: 
R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x50): relocation truncated to fit: 
R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o:(.fixup+0x58): additional relocation overflows 
omitted from the output

so the .fixup section is completely out of reach of the start of the .text 
section.

The size output for the partial link of vmlinux.o is

section size addr
.head.text   492   3221258240
.text   43889568   3221258752
.text.head 80
.rodata 11020608 4096
__bug_table   138636 11024704
.pci_fixup 0 11163340
.builtin_fw  684 11163340
.rio_ops   0 11164024
__ksymtab  53424 11164024
__ksymtab_gpl  43560 11217448
__ksymtab_unused   0 11261008
__ksymtab_unused_gpl   0 11261008
__ksymtab_gpl_future   0 11261008
__kcrctab  26712 11261008
__kcrctab_gpl  21780 11287720
__kcrctab_unused   0 11309500
__kcrctab_unused_gpl   0 11309500
__kcrctab_gpl_future   0 11309500
__ksymtab_strings 251888 11309500
__param33104 11561388
__modver1284 11594492
__ex_table  6288 11595776
.ARM.unwind_idx   907888 11602064
.ARM.unwind_tab  1362276 12509952
.notes36 13872228
.init.text685436 13873152
.exit.text124324 14558588
.init.arch.info 5396 14682912
.init.tagtable72 14688308
.init.smpalt 952 14688380
.init.pv_table  2232 14689332
.init.data649164 14691568
.exit.data   120 15340732
.data..percpu1460032 15343616
.data3370676 16809984
.tcm_start   332 20180660
.text_itcm 0   4294836224
.dtcm_start0 20180992
.data_dtcm 0   4294868992
.tcm_end   0 20180992
.bss 8007852 20180992
.comment  3144240
.ARM.attributes   500
.debug_line 191855650
.debug_info 617576490
.debug_abbrev58354570
.debug_aranges2994160
.debug_ranges   104820640
.debug_frame 46017680
.debug_str  374337320
.debug_loc  455782060
Total  257553155

I had the idea that turning off THUMB2 support in allyesconfig would help,
but then I found that it's already disabled

Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error

2013-02-15 Thread Nicolas Pitre 
On Fri, 15 Feb 2013, Russell King - ARM Linux wrote:

 On Thu, Feb 14, 2013 at 11:47:50PM +0100, Arnd Bergmann wrote:
  Patch c08e20d24 arm: Add v7_invalidate_l1 to cache-v7.S
  moves the v7_invalidate_l1 symbol out of imx/headsmp.S,
  which seems to cause a link error because it is now
  too far away from v7_cpu_resume when building an
  allyesconfig kernel.
  
  If we move the v7_cpu_resume function from the .data
  section to .text, that creates another link error
  for the reference to phys_l2x0_saved_regs, but we
  can move all of the above to .text.
  
  I believe that this is not a correct bug fix but just
  a bad workaround, so I'm open to ideas from people
  who understand the bigger picture.
 
 Unfortunately, this ends up with writable data in the .text section, which
 is supposed to be read-only.  We should try to preserve that status, even
 though we don't enforce it.
 
 I guess the problem is that we end up with the .data segment soo far away
 from the .text segment that these branches no longer work (and remember
 that this code executes with the MMU off.)
 
 The only solution I can think is that we need to do quite a bit of magic
 here to jump to an absolute address, but taking account of the V:P offset.
 That's not going to be particularly nice, and it's going to then also have
 to jump back the other way - to the cpu_resume code which is also in the
 .data section.

Something like this should work:

diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
index 7e49deb128..9de26f3edb 100644
--- a/arch/arm/mach-imx/headsmp.S
+++ b/arch/arm/mach-imx/headsmp.S
@@ -99,8 +99,11 @@ phys_l2x0_saved_regs:
 #endif
 
 ENTRY(v7_cpu_resume)
-   bl  v7_invalidate_l1
+   ldr ip, 2f
+   mov lr, pc
+1: add pc, pc, ip
pl310_resume
b   cpu_resume
+2: .word v7_invalidate_l1 - 1b - 8
 ENDPROC(v7_cpu_resume)
 #endif


However it is probably best to move all the code to the .text section 
where it belongs and fixup the data access instead.  I must plead guilty 
for introducing this idea of putting code in the .data section with the 
SA1100resume code over 10 years ago that everyone copied since.

So here's how I think it should look instead, and how I should have done 
the SA1100 code back then:

diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
index 7e49deb128..38a544a037 100644
--- a/arch/arm/mach-imx/headsmp.S
+++ b/arch/arm/mach-imx/headsmp.S
@@ -73,16 +73,16 @@ ENDPROC(v7_secondary_startup)
 
 #ifdef CONFIG_PM
 /*
- * The following code is located into the .data section.  This is to
- * allow phys_l2x0_saved_regs to be accessed with a relative load
- * as we are running on physical address here.
+ * The following code must assume it is running from physical address
+ * where absolute virtual addresses to the data section have to be
+ * turned into relative ones.
  */
-   .data
-   .align
 
 #ifdef CONFIG_CACHE_L2X0
.macro  pl310_resume
-   ldr r2, phys_l2x0_saved_regs
+   adr r0, phys_l2x0_saved_ptr_offset
+   ldr r2, [r0]
+   add r2, r2, r0
ldr r0, [r2, #L2X0_R_PHY_BASE]  @ get physical base of l2x0
ldr r1, [r2, #L2X0_R_AUX_CTRL]  @ get aux_ctrl value
str r1, [r0, #L2X0_AUX_CTRL]@ restore aux_ctrl
@@ -90,9 +90,13 @@ ENDPROC(v7_secondary_startup)
str r1, [r0, #L2X0_CTRL]@ re-enable L2
.endm
 
+   .bss
.globl  phys_l2x0_saved_regs
 phys_l2x0_saved_regs:
-.long   0
+.space   4
+   .previous
+phys_l2x0_saved_ptr_offset:
+   .word   phys_l2x0_saved_regs - .
 #else
.macro  pl310_resume
.endm

And yet we could dispense with phys_l2x0_saved_regs 
altogether and use l2x0_saved_regs directly here instead.

That doesn't solve the issue of the kernel becoming too large for branch 
displacement fixup though.


Nicolas
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error

2013-02-14 Thread Stephen Warren 
On 02/14/2013 03:47 PM, Arnd Bergmann wrote:
> Patch c08e20d24 "arm: Add v7_invalidate_l1 to cache-v7.S"
> moves the v7_invalidate_l1 symbol out of imx/headsmp.S,
> which seems to cause a link error because it is now
> too far away from v7_cpu_resume when building an
> allyesconfig kernel.

Is the problem from the following in arch/arm/mach-imx/headsmp.S:

ENTRY(v7_cpu_resume)
bl  v7_invalidate_l1

Isn't the range of bl +/- 32MiB (or +/- 16MibB in Thumb 2). Is the
kernel really that big? Sorry, I'm having trouble understanding what
causes the problem.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error

2013-02-14 Thread Arnd Bergmann 
Patch c08e20d24 "arm: Add v7_invalidate_l1 to cache-v7.S"
moves the v7_invalidate_l1 symbol out of imx/headsmp.S,
which seems to cause a link error because it is now
too far away from v7_cpu_resume when building an
allyesconfig kernel.

If we move the v7_cpu_resume function from the .data
section to .text, that creates another link error
for the reference to phys_l2x0_saved_regs, but we
can move all of the above to .text.

I believe that this is not a correct bug fix but just
a bad workaround, so I'm open to ideas from people
who understand the bigger picture.

Without this patch, building allyesconfig results in:

arch/arm/mach-imx/built-in.o: In function `v7_cpu_resume':
arch/arm/mach-imx/headsmp.S:55:(.data+0x87f8): relocation truncated to fit: 
R_ARM_CALL against symbol `v7_invalidate_l1' defined in .text section in 
arch/arm/mm/built-in.o

Signed-off-by: Arnd Bergmann 
Cc: Shawn Guo 
Cc: Sascha Hauer 
Cc: Dinh Nguyen 
Cc: Pavel Machek 
Cc: Stephen Warren 
Cc: Simon Horman 
---
 arch/arm/mach-imx/headsmp.S | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
index 921fc15..0de76cc 100644
--- a/arch/arm/mach-imx/headsmp.S
+++ b/arch/arm/mach-imx/headsmp.S
@@ -30,7 +30,7 @@ ENDPROC(v7_secondary_startup)
  * allow phys_l2x0_saved_regs to be accessed with a relative load
  * as we are running on physical address here.
  */
-   .data
+   .text
.align
 
 #ifdef CONFIG_CACHE_L2X0
@@ -51,6 +51,8 @@ phys_l2x0_saved_regs:
.endm
 #endif
 
+   .text
+
 ENTRY(v7_cpu_resume)
bl  v7_invalidate_l1
pl310_resume
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error

2013-02-14 Thread Arnd Bergmann 
Patch c08e20d24 arm: Add v7_invalidate_l1 to cache-v7.S
moves the v7_invalidate_l1 symbol out of imx/headsmp.S,
which seems to cause a link error because it is now
too far away from v7_cpu_resume when building an
allyesconfig kernel.

If we move the v7_cpu_resume function from the .data
section to .text, that creates another link error
for the reference to phys_l2x0_saved_regs, but we
can move all of the above to .text.

I believe that this is not a correct bug fix but just
a bad workaround, so I'm open to ideas from people
who understand the bigger picture.

Without this patch, building allyesconfig results in:

arch/arm/mach-imx/built-in.o: In function `v7_cpu_resume':
arch/arm/mach-imx/headsmp.S:55:(.data+0x87f8): relocation truncated to fit: 
R_ARM_CALL against symbol `v7_invalidate_l1' defined in .text section in 
arch/arm/mm/built-in.o

Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Shawn Guo shawn@linaro.org
Cc: Sascha Hauer s.ha...@pengutronix.de
Cc: Dinh Nguyen dingu...@altera.com
Cc: Pavel Machek pa...@denx.de
Cc: Stephen Warren swar...@nvidia.com
Cc: Simon Horman horms+rene...@verge.net.au
---
 arch/arm/mach-imx/headsmp.S | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
index 921fc15..0de76cc 100644
--- a/arch/arm/mach-imx/headsmp.S
+++ b/arch/arm/mach-imx/headsmp.S
@@ -30,7 +30,7 @@ ENDPROC(v7_secondary_startup)
  * allow phys_l2x0_saved_regs to be accessed with a relative load
  * as we are running on physical address here.
  */
-   .data
+   .text
.align
 
 #ifdef CONFIG_CACHE_L2X0
@@ -51,6 +51,8 @@ phys_l2x0_saved_regs:
.endm
 #endif
 
+   .text
+
 ENTRY(v7_cpu_resume)
bl  v7_invalidate_l1
pl310_resume
-- 
1.8.1.2

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error

2013-02-14 Thread Stephen Warren 
On 02/14/2013 03:47 PM, Arnd Bergmann wrote:
 Patch c08e20d24 arm: Add v7_invalidate_l1 to cache-v7.S
 moves the v7_invalidate_l1 symbol out of imx/headsmp.S,
 which seems to cause a link error because it is now
 too far away from v7_cpu_resume when building an
 allyesconfig kernel.

Is the problem from the following in arch/arm/mach-imx/headsmp.S:

ENTRY(v7_cpu_resume)
bl  v7_invalidate_l1

Isn't the range of bl +/- 32MiB (or +/- 16MibB in Thumb 2). Is the
kernel really that big? Sorry, I'm having trouble understanding what
causes the problem.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/