| Age | Commit message (Collapse) | Author |
|---|
|
This adds the basic support for running on BPA machines.
So far, this is only the IBM workstation, and it will
not run on others without a little more generalization.
It should be possible to configure a kernel for any
combination of CONFIG_PPC_BPA with any of the other
multiplatform targets.
Signed-off-by: Arnd Bergmann <arndb@de.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
|
|
co for biarch compilers
The following kind of calls currently fails :
make ARCH=ppc64 CC="gcc-3.4"
Since the code for detecting a biarch compiler and adding the needed 64bit
magic argument fails if the AS/LD/CC commands are overriden in the command
line.
The attached patch fixes this by using the make override and += directive,
but i am not 100% sure this will work without gmake, as i am no Makefile
expert.
Cc: Paul Mackerras <paulus@samba.org>
Cc: Anton Blanchard <anton@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
gcc-4.0 generates altivec code implicitly when -mcpu indicates an
altivec capable CPU which is not suitable for the kernel. However, we
used to set -mcpu=970 when CONFIG_ALTIVEC was set because a gcc-3.x bug
prevented from using -maltivec along with -mcpu=power4, thus prevented
building the RAID6 altivec code.
This patch fixes all of this by testing for the gcc version. If 4.0 or
later, just normally use -mcpu=power4 and let the RAID6 code add
-maltivec to the few files it needs to be compiled with altivec support.
For 3.x, we still use -mcpu=970 to work around the above problem, which
is fine as 3.x will never implicitly generate altivec code.
The Makefile hackery may not be the most lovely, I welcome anybody more
skilled than me to improve it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
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!
|
