path: root/arch/arm/vfp/Makefile
AgeCommit message (Collapse)Author
2011-10-01ARM: vfp: use -mfloat-abi=soft to build vfpArnd Bergmann
Distros are starting to ship with toolchains defaulting to hardfloat. Using such a compiler to build the kernel fails in the VFP directory with arch/arm/vfp/entry.S:1:0: sorry, unimplemented: -mfloat-abi=hard and VFP Adding -mfloat-abi=soft to the gcc command line fixes this. Signed-off-by: Arnd Bergmann <>
2011-03-17arm: change to new flag variablesmatt mooney
Replace EXTRA_CFLAGS with ccflags-y and EXTRA_AFLAGS with asflags-y. Signed-off-by: matt mooney <> Acked-by: WANG Cong <> Signed-off-by: Michal Marek <>
2007-10-15kbuild: enable 'make AFLAGS=...' to add additional options to ASSam Ravnborg
The variable AFLAGS is a wellknown variable and the usage by kbuild may result in unexpected behaviour. On top of that several people over time has asked for a way to pass in additional flags to gcc. This patch replace use of AFLAGS with KBUILD_AFLAGS all over the tree. Patch was tested on following architectures: alpha, arm, i386, x86_64, mips, sparc, sparc64, ia64, m68k, s390 Signed-off-by: Sam Ravnborg <>
2006-06-22[ARM] Enable VFP to be built when non-VFP capable CPUs are selectedRussell King
Since we pass flags to the compiler to control code generation based on the least capable selected CPU, if we want to include VFP support, we must tweak the assembler flags to allow the VFP instructions. Moreover, we must not use the mrrc/mcrr versions since these will not be recognised by the assembler. We do not convert all instructions to the VFP-equivalent (yet) since binutils appears to barf on "fmrx rn, fpinst" and doesn't provide any other way (other than using the mrc equivalent) to encode this instruction - which is rather a problem when you have a VFP implementation which requires these instructions. Signed-off-by: Russell King <>
2005-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!