[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
Russell King - ARM Linux
linux at arm.linux.org.uk
Fri Jan 14 18:58:40 EST 2011
On Fri, Jan 14, 2011 at 04:10:29PM -0700, Paul Walmsley wrote:
> I wonder if, in a similar vein, you would consider adding a CONFIG_CPU_V6
> plus CONFIG_CPU_V7 config, such as omap2plus_defconfig, into your
> compile-testing regimen, if one is not already present?
> That would help catch compile problems like the recent CONFIG_SWP_EMULATE
Such as these?
../build/omap3/.config:# CONFIG_SWP_EMULATE is not set
../build/omap4/.config:# CONFIG_SWP_EMULATE is not set
So, I already have configs for V7 only+SWP_EMULATE=y, V7 only+SWP_EMULATE=n,
V6 only, V6+V7+SWP_EMULATE=y but not V6+V7+SWP_EMULATE=n
It doesn't appear for me because my toolchain new enough to be broken.
What has been merged into the toolchain (gcc emitting a .armv7 at the
beginning of its assembler output) was a pretty stupid idea as it's
going to break _everything_ out there which has been carefully crafted
to compile for ARMv6 but selectively use ARMv7 instructions.
I am very much of the opinion that this new "feature" needs to be removed
from the toolchain, and it should do as previous versions of the toolchain
does - where the gcc frontend passes the correct architecture flags to
This "feature" will have broken a lot more than just the SWP emulate code
in the kernel - anything which tries to build a kernel crossing several
CPU architectures will hit this failure.
This is what I get from building the realview configuration listed above:
$ emake O=../build/realview/ arch/arm/kernel/
Using /home/rmk/git/linux-2.6-rmk as source for kernel
make: `include/generated/mach-types.h' is up to date.
So, as you can see, it builds perfectly fine for me. GCC 4.3.5,
binutils 2.19.1. The command used to build swp_emulate.o was:
arm-linux-gcc -Wp,-MD,arch/arm/kernel/.swp_emulate.o.d -nostdinc
-I/home/rmk/git/linux-2.6-rmk/include -include include/generated/autoconf.h
-Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
-Wno-format-security -fno-delete-null-pointer-checks -O2 -marm
-fno-omit-frame-pointer -mapcs -mno-sched-prolog -mabi=aapcs-linux
-mno-thumb-interwork -D__LINUX_ARM_ARCH__=6 -march=armv6k -mtune=arm1136j-s
-msoft-float -Uarm -fno-stack-protector -fno-omit-frame-pointer
-fno-optimize-sibling-calls -Wdeclaration-after-statement -Wno-pointer-sign
-c -o arch/arm/kernel/swp_emulate.o
So, the reason I don't see it is because I don't build the omap2plus_defconfig
bool "Support ARM V6K processor extensions" if !SMP
depends on CPU_V6 || CPU_V7
default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
OMAP2 prevents the selection of armv6k support. This is probably a very
bad idea if you want to run the resulting kernel on SMP hardware as it
removes a barrier in the spinlock code and disables the SMP-safe bitops.
The original patch which started turning this off was from the MX3 stuff,
but without explaination.
However, OMAP extended this to disabling the select statement for CPU_32v6K
even if CPU_V7 is set:
bool "Support ARM V7 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB |- select CPU_32v6K
+ select CPU_32v6K if !ARCH_OMAP2
Arguably, SMP _requires_ CPU_32v6K to be enabled for a safe kernel, and this
patch should not have been merged.
More information about the linux-arm-kernel