I just hit an issue cross-compiling the linux-linaro-2.6.37.git source. I'm seeing errors for arch/arm/mach-omap2/sleep34xx.S like:
Error: selected processor does not support ARM mode `smc #1'
It appears to be related to commit:
98be69a ARM: omap3: Remove hand-encoded SMC instructions
After doing a little searching, I stumbled across something similar from John Rigby:
http://marc.info/?l=linux-omap&m=129118316614865&w=2
I "fixed" the problem on my system with this patch:
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index f6614a6..985bc89 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -68,7 +68,7 @@ obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartre obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3) += smartreflex-class3.o
AFLAGS_sleep24xx.o :=-Wa,-march=armv6 -AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a +AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a$(plus_sec)
ifeq ($(CONFIG_PM_VERBOSE),y) CFLAGS_pm_bus.o += -DDEBUG
My question: Is this patch actually needed for cross-compiling our kernel, or is there some additional argument I need to pass to Make when building my kernel?
FYI - My current command line looks like: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- O=out V=1 uImage modules
-andy
On Sat, Feb 19, 2011 at 12:08 AM, Andy Doan andy.doan@linaro.org wrote:
I just hit an issue cross-compiling the linux-linaro-2.6.37.git source. I'm seeing errors for arch/arm/mach-omap2/sleep34xx.S like:
Error: selected processor does not support ARM mode `smc #1'
It appears to be related to commit:
98be69a ARM: omap3: Remove hand-encoded SMC instructions
After doing a little searching, I stumbled across something similar from John Rigby:
http://marc.info/?l=linux-omap&m=129118316614865&w=2
I "fixed" the problem on my system with this patch:
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index f6614a6..985bc89 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -68,7 +68,7 @@ obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartre obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3) += smartreflex-class3.o
AFLAGS_sleep24xx.o :=-Wa,-march=armv6 -AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a +AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a$(plus_sec)
ifeq ($(CONFIG_PM_VERBOSE),y) CFLAGS_pm_bus.o += -DDEBUG
My question: Is this patch actually needed for cross-compiling our kernel, or is there some additional argument I need to pass to Make when building my kernel?
My best guess is that Dave is not using the latest binutils but that is a bit surprising. I think this fix is the right thing, unless Dave has a better fix.
FYI - My current command line looks like: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- O=out V=1 uImage modules
-andy
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On 02/20/2011 12:06 AM, Somebody in the thread at some point said:
Hi -
On Sat, Feb 19, 2011 at 12:08 AM, Andy Doanandy.doan@linaro.org wrote:
I just hit an issue cross-compiling the linux-linaro-2.6.37.git source. I'm seeing errors for arch/arm/mach-omap2/sleep34xx.S like:
+AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a$(plus_sec)
I just met a similar issue earlier in x-loader, I made it go away there by changing global AFLAGS definition to be "-Wa,-march=armv7-a+sec"
I googled around on it and found this
http://osdir.com/ml/kernel-team/2010-12/msg00116.html
suggesting it may be something to do with gcc 4.5.1, which I am using.
-Andy
On Sun, Feb 20, 2011 at 10:45 PM, Andy Green andy@warmcat.com wrote:
On 02/20/2011 12:06 AM, Somebody in the thread at some point said:
Hi -
On Sat, Feb 19, 2011 at 12:08 AM, Andy Doanandy.doan@linaro.org wrote:
I just hit an issue cross-compiling the linux-linaro-2.6.37.git source. I'm seeing errors for arch/arm/mach-omap2/sleep34xx.S like:
+AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a$(plus_sec)
I just met a similar issue earlier in x-loader, I made it go away there by changing global AFLAGS definition to be "-Wa,-march=armv7-a+sec"
I googled around on it and found this
http://osdir.com/ml/kernel-team/2010-12/msg00116.html
suggesting it may be something to do with gcc 4.5.1, which I am using.
The SMC instruction is part of the optional Security Extensions profile. Since around September last year you need to explicitly tell binutils that your chip has this extension by either passing -march=armv7-a+sec to gas or by adding a '.arch_extension sec' directive to the start of the assembly file.
-- Michael