linux-next: omap2plus_defconfig not building

linux-next: omap2plus_defconfig not building

[Anand Gadiyar]

Commit ba1b9be5cd in linux-next (ARM: Add SWP/SWPB emulation for ARMv7 
processors (v5)) introduced arch/arm/kernel/swp_emulate.c. This file 
gets compiled when the omap2plus_defconfig is built - the 
omap2plus_defconfig builds OMAP2420, OMAP2430, OMAP3 and OMAP4 in one 
image, and has CPU_V6 and CPU_V7 both enabled.

When I attempt to build this configuration, I get the following build error:

   CC      arch/arm/kernel/swp_emulate.o
/tmp/ccRIcFIf.s: Assembler messages:
/tmp/ccRIcFIf.s:342: Error: selected processor does not support ARM mode 
`ldrexb r6,[r5]'
/tmp/ccRIcFIf.s:343: Error: selected processor does not support ARM mode 
`strexb r1,r3,[r5]'
make[1]: *** [arch/arm/kernel/swp_emulate.o] Error 1
make: *** [arch/arm/kernel] Error 2

I'm able to build when I disable ARCH_OMAP2 (and therefore CPU_V6),
as also (as expected) when I disable CONFIG_SWP_EMULATE.

I'm using Codesourcery's 2010q1-202, based on gcc 4.4.1.
I'm no ARM expert and I'm not even sure if this is an issue with the 
toolchain I am using. Just reporting the problem.

- Anand

linux-next: omap2plus_defconfig not building

[Catalin Marinas]

On Tue, 2010-10-19 at 11:18 +0100, Anand Gadiyar wrote:
> Commit ba1b9be5cd in linux-next (ARM: Add SWP/SWPB emulation for ARMv7
> processors (v5)) introduced arch/arm/kernel/swp_emulate.c. This file
> gets compiled when the omap2plus_defconfig is built - the
> omap2plus_defconfig builds OMAP2420, OMAP2430, OMAP3 and OMAP4 in one
> image, and has CPU_V6 and CPU_V7 both enabled.

This patch should fix it:


ARM: Do not enable SWP emulation if CPU_V6 && CPU_V7

From: Catalin Marinas <catalin.marinas@arm.com>

This option uses LDREXB/STREXB to emulate SWPB but these instructions
are not supported on all the ARMv6 processors.

Reported-by: Anand Gadiyar <gadiyar@ti.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Leif Lindholm <Leif.Lindholm@arm.com>
---
 arch/arm/mm/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 8493ed0..5195d61 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -638,7 +638,7 @@ config ARM_THUMBEE
 
 config SWP_EMULATE
 	bool "Emulate SWP/SWPB instructions"
-	depends on CPU_V7
+	depends on CPU_V7 && !CPU_V6
 	select HAVE_PROC_CPU if PROC_FS
 	default y if SMP
 	help

linux-next: omap2plus_defconfig not building

[Anand Gadiyar]

On 10/19/2010 5:07 PM, Catalin Marinas wrote:
> On Tue, 2010-10-19 at 11:18 +0100, Anand Gadiyar wrote:
>> Commit ba1b9be5cd in linux-next (ARM: Add SWP/SWPB emulation for ARMv7
>> processors (v5)) introduced arch/arm/kernel/swp_emulate.c. This file
>> gets compiled when the omap2plus_defconfig is built - the
>> omap2plus_defconfig builds OMAP2420, OMAP2430, OMAP3 and OMAP4 in one
>> image, and has CPU_V6 and CPU_V7 both enabled.
>
> This patch should fix it:
>

Yes, it does. I've not yet boot tested on omap2; will try
that out in a bit.

OMAP3 and OMAP4 still don't boot on next if support for both are 
compiled together, however that's a separate issue to debug.

Thanks!

- Anand


>
> ARM: Do not enable SWP emulation if CPU_V6&&  CPU_V7
>
> From: Catalin Marinas<catalin.marinas@arm.com>
>
> This option uses LDREXB/STREXB to emulate SWPB but these instructions
> are not supported on all the ARMv6 processors.
>
> Reported-by: Anand Gadiyar<gadiyar@ti.com>
> Signed-off-by: Catalin Marinas<catalin.marinas@arm.com>
> Cc: Leif Lindholm<Leif.Lindholm@arm.com>
> ---
>   arch/arm/mm/Kconfig |    2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index 8493ed0..5195d61 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -638,7 +638,7 @@ config ARM_THUMBEE
>
>   config SWP_EMULATE
>   	bool "Emulate SWP/SWPB instructions"
> -	depends on CPU_V7
> +	depends on CPU_V7&&  !CPU_V6
>   	select HAVE_PROC_CPU if PROC_FS
>   	default y if SMP
>   	help
>
>

linux-next: omap2plus_defconfig not building

[Tony Lindgren]

* Anand Gadiyar <gadiyar@ti.com> [101019 05:06]:
> On 10/19/2010 5:07 PM, Catalin Marinas wrote:
> >On Tue, 2010-10-19 at 11:18 +0100, Anand Gadiyar wrote:
> >>Commit ba1b9be5cd in linux-next (ARM: Add SWP/SWPB emulation for ARMv7
> >>processors (v5)) introduced arch/arm/kernel/swp_emulate.c. This file
> >>gets compiled when the omap2plus_defconfig is built - the
> >>omap2plus_defconfig builds OMAP2420, OMAP2430, OMAP3 and OMAP4 in one
> >>image, and has CPU_V6 and CPU_V7 both enabled.
> >
> >This patch should fix it:
> >
> 
> Yes, it does. I've not yet boot tested on omap2; will try
> that out in a bit.

Thanks that fixes it.

Acked-by: Tony Lindgren <tony@atomide.com>

linux-next: omap2plus_defconfig not building

[Anand Gadiyar]

Catalin Marinas wrote:
>
> On Tue, 2010-10-19 at 11:18 +0100, Anand Gadiyar wrote:
> > Commit ba1b9be5cd in linux-next (ARM: Add SWP/SWPB emulation for ARMv7
> > processors (v5)) introduced arch/arm/kernel/swp_emulate.c. This file
> > gets compiled when the omap2plus_defconfig is built - the
> > omap2plus_defconfig builds OMAP2420, OMAP2430, OMAP3 and OMAP4 in one
> > image, and has CPU_V6 and CPU_V7 both enabled.
>
> This patch should fix it:
>
>
> ARM: Do not enable SWP emulation if CPU_V6 && CPU_V7
>
> From: Catalin Marinas <catalin.marinas@arm.com>
>
> This option uses LDREXB/STREXB to emulate SWPB but these instructions
> are not supported on all the ARMv6 processors.
>
> Reported-by: Anand Gadiyar <gadiyar@ti.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Leif Lindholm <Leif.Lindholm@arm.com>

Hi Catalin, Leif,

I can't find this patch in linux-next. Hope we haven't missed it.
Tony acked this btw.

Strangely, the omap2plus_defconfig in v2.6.37-rc1 no longer gets
CONFIG_SWP_EMULATE enabled even without this patch - I can't figure
out why.

- Anand

> ---
>  arch/arm/mm/Kconfig |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index 8493ed0..5195d61 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -638,7 +638,7 @@ config ARM_THUMBEE
>
>  config SWP_EMULATE
>  	bool "Emulate SWP/SWPB instructions"
> -	depends on CPU_V7
> +	depends on CPU_V7 && !CPU_V6
>  	select HAVE_PROC_CPU if PROC_FS
>  	default y if SMP
>  	help
>
>
>

linux-next: omap2plus_defconfig not building

[Uwe Kleine-König]

Hello,

On Mon, Nov 08, 2010 at 11:35:16AM +0530, Anand Gadiyar wrote:
> Catalin Marinas wrote:
> >
> > On Tue, 2010-10-19 at 11:18 +0100, Anand Gadiyar wrote:
> > > Commit ba1b9be5cd in linux-next (ARM: Add SWP/SWPB emulation for ARMv7
> > > processors (v5)) introduced arch/arm/kernel/swp_emulate.c. This file
> > > gets compiled when the omap2plus_defconfig is built - the
> > > omap2plus_defconfig builds OMAP2420, OMAP2430, OMAP3 and OMAP4 in one
> > > image, and has CPU_V6 and CPU_V7 both enabled.
> >
> > This patch should fix it:
> >
> >
> > ARM: Do not enable SWP emulation if CPU_V6 && CPU_V7
> >
> > From: Catalin Marinas <catalin.marinas@arm.com>
> >
> > This option uses LDREXB/STREXB to emulate SWPB but these instructions
> > are not supported on all the ARMv6 processors.
> >
> > Reported-by: Anand Gadiyar <gadiyar@ti.com>
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Leif Lindholm <Leif.Lindholm@arm.com>
> 
> Hi Catalin, Leif,
> 
> I can't find this patch in linux-next. Hope we haven't missed it.
> Tony acked this btw.
> 
> Strangely, the omap2plus_defconfig in v2.6.37-rc1 no longer gets
> CONFIG_SWP_EMULATE enabled even without this patch - I can't figure
> out why.
I guess that's simply because v2.6.37-rc1 doesn't have ba1b9be5cd.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

linux-next: omap2plus_defconfig not building

[Catalin Marinas]

On Mon, 2010-11-08 at 06:05 +0000, Anand Gadiyar wrote:
> Catalin Marinas wrote:
> > On Tue, 2010-10-19 at 11:18 +0100, Anand Gadiyar wrote:
> > > Commit ba1b9be5cd in linux-next (ARM: Add SWP/SWPB emulation for ARMv7
> > > processors (v5)) introduced arch/arm/kernel/swp_emulate.c. This file
> > > gets compiled when the omap2plus_defconfig is built - the
> > > omap2plus_defconfig builds OMAP2420, OMAP2430, OMAP3 and OMAP4 in one
> > > image, and has CPU_V6 and CPU_V7 both enabled.
> >
> > This patch should fix it:
> >
> >
> > ARM: Do not enable SWP emulation if CPU_V6 && CPU_V7
> >
> > From: Catalin Marinas <catalin.marinas@arm.com>
> >
> > This option uses LDREXB/STREXB to emulate SWPB but these instructions
> > are not supported on all the ARMv6 processors.
> >
> > Reported-by: Anand Gadiyar <gadiyar@ti.com>
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Leif Lindholm <Leif.Lindholm@arm.com>
> 
> I can't find this patch in linux-next. Hope we haven't missed it.
> Tony acked this btw.
> 
> Strangely, the omap2plus_defconfig in v2.6.37-rc1 no longer gets
> CONFIG_SWP_EMULATE enabled even without this patch - I can't figure
> out why.

Russell had a better idea for handling this, not sure whether it went
into -next. It was basically adding -march=armv7-a to
CFLAGS_swp_emulate.o in arch/arm/kernel/Makefile since we can't trigger
an undef fault for SWP on ARMv6 anyway.

If it's not in yet, I can submit a patch.

Catalin

linux-next: omap2plus_defconfig not building

[Russell King - ARM Linux]

On Mon, Nov 08, 2010 at 09:48:13AM +0000, Catalin Marinas wrote:
> Russell had a better idea for handling this, not sure whether it went
> into -next. It was basically adding -march=armv7-a to
> CFLAGS_swp_emulate.o in arch/arm/kernel/Makefile since we can't trigger
> an undef fault for SWP on ARMv6 anyway.

It's probably not a good idea to override the compiler architecture,
but just allow the assembler to accept the instruction.  -Wa,-march=armv7-a
should be good enough.

linux-next: omap2plus_defconfig not building

[Catalin Marinas]

On Mon, 2010-11-08 at 10:14 +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 08, 2010 at 09:48:13AM +0000, Catalin Marinas wrote:
> > Russell had a better idea for handling this, not sure whether it went
> > into -next. It was basically adding -march=armv7-a to
> > CFLAGS_swp_emulate.o in arch/arm/kernel/Makefile since we can't trigger
> > an undef fault for SWP on ARMv6 anyway.
> 
> It's probably not a good idea to override the compiler architecture,
> but just allow the assembler to accept the instruction.  -Wa,-march=armv7-a
> should be good enough.

Yes, even better via AFLAGS. Do you have a patch already or I should
push one?

Catalin

linux-next: omap2plus_defconfig not building

[Russell King - ARM Linux]

On Mon, Nov 08, 2010 at 10:20:51AM +0000, Catalin Marinas wrote:
> On Mon, 2010-11-08 at 10:14 +0000, Russell King - ARM Linux wrote:
> > On Mon, Nov 08, 2010 at 09:48:13AM +0000, Catalin Marinas wrote:
> > > Russell had a better idea for handling this, not sure whether it went
> > > into -next. It was basically adding -march=armv7-a to
> > > CFLAGS_swp_emulate.o in arch/arm/kernel/Makefile since we can't trigger
> > > an undef fault for SWP on ARMv6 anyway.
> > 
> > It's probably not a good idea to override the compiler architecture,
> > but just allow the assembler to accept the instruction.  -Wa,-march=armv7-a
> > should be good enough.
> 
> Yes, even better via AFLAGS.

Not by AFLAGS unless you want to rewrite swp_emulate entirely in assembler!
AFLAGS is used for .S -> .o.  CFLAGS is used for .c -> .o.

> Do you have a patch already or I should push one?

I've already fixed it.

linux-next: omap2plus_defconfig not building

[Catalin Marinas]

On Mon, 2010-11-08 at 10:25 +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 08, 2010 at 10:20:51AM +0000, Catalin Marinas wrote:
> > On Mon, 2010-11-08 at 10:14 +0000, Russell King - ARM Linux wrote:
> > > On Mon, Nov 08, 2010 at 09:48:13AM +0000, Catalin Marinas wrote:
> > > > Russell had a better idea for handling this, not sure whether it went
> > > > into -next. It was basically adding -march=armv7-a to
> > > > CFLAGS_swp_emulate.o in arch/arm/kernel/Makefile since we can't trigger
> > > > an undef fault for SWP on ARMv6 anyway.
> > >
> > > It's probably not a good idea to override the compiler architecture,
> > > but just allow the assembler to accept the instruction.  -Wa,-march=armv7-a
> > > should be good enough.
> >
> > Yes, even better via AFLAGS.
> 
> Not by AFLAGS unless you want to rewrite swp_emulate entirely in assembler!
> AFLAGS is used for .S -> .o.  CFLAGS is used for .c -> .o.

No, what I meant was via -Wa,

> > Do you have a patch already or I should push one?
> 
> I've already fixed it.

Anyway, good that you've fixed it. Thanks.

Catalin

linux-next: omap2plus_defconfig not building

[Anand Gadiyar]

On 11/8/2010 3:18 PM, Catalin Marinas wrote:
> On Mon, 2010-11-08 at 06:05 +0000, Anand Gadiyar wrote:
>> Catalin Marinas wrote:
>>> On Tue, 2010-10-19 at 11:18 +0100, Anand Gadiyar wrote:
>>>> Commit ba1b9be5cd in linux-next (ARM: Add SWP/SWPB emulation for ARMv7
>>>> processors (v5)) introduced arch/arm/kernel/swp_emulate.c. This file
>>>> gets compiled when the omap2plus_defconfig is built - the
>>>> omap2plus_defconfig builds OMAP2420, OMAP2430, OMAP3 and OMAP4 in one
>>>> image, and has CPU_V6 and CPU_V7 both enabled.
>>>
>>> This patch should fix it:
>>>
>>>
>>> ARM: Do not enable SWP emulation if CPU_V6 && CPU_V7
>>>
>>> From: Catalin Marinas <catalin.marinas@arm.com>
>>>
>>> This option uses LDREXB/STREXB to emulate SWPB but these instructions
>>> are not supported on all the ARMv6 processors.
>>>
>>> Reported-by: Anand Gadiyar <gadiyar@ti.com>
>>> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
>>> Cc: Leif Lindholm <Leif.Lindholm@arm.com>
>>
>> I can't find this patch in linux-next. Hope we haven't missed it.
>> Tony acked this btw.
>>
>> Strangely, the omap2plus_defconfig in v2.6.37-rc1 no longer gets
>> CONFIG_SWP_EMULATE enabled even without this patch - I can't figure
>> out why.
> 
> Russell had a better idea for handling this, not sure whether it went
> into -next. It was basically adding -march=armv7-a to
> CFLAGS_swp_emulate.o in arch/arm/kernel/Makefile since we can't trigger
> an undef fault for SWP on ARMv6 anyway.
> 
> If it's not in yet, I can submit a patch.
> 

I tested the patch in current linux-next that adds the CFLAGS_swp_emulate.o

It doesn't solve the compile issue for omap2plus_defconfig.

Here's what a 'make V=1' throws up.

  ccache arm-none-linux-gnueabi-gcc -Wp,-MD,arch/arm/kernel/.swp_emulate.o.d  -nostdinc -isystem /db/omapts/arm-2010q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/include -I/home/userdata/a0393673/mainline/mainline/arch/arm/include -Iinclude  -include include/generated/autoconf.h -D__KERNEL__ -mlittle-endian -Iarch/arm/mach-omap2/include -Iarch/arm/plat-omap/include -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -Os -marm -fno-dwarf2-cfi-asm -mabi=aapcs-linux -mno-thumb-interwork -funwind-tables -D__LINUX_ARM_ARCH__=6 -march=armv6 -mtune=arm1136j-s -msoft-float -Uarm -Wframe-larger-than=1024 -fno-stack-protector -fomit-frame-pointer -g -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Wa,-march=armv7-a    -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(swp_emulate)"  -D"KBUILD_MODNAME=KBUILD_STR(swp_emulate)" -c
 -o arch/arm/kernel/.tmp_swp_emulate.o arch/arm/kernel/swp_emulate.c
/tmp/ccLscgtf.s: Assembler messages:
/tmp/ccLscgtf.s:339: Error: selected processor does not support ARM mode `ldrexb r7,[r6]'
/tmp/ccLscgtf.s:340: Error: selected processor does not support ARM mode `strexb r3,r2,[r6]'
make[1]: *** [arch/arm/kernel/swp_emulate.o] Error 1
make: *** [arch/arm/kernel/] Error 2

- Anand

linux-next: omap2plus_defconfig not building

[Russell King - ARM Linux]

On Thu, Nov 25, 2010 at 07:24:57PM +0530, Anand Gadiyar wrote:
> Here's what a 'make V=1' throws up.
> 
>   ccache arm-none-linux-gnueabi-gcc -Wp,-MD,arch/arm/kernel/.swp_emulate.o.d  -nostdinc -isystem /db/omapts/arm-2010q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/include -I/home/userdata/a0393673/mainline/mainline/arch/arm/include -Iinclude  -include include/generated/autoconf.h -D__KERNEL__ -mlittle-endian -Iarch/arm/mach-omap2/include -Iarch/arm/plat-omap/include -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -Os -marm -fno-dwarf2-cfi-asm -mabi=aapcs-linux -mno-thumb-interwork -funwind-tables -D__LINUX_ARM_ARCH__=6 -march=armv6 -mtune=arm1136j-s -msoft-float -Uarm -Wframe-larger-than=1024 -fno-stack-protector -fomit-frame-pointer -g -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Wa,-march=armv7-a    -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(swp_emulate)"  -D"KBUILD_MODNAME=KBUILD_STR(swp_emulate)" -c
>  -o arch/arm/kernel/.tmp_swp_emulate.o arch/arm/kernel/swp_emulate.c
> /tmp/ccLscgtf.s: Assembler messages:
> /tmp/ccLscgtf.s:339: Error: selected processor does not support ARM mode `ldrexb r7,[r6]'
> /tmp/ccLscgtf.s:340: Error: selected processor does not support ARM mode `strexb r3,r2,[r6]'
> make[1]: *** [arch/arm/kernel/swp_emulate.o] Error 1
> make: *** [arch/arm/kernel/] Error 2

Please do:

make V=1 CFLAGS_KERNEL=-v arch/arm/kernel/swp_emulate.o

and send the output.  This should show what command arguments are being
passed to the assembler.

linux-next: omap2plus_defconfig not building

[Anand Gadiyar]

On 11/25/2010 10:20 PM, Russell King - ARM Linux wrote:
> Please do:
> 
> make V=1 CFLAGS_KERNEL=-v arch/arm/kernel/swp_emulate.o
> 
> and send the output.  This should show what command arguments are being
> passed to the assembler.

Here's the last line of output from the command above. I've attached the
complete log if anyone's interested.

 /db/omapts/arm-2010q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/../../../../arm-none-linux-gnueabi/bin/as -v -I/home/userdata/a0393673/mainline/mainline/arch/arm/include -Iinclude -Iarch/arm/mach-omap2/include -Iarch/arm/plat-omap/include -EL -march=armv6 -mfloat-abi=soft -meabi=5 -march=armv7-a -o /tmp/a0393673/ccache/tmp.hash.ubomapldc13.24604.o /tmp/cc4MQyRN.s
GNU assembler version 2.19.51 (arm-none-linux-gnueabi) using BFD version (Sourcery G++ Lite 2010q1-202) 2.19.51.20090709
/tmp/cc4MQyRN.s: Assembler messages:
/tmp/cc4MQyRN.s:339: Error: selected processor does not support ARM mode `ldrexb r7,[r6]'
/tmp/cc4MQyRN.s:340: Error: selected processor does not support ARM mode `strexb r3,r2,[r6]'
make[1]: *** [arch/arm/kernel/swp_emulate.o] Error 1
make: *** [arch/arm/kernel/swp_emulate.o] Error 2

- Anand



-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: swp-compile-fail.log
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20101126/e0dd40b0/attachment-0001.ksh>

linux-next: omap2plus_defconfig not building

[Russell King - ARM Linux]

On Fri, Nov 26, 2010 at 05:05:41PM +0530, Anand Gadiyar wrote:
> On 11/25/2010 10:20 PM, Russell King - ARM Linux wrote:
> > Please do:
> > 
> > make V=1 CFLAGS_KERNEL=-v arch/arm/kernel/swp_emulate.o
> > 
> > and send the output.  This should show what command arguments are being
> > passed to the assembler.
> 
> Here's the last line of output from the command above. I've attached the
> complete log if anyone's interested.
> 
>  /db/omapts/arm-2010q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/../../../../arm-none-linux-gnueabi/bin/as -v -I/home/userdata/a0393673/mainline/mainline/arch/arm/include -Iinclude -Iarch/arm/mach-omap2/include -Iarch/arm/plat-omap/include -EL -march=armv6 -mfloat-abi=soft -meabi=5 -march=armv7-a -o /tmp/a0393673/ccache/tmp.hash.ubomapldc13.24604.o /tmp/cc4MQyRN.s
> GNU assembler version 2.19.51 (arm-none-linux-gnueabi) using BFD version (Sourcery G++ Lite 2010q1-202) 2.19.51.20090709
> /tmp/cc4MQyRN.s: Assembler messages:
> /tmp/cc4MQyRN.s:339: Error: selected processor does not support ARM mode `ldrexb r7,[r6]'
> /tmp/cc4MQyRN.s:340: Error: selected processor does not support ARM mode `strexb r3,r2,[r6]'
> make[1]: *** [arch/arm/kernel/swp_emulate.o] Error 1
> make: *** [arch/arm/kernel/swp_emulate.o] Error 2

$ arm-linux-as -v -o /dev/null /dev/null
GNU assembler version 2.19.1 (arm-linux) using BFD version (GNU Binutils) 2.19.1
$ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -march=armv7-a -o /dev/null t.s
$ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -o /dev/null t.s
t.s: Assembler messages:
t.s:1: Error: selected processor does not support `ldrexb r7,[r6]'

So it looks like someone's changed the behaviour of the assembler so it's
no longer possible to override the -march= argument from the gcc frontend.

Maybe Will can shed some light on this?

linux-next: omap2plus_defconfig not building

[Will Deacon]

Hi Russell,

> $ arm-linux-as -v -o /dev/null /dev/null
> GNU assembler version 2.19.1 (arm-linux) using BFD version (GNU Binutils) 2.19.1
> $ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -march=armv7-a -o /dev/null t.s
> $ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -o /dev/null t.s
> t.s: Assembler messages:
> t.s:1: Error: selected processor does not support `ldrexb r7,[r6]'
> 
> So it looks like someone's changed the behaviour of the assembler so it's
> no longer possible to override the -march= argument from the gcc frontend.
> 
> Maybe Will can shed some light on this?

Well we pass -march=armv6 to GCC and -march=v7-a to the assembler using the -Wa
option. This means that the compiler generates a .arch armv6 directive in the .s
file and the assembler barfs.

Please can you try this patch?

diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 4036a59..7f32510 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -43,7 +43,7 @@ obj-$(CONFIG_ARM_UNWIND)      += unwind.o
 obj-$(CONFIG_HAVE_TCM)         += tcm.o
 obj-$(CONFIG_CRASH_DUMP)       += crash_dump.o
 obj-$(CONFIG_SWP_EMULATE)      += swp_emulate.o
-CFLAGS_swp_emulate.o           := -Wa,-march=armv7-a
+CFLAGS_swp_emulate.o           := -march=armv7-a
 obj-$(CONFIG_HAVE_HW_BREAKPOINT)       += hw_breakpoint.o
 
 obj-$(CONFIG_CRUNCH)           += crunch.o crunch-bits.o


Will

linux-next: omap2plus_defconfig not building

[Russell King - ARM Linux]

On Fri, Nov 26, 2010 at 12:22:15PM -0000, Will Deacon wrote:
> Hi Russell,
> 
> > $ arm-linux-as -v -o /dev/null /dev/null
> > GNU assembler version 2.19.1 (arm-linux) using BFD version (GNU Binutils) 2.19.1
> > $ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -march=armv7-a -o /dev/null t.s
> > $ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -o /dev/null t.s
> > t.s: Assembler messages:
> > t.s:1: Error: selected processor does not support `ldrexb r7,[r6]'
> > 
> > So it looks like someone's changed the behaviour of the assembler so it's
> > no longer possible to override the -march= argument from the gcc frontend.
> > 
> > Maybe Will can shed some light on this?
> 
> Well we pass -march=armv6 to GCC and -march=v7-a to the assembler using the -Wa
> option. This means that the compiler generates a .arch armv6 directive in the .s
> file and the assembler barfs.
> 
> Please can you try this patch?

We can't do this - we'll end up running ARMv7 code on ARMv6 CPUs.

linux-next: omap2plus_defconfig not building

[Russell King - ARM Linux]

On Fri, Nov 26, 2010 at 12:22:15PM -0000, Will Deacon wrote:
> Hi Russell,
> 
> > $ arm-linux-as -v -o /dev/null /dev/null
> > GNU assembler version 2.19.1 (arm-linux) using BFD version (GNU Binutils) 2.19.1
> > $ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -march=armv7-a -o /dev/null t.s
> > $ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -o /dev/null t.s
> > t.s: Assembler messages:
> > t.s:1: Error: selected processor does not support `ldrexb r7,[r6]'
> > 
> > So it looks like someone's changed the behaviour of the assembler so it's
> > no longer possible to override the -march= argument from the gcc frontend.
> > 
> > Maybe Will can shed some light on this?
> 
> Well we pass -march=armv6 to GCC and -march=v7-a to the assembler using the -Wa
> option. This means that the compiler generates a .arch armv6 directive in the .s
> file and the assembler barfs.

BTW, what this means is that now, we can't support anything but the
targetted CPU with the kernel.  We can say goodbye to multiple-CPU
supporting kernels, and Linaro's idea of having one kernel support
multiple platforms.

linux-next: omap2plus_defconfig not building

[Catalin Marinas]

On Fri, 2010-11-26 at 12:28 +0000, Russell King - ARM Linux wrote:
> On Fri, Nov 26, 2010 at 12:22:15PM -0000, Will Deacon wrote:
> > Hi Russell,
> >
> > > $ arm-linux-as -v -o /dev/null /dev/null
> > > GNU assembler version 2.19.1 (arm-linux) using BFD version (GNU Binutils) 2.19.1
> > > $ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -march=armv7-a -o /dev/null t.s
> > > $ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -o /dev/null t.s
> > > t.s: Assembler messages:
> > > t.s:1: Error: selected processor does not support `ldrexb r7,[r6]'
> > >
> > > So it looks like someone's changed the behaviour of the assembler so it's
> > > no longer possible to override the -march= argument from the gcc frontend.
> > >
> > > Maybe Will can shed some light on this?
> >
> > Well we pass -march=armv6 to GCC and -march=v7-a to the assembler using the -Wa
> > option. This means that the compiler generates a .arch armv6 directive in the .s
> > file and the assembler barfs.
> >
> > Please can you try this patch?
> 
> We can't do this - we'll end up running ARMv7 code on ARMv6 CPUs.

An alternative would be to add the '.arch armv7-a' in the inline
assembly in swp_emulate.c. But that's an ugly workaround and you can't
revert to the previous .arch unless you add another '.arch armv6' at the
end of the asm (with lots of #ifdef's).

We need to check with tools people here since, as you said, there are
wider implications.

-- 
Catalin

linux-next: omap2plus_defconfig not building

[Dave Martin]

On Fri, Nov 26, 2010 at 12:38 PM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> On Fri, 2010-11-26 at 12:28 +0000, Russell King - ARM Linux wrote:
>> On Fri, Nov 26, 2010 at 12:22:15PM -0000, Will Deacon wrote:
>> > Hi Russell,
>> >
>> > > $ arm-linux-as -v -o /dev/null /dev/null
>> > > GNU assembler version 2.19.1 (arm-linux) using BFD version (GNU Binutils) 2.19.1
>> > > $ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -march=armv7-a -o /dev/null t.s
>> > > $ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -o /dev/null t.s
>> > > t.s: Assembler messages:
>> > > t.s:1: Error: selected processor does not support `ldrexb r7,[r6]'
>> > >
>> > > So it looks like someone's changed the behaviour of the assembler so it's
>> > > no longer possible to override the -march= argument from the gcc frontend.
>> > >
>> > > Maybe Will can shed some light on this?
>> >
>> > Well we pass -march=armv6 to GCC and -march=v7-a to the assembler using the -Wa
>> > option. This means that the compiler generates a .arch armv6 directive in the .s
>> > file and the assembler barfs.
>> >
>> > Please can you try this patch?
>>
>> We can't do this - we'll end up running ARMv7 code on ARMv6 CPUs.
>
> An alternative would be to add the '.arch armv7-a' in the inline
> assembly in swp_emulate.c. But that's an ugly workaround and you can't
> revert to the previous .arch unless you add another '.arch armv6' at the
> end of the asm (with lots of #ifdef's).

This is an instance of the general problem that while the assembler is
stateful, it's impossible to query most aspects of its state (such as
the target arch) during assembly...

If we just need to remember default settings so we can restore them,
we can add definitions in CFLAGS or headers to achieve this.

If we added, say, -DARM_RESTORE_BASE_ARCH="\".arch <architecture>\""
to the CFLAGS, inline asm could do something like this:

asm(
        ".arch armv7-a"
        [...]
        ARM_RESTORE_BASE_ASCH
);

any help?

Cheers
---Dave

linux-next: omap2plus_defconfig not building

[Russell King - ARM Linux]

On Fri, Nov 26, 2010 at 12:38:54PM +0000, Catalin Marinas wrote:
> On Fri, 2010-11-26 at 12:28 +0000, Russell King - ARM Linux wrote:
> > On Fri, Nov 26, 2010 at 12:22:15PM -0000, Will Deacon wrote:
> > > Hi Russell,
> > >
> > > > $ arm-linux-as -v -o /dev/null /dev/null
> > > > GNU assembler version 2.19.1 (arm-linux) using BFD version (GNU Binutils) 2.19.1
> > > > $ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -march=armv7-a -o /dev/null t.s
> > > > $ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -o /dev/null t.s
> > > > t.s: Assembler messages:
> > > > t.s:1: Error: selected processor does not support `ldrexb r7,[r6]'
> > > >
> > > > So it looks like someone's changed the behaviour of the assembler so it's
> > > > no longer possible to override the -march= argument from the gcc frontend.
> > > >
> > > > Maybe Will can shed some light on this?
> > >
> > > Well we pass -march=armv6 to GCC and -march=v7-a to the assembler using the -Wa
> > > option. This means that the compiler generates a .arch armv6 directive in the .s
> > > file and the assembler barfs.
> > >
> > > Please can you try this patch?
> > 
> > We can't do this - we'll end up running ARMv7 code on ARMv6 CPUs.
> 
> An alternative would be to add the '.arch armv7-a' in the inline
> assembly in swp_emulate.c. But that's an ugly workaround and you can't
> revert to the previous .arch unless you add another '.arch armv6' at the
> end of the asm (with lots of #ifdef's).

Yup, so this won't work either.  Also, as I understand it, I don't think
you can rely upon the compiler ordering functions wrt. asm() statements
outside of the function blocks, so I don't think this will work anyway.

We could separate out the non-ARMv7 specific code into a separate file
(maybe called swp_emulate-init.c) and export proc_read_status and swp_hook
into the global namespace.  These would have to be renamed to avoid any
possible clashes with other symbols.

We could just take the view that we don't allow SWP on ARMv7 at all,
which would make it a pain for userspace people.

We could also re-enable SWP support on ARMv7 without the emulation code.

Luckily, this is the only place - at present - where we have C code built
containing instructions (via asm() statements) for higher versions of the
architecture.

linux-next: omap2plus_defconfig not building

[Dave Martin]

On Fri, Nov 26, 2010 at 1:00 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Nov 26, 2010 at 12:38:54PM +0000, Catalin Marinas wrote:
>> On Fri, 2010-11-26 at 12:28 +0000, Russell King - ARM Linux wrote:
>> > On Fri, Nov 26, 2010 at 12:22:15PM -0000, Will Deacon wrote:
>> > > Hi Russell,
>> > >
>> > > > $ arm-linux-as -v -o /dev/null /dev/null
>> > > > GNU assembler version 2.19.1 (arm-linux) using BFD version (GNU Binutils) 2.19.1
>> > > > $ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -march=armv7-a -o /dev/null t.s
>> > > > $ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -o /dev/null t.s
>> > > > t.s: Assembler messages:
>> > > > t.s:1: Error: selected processor does not support `ldrexb r7,[r6]'
>> > > >
>> > > > So it looks like someone's changed the behaviour of the assembler so it's
>> > > > no longer possible to override the -march= argument from the gcc frontend.
>> > > >
>> > > > Maybe Will can shed some light on this?
>> > >
>> > > Well we pass -march=armv6 to GCC and -march=v7-a to the assembler using the -Wa
>> > > option. This means that the compiler generates a .arch armv6 directive in the .s
>> > > file and the assembler barfs.
>> > >
>> > > Please can you try this patch?
>> >
>> > We can't do this - we'll end up running ARMv7 code on ARMv6 CPUs.
>>
>> An alternative would be to add the '.arch armv7-a' in the inline
>> assembly in swp_emulate.c. But that's an ugly workaround and you can't
>> revert to the previous .arch unless you add another '.arch armv6' at the
>> end of the asm (with lots of #ifdef's).
>
> Yup, so this won't work either. ?Also, as I understand it, I don't think
> you can rely upon the compiler ordering functions wrt. asm() statements
> outside of the function blocks, so I don't think this will work anyway.

The compiler treats inline asms as solid lumps, so providing that the
two .arch directives are inside the affected inline asm block, it
should work.

What you presumably can't do reliably is something like

#include <...>
#include <...>

asm(".arch armv7-a");

...

{
    asm( v7-dependent code )
}

> We could separate out the non-ARMv7 specific code into a separate file
> (maybe called swp_emulate-init.c) and export proc_read_status and swp_hook
> into the global namespace. ?These would have to be renamed to avoid any
> possible clashes with other symbols.
>
> We could just take the view that we don't allow SWP on ARMv7 at all,
> which would make it a pain for userspace people.
>
> We could also re-enable SWP support on ARMv7 without the emulation code.
>
> Luckily, this is the only place - at present - where we have C code built
> containing instructions (via asm() statements) for higher versions of the
> architecture.

For this case, I agree that separating the affected assembler out into
a separate .S file is probably the cleanest and simplest solution...
but I guess we should think about whether we're going to need to
revisit this in the future.

Cheers
---Dave

linux-next: omap2plus_defconfig not building

[Russell King - ARM Linux]

On Fri, Nov 26, 2010 at 01:31:15PM +0000, Dave Martin wrote:
> On Fri, Nov 26, 2010 at 1:00 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Nov 26, 2010 at 12:38:54PM +0000, Catalin Marinas wrote:
> >> On Fri, 2010-11-26 at 12:28 +0000, Russell King - ARM Linux wrote:
> >> > On Fri, Nov 26, 2010 at 12:22:15PM -0000, Will Deacon wrote:
> >> > > Hi Russell,
> >> > >
> >> > > > $ arm-linux-as -v -o /dev/null /dev/null
> >> > > > GNU assembler version 2.19.1 (arm-linux) using BFD version (GNU Binutils) 2.19.1
> >> > > > $ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -march=armv7-a -o /dev/null t.s
> >> > > > $ arm-linux-as -march=armv6 -mfloat-abi=soft -meabi=5 -o /dev/null t.s
> >> > > > t.s: Assembler messages:
> >> > > > t.s:1: Error: selected processor does not support `ldrexb r7,[r6]'
> >> > > >
> >> > > > So it looks like someone's changed the behaviour of the assembler so it's
> >> > > > no longer possible to override the -march= argument from the gcc frontend.
> >> > > >
> >> > > > Maybe Will can shed some light on this?
> >> > >
> >> > > Well we pass -march=armv6 to GCC and -march=v7-a to the assembler using the -Wa
> >> > > option. This means that the compiler generates a .arch armv6 directive in the .s
> >> > > file and the assembler barfs.
> >> > >
> >> > > Please can you try this patch?
> >> >
> >> > We can't do this - we'll end up running ARMv7 code on ARMv6 CPUs.
> >>
> >> An alternative would be to add the '.arch armv7-a' in the inline
> >> assembly in swp_emulate.c. But that's an ugly workaround and you can't
> >> revert to the previous .arch unless you add another '.arch armv6' at the
> >> end of the asm (with lots of #ifdef's).
> >
> > Yup, so this won't work either. ?Also, as I understand it, I don't think
> > you can rely upon the compiler ordering functions wrt. asm() statements
> > outside of the function blocks, so I don't think this will work anyway.
> 
> The compiler treats inline asms as solid lumps, so providing that the
> two .arch directives are inside the affected inline asm block, it
> should work.
> 
> What you presumably can't do reliably is something like
> 
> #include <...>
> #include <...>
> 
> asm(".arch armv7-a");
> 
> ...
> 
> {
>     asm( v7-dependent code )
> }
> 
> > We could separate out the non-ARMv7 specific code into a separate file
> > (maybe called swp_emulate-init.c) and export proc_read_status and swp_hook
> > into the global namespace. ?These would have to be renamed to avoid any
> > possible clashes with other symbols.
> >
> > We could just take the view that we don't allow SWP on ARMv7 at all,
> > which would make it a pain for userspace people.
> >
> > We could also re-enable SWP support on ARMv7 without the emulation code.
> >
> > Luckily, this is the only place - at present - where we have C code built
> > containing instructions (via asm() statements) for higher versions of the
> > architecture.
> 
> For this case, I agree that separating the affected assembler out into
> a separate .S file is probably the cleanest and simplest solution...
> but I guess we should think about whether we're going to need to
> revisit this in the future.

Maybe we need to make the ability to build for several differing CPU
architectures a requirement for the toolchain people, and have a more
official way to do this than hacking around with the assembler.

linux-next: omap2plus_defconfig not building

[Tony Lindgren]

* Catalin Marinas <catalin.marinas@arm.com> [101108 01:38]:
> On Mon, 2010-11-08 at 06:05 +0000, Anand Gadiyar wrote:
> > Catalin Marinas wrote:
> > > On Tue, 2010-10-19 at 11:18 +0100, Anand Gadiyar wrote:
> > > > Commit ba1b9be5cd in linux-next (ARM: Add SWP/SWPB emulation for ARMv7
> > > > processors (v5)) introduced arch/arm/kernel/swp_emulate.c. This file
> > > > gets compiled when the omap2plus_defconfig is built - the
> > > > omap2plus_defconfig builds OMAP2420, OMAP2430, OMAP3 and OMAP4 in one
> > > > image, and has CPU_V6 and CPU_V7 both enabled.
> > >
> > > This patch should fix it:
> > >
> > >
> > > ARM: Do not enable SWP emulation if CPU_V6 && CPU_V7
> > >
> > > From: Catalin Marinas <catalin.marinas@arm.com>
> > >
> > > This option uses LDREXB/STREXB to emulate SWPB but these instructions
> > > are not supported on all the ARMv6 processors.
> > >
> > > Reported-by: Anand Gadiyar <gadiyar@ti.com>
> > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > > Cc: Leif Lindholm <Leif.Lindholm@arm.com>
> > 
> > I can't find this patch in linux-next. Hope we haven't missed it.
> > Tony acked this btw.
> > 
> > Strangely, the omap2plus_defconfig in v2.6.37-rc1 no longer gets
> > CONFIG_SWP_EMULATE enabled even without this patch - I can't figure
> > out why.
> 
> Russell had a better idea for handling this, not sure whether it went
> into -next. It was basically adding -march=armv7-a to
> CFLAGS_swp_emulate.o in arch/arm/kernel/Makefile since we can't trigger
> an undef fault for SWP on ARMv6 anyway.
> 
> If it's not in yet, I can submit a patch.

Catalin, you patch is still needed until we have a better solution.

Looks like the long term solution is to move the _user_swpX_asm
into a separate .S file and set the v7 instructions for it.

Regards,

Tony

linux-next: omap2plus_defconfig not building

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [101223 12:01]:
> 
> Looks like the long term solution is to move the _user_swpX_asm
> into a separate .S file and set the v7 instructions for it.

I mean set the v7 compiler flags for it..

Tony

linux-next: omap2plus_defconfig not building

[Russell King - ARM Linux]

On Thu, Dec 23, 2010 at 11:55:03AM -0800, Tony Lindgren wrote:
> * Catalin Marinas <catalin.marinas@arm.com> [101108 01:38]:
> > On Mon, 2010-11-08 at 06:05 +0000, Anand Gadiyar wrote:
> > > I can't find this patch in linux-next. Hope we haven't missed it.
> > > Tony acked this btw.
> > > 
> > > Strangely, the omap2plus_defconfig in v2.6.37-rc1 no longer gets
> > > CONFIG_SWP_EMULATE enabled even without this patch - I can't figure
> > > out why.

That'll be because swap emulation isn't in v2.6.37-rc1.  It's queued
for 2.6.38's merge window.

> > Russell had a better idea for handling this, not sure whether it went
> > into -next. It was basically adding -march=armv7-a to
> > CFLAGS_swp_emulate.o in arch/arm/kernel/Makefile since we can't trigger
> > an undef fault for SWP on ARMv6 anyway.
> > 
> > If it's not in yet, I can submit a patch.

It's also queued for 2.6.38, but there is an issue with the latest gcc
stuffing a .armv7 directive (or whatever) at the beginning of its
output, thereby overriding the -Wa,-march=armv7-a on the command line.
I think someone's looking at fixing GCC.

This stuff _is_ in linux-next, and has been in linux-next for ages.

linux-next: omap2plus_defconfig not building

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [101223 12:30]:
> 
> It's also queued for 2.6.38, but there is an issue with the latest gcc
> stuffing a .armv7 directive (or whatever) at the beginning of its
> output, thereby overriding the -Wa,-march=armv7-a on the command line.
> I think someone's looking at fixing GCC.
> 
> This stuff _is_ in linux-next, and has been in linux-next for ages.

Yes, but that's a different patch :) Sorry I should have provided a link
for the one I'm talking about, it's the patch that changes the options
for SWP_EMULATE to have "depends on CPU_V7 && !CPU_V6":

http://marc.info/?l=linux-arm-kernel&m=128748874510144&w=2

That's still needed until we have the assembly in a separate .S file,
or have the GCC options changed.

Regards,

Tony

linux-next: omap2plus_defconfig not building

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [101223 13:12]:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [101223 12:30]:
> > 
> > It's also queued for 2.6.38, but there is an issue with the latest gcc
> > stuffing a .armv7 directive (or whatever) at the beginning of its
> > output, thereby overriding the -Wa,-march=armv7-a on the command line.
> > I think someone's looking at fixing GCC.
> > 
> > This stuff _is_ in linux-next, and has been in linux-next for ages.
> 
> Yes, but that's a different patch :) Sorry I should have provided a link
> for the one I'm talking about, it's the patch that changes the options
> for SWP_EMULATE to have "depends on CPU_V7 && !CPU_V6":
> 
> http://marc.info/?l=linux-arm-kernel&m=128748874510144&w=2
> 
> That's still needed until we have the assembly in a separate .S file,
> or have the GCC options changed.

I'll queue Catalin's patch as I need it for omap2plus_defconfig to
build. Let me if you want to take it and I'll drop it.

Regards,

Tony