aboutsummaryrefslogtreecommitdiffstats
path: root/arch/ppc64/Makefile
Commit message (Collapse)AuthorAgeFilesLines
* powerpc: fix __strnlen_user in merge treeStephen Rothwell2005-11-011-1/+0
| | | | | | | | Change USER/KERNEL_DS so that the merged version of __strnlen_user can be used which allows us to complete the removal of arch/ppc64/lib/. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
* [PATCH] ppc64: reenable make install with defconfigOlaf Hering2005-10-291-1/+1
| | | | | | | | | | | | 'make ARCH=ppc64 O=../O install' does not work with the defconfig. CONFIG_PPC_BPA is part of it, but the BPA bootimage variable is wrong: make[2]: *** No rule to make target `zImage', needed by `install'. Stop. Signed-off-by: Olaf Hering <olh@suse.de> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
* [PATCH] ppc: prevent GCC 4 from generating AltiVec instructions in kernelLee Nicks2005-10-291-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Depending on how GCC is built, GCC 4 may generate altivec instructions without user explicitly requesting vector operations in the code. Although this is a performance booster for user applications, it is a problem for kernel. This patch explicitly instruct GCC to NOT generate altivec instructions while building the kernel. Here are some test cases I ran. (1) build gcc 4.0.1 with '--with-cpu=7450 --enable-altivec --enable-cxx-flags=-mcpu=7450', and use this gcc to build kernel WITHOUT this kernel patch. Kernel fail to boot up on a 7450 board because of altivec instructions in kernel. (2) build gcc 4.0.1 with "--with-cpu=7450 --enable-altivec --enable-cxx-flags=-mcpu=7450", and use this gcc to build kernel WITH this kernel patch. Kernel boot up on a 7450 board without any problem. (3) build gcc 4.0.1 with "--with-cpu=750 --enable-cxx-flags=-mcpu=750", and use this gcc to build kernel with or without this kernel patch. Kernel boot up on a 7450 board without any problem. This patch should also work with GCC 3 or even earlier GCC 2.95.3. Signed-off-by: Lee Nicks <allinux@gmail.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
* powerpc: Merge xmonPaul Mackerras2005-10-281-1/+1
| | | | | | | | | | | The merged version follows the ppc64 version pretty closely mostly, and in fact ARCH=ppc64 now uses the arch/powerpc/xmon version. The main difference for ppc64 is that the 'p' command to call show_state (which was always pretty dodgy) has been replaced by the ppc32 'p' command, which calls a given procedure (so in fact the old 'p' command behaviour can be achieved with 'p $show_state'). Signed-off-by: Paul Mackerras <paulus@samba.org>
* ppc64: use checksum_64.S from powerpcStephen Rothwell2005-10-281-0/+1
| | | | | | as it is identical to checksum.S from ppc64. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
* ppc64: use the merged syscall tableStephen Rothwell2005-10-281-0/+1
| | | | | | | This allows us to also use entry_64.S from the merged tree and reverts the setup_64.c part of fda262b8978d0089758ef9444508434c74113a61. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
* [PATCH] powerpc: Fix handling of fpscr on 64-bitDavid Gibson2005-10-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The recent merge of fpu.S broken the handling of fpscr for ARCH=powerpc and CONFIG_PPC64=y. FP registers could be corrupted, leading to strange random application crashes. The confusion arises, because the thread_struct has (and requires) a 64-bit area to save the fpscr, because we use load/store double instructions to get it in to/out of the FPU. However, only the low 32-bits are actually used, so we want to treat it as a 32-bit quantity when manipulating its bits to avoid extra load/stores on 32-bit. This patch replaces the current definition with a structure of two 32-bit quantities (pad and val), to clarify things as much as is possible. The 'val' field is used when manipulating bits, the structure itself is used when obtaining the address for loading/unloading the value from the FPU. While we're at it, consolidate the 4 (!) almost identical versions of cvt_fd() and cvt_df() (arch/ppc/kernel/misc.S, arch/ppc64/kernel/misc.S, arch/powerpc/kernel/misc_32.S, arch/powerpc/kernel/misc_64.S) into a single version in fpu.S. The new version takes a pointer to thread_struct and applies the correct offset itself, rather than a pointer to the fpscr field itself, again to avoid confusion as to which is the correct field to use. Finally, this patch makes ARCH=ppc64 also use the consolidated fpu.S code, which it previously did not. Built for G5 (ARCH=ppc64 and ARCH=powerpc), 32-bit powermac (ARCH=ppc and ARCH=powerpc) and Walnut (ARCH=ppc, CONFIG_MATH_EMULATION=y). Booted on G5 (ARCH=powerpc) and things which previously fell over no longer do. Signed-off-by: David Gibson <dwg@au1.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
* ppc64: Use the merged mpic.cPaul Mackerras2005-10-201-0/+1
| | | | | | This means we now compile in arch/powerpc/sysdev for ARCH=ppc64. Signed-off-by: Paul Mackerras <paulus@samba.org>
* powerpc: Merge arch/ppc64/mm to arch/powerpc/mmPaul Mackerras2005-10-101-1/+1
| | | | | | | This moves the remaining files in arch/ppc64/mm to arch/powerpc/mm, and arranges that we use them when compiling with ARCH=ppc64. Signed-off-by: Paul Mackerras <paulus@samba.org>
* ppc64: simplify the build a littleStephen Rothwell2005-10-011-1/+1
| | | | Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
* powerpc: Create arch/powerpc/platforms/iseriesStephen Rothwell2005-09-271-0/+1
| | | | | | | I also move arch/ppc64/kernel/HvCall.c to arch/powerpc/platforms/iseries/hvcall.c. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
* Merge from Linus' tree.Paul Mackerras2005-09-251-1/+1
|\
| * [PATCH] ppc64: Build zImage.vmode for G5Benjamin Herrenschmidt2005-09-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | zImage.vmode was recently added. It's a version of zImage in which the ELF note section used by open firmware indicates that it requires a virtual mode instance of OF instead of real mode. This allows it to work with Apple OF, and thus is directly bootable (or netbootable) from OF command line. (Unfortunately, pSeries OF sort-of requires real mode and Apple OF sort-of requires virtual mode, and both tend to be unhappy if no notes section specifies the mode at all). However, we forgot to add zImage.vmode to the default G5 build. This fixes it. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* | [PATCH] powerpc: merge the rest of arch/ppc*/oprofileStephen Rothwell2005-09-211-1/+1
|/ | | | | | | | | | - merge common.c - move model specific files - remove stub Makefiles - clean up arch/ppc*/Makefile Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Paul Mackerras <paulus@samba.org>
* [PATCH] powerpc: Move include3 to arch/$(ARCH)/includeStephen Rothwell2005-09-101-6/+7
| | | | | | | This is less troublesome and makes more sense. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Merge master.kernel.org:/pub/scm/linux/kernel/git/sam/kbuild Linus Torvalds2005-09-091-9/+0
|\
| * kbuild: m68k,parisc,ppc,ppc64,s390,xtensa use generic asm-offsets.h supportSam Ravnborg2005-09-091-9/+0
| | | | | | | | | | | | Delete obsoleted parts form arch makefiles and rename to asm-offsets.h Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
* | [PATCH] ppc64: zimage build fixGeoff Levand2005-09-091-9/+12
|/ | | | | Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
* [PATCH] CHECKFLAGS on ppc64 got brokenviro@ZenIV.linux.org.uk2005-09-071-1/+1
| | | | | | | | Now that asm-powerpc/* is using ifdefs on __powerpc64__ we need to add it to CHECKFLAGS on ppc64. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] Create include/asm-powerpcStephen Rothwell2005-08-301-0/+9
| | | | | | | | | | | | | The ppc and ppc64 trees are hopefully going to merge over time, so this patch begins the process by creating a place for the merging of the header files. Create include/asm-powerpc (and move linkage.h into it from asm-{ppc,ppc64} since we don't like empty directories). Modify the ppc and ppc64 Makefiles to cope. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Paul Mackerras <paulus@samba.org>
* [PATCH] ppc64: add BPA platform typeArnd Bergmann2005-06-231-0/+2
| | | | | | | | | | | | | 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>
* [PATCH] ppc64: override command line AS/LD/CC variables when adding -m64 and ↵Sven Luther2005-06-211-3/+3
| | | | | | | | | | | | | | | | | | | | | | 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>
* [PATCH] ppc64: fix gcc 4.0 vs CONFIG_ALTIVECBenjamin Herrenschmidt2005-05-031-0/+7
| | | | | | | | | | | | | | | | | | | | 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>
* Linux-2.6.12-rc2Linus Torvalds2005-04-161-0/+122
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!
generated by cgit v1.1 at 2024-12-27 14:58:03 +0000