kernel.git/arch/sh/Makefile, branch linux-2.6.28.y

sh: SHmedia ISA tuning fixups.

2008-10-31T06:58:53Z

SH-5 doesn't support any elaborate ISA inheritance schemes (-dsp, -up, etc.), so only bother with that if we are building an sh32 kernel. Signed-off-by: Paul Mundt

sh: Simplify and lock down the ISA tuning.

2008-10-28T10:37:05Z

The ISA tuning as it is today can not cope with all of the different variations that are possible, so all we can do is a best attempt based on the CPU family. The DSP and FPU generation are already at odds with each other, and the nommu tuning we weren't handling at all. Additionally, for platforms that never had an FPU, the -nofpu variant never existed, meaning that we would lose out on family granular tuning completely in certain cases. With tat out of the way, we were also using -up versions, allowing for later instructions that branched off of a particular subset of the ISA, but are not actually reflected on the hardware being targetted. This leads to some confusion, and the possibility of bogus instructions on older parts. Kill that off and lock it down to the family being built for specifically. Signed-off-by: Paul Mundt

sh: sh7785lcr: Select uImage as default image target.

2008-10-28T09:50:00Z

Signed-off-by: Paul Mundt

sh: Fix FPU tuning on toolchains with mismatched multilib targets.

2008-10-28T08:19:35Z

Presently there is very little standing in the way of using an SH-4 toolchain for building an SH-2 kernel, and vice versa. Binutils itself has no limitations whatsoever and supports explicit ISA hinting, which we already use with varying degrees of success today. This leaves GCC as the odd one out, due to a rather dubious policy decision by the GCC folks to not include all of the CPU family variants in the default list of multilib targets in GCC4. Despite best efforts to the contrary, libgcc itself already contains awareness of the various CPU types and remains generally usable, allowing it to safely be referenced even on a mismatched target (and indeed, explicit ISA tuning by binutils keeps us honest in terms of ensuring that we do not link incompatible objects in). In order to support this, a couple of changes had to be made. Firstly, the introduction of MAYBE_DECLARE_EXPORT(), which provides a __weak extern reference for libgcc resident routines when finer-grained -m based tuning is not supported by the toolchain. This fixes up the __sdivsi3_i4i and __udivsi3_i4i references when dealing with SH-2 kernels linked with an SH-4 libgcc. Secondly, in case where we are unable to find a suitable match for CPU family tuning but still have a toolchain that defaults to FP instruction generation, a suitable nofpu target must be selected. This is accomplished by selecting the first nofpu multilib target supported by the toolchain, which is also necessary for selecting the proper libgcc to link against. Signed-off-by: Paul Mundt

sh: Migrate common board headers to mach-common/.

2008-10-20T04:02:48Z

Signed-off-by: Paul Mundt

sh: Provide a fixed UTS_MACHINE definition for sh64.

2008-09-12T09:58:28Z

Signed-off-by: Paul Mundt

sh: fix LIBGCC

2008-08-01T22:23:31Z

Commit f15cbe6f1a4b4d9df59142fc8e4abb973302cf44 (sh: migrate to arch/sh/include/) moved KBUILD_CFLAGS (which is used by LIBGCC) below LIBGCC, causing build errors like the following: <-- snip --> ... LD .tmp_vmlinux1 arch/sh/kernel/built-in.o: In function `module_clk_recalc': clock-sh4.c:(.text+0x80f0): undefined reference to `__udivsi3_i4i' ... make[1]: *** [.tmp_vmlinux1] Error 1 <-- snip --> Reported-by: Adrian Bunk Signed-off-by: Adrian Bunk Signed-off-by: Paul Mundt

sh: Revert the location change of auto-generated asm/machtypes.h

2008-08-01T22:14:09Z

This ended up causing build breakage on O= builds, as reported by Adrian: <-- snip --> ... CC init/main.o In file included from /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/sh/include/asm/irq.h:4, from /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/irq.h:23, from /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/sh/include/asm/hardirq.h:5, from /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/hardirq.h:7, from /home/bunk/linux/kernel-2.6/git/linux-2.6/include/asm-generic/local.h:5, from /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/sh/include/asm/local.h:4, from /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/module.h:19, from /home/bunk/linux/kernel-2.6/git/linux-2.6/init/main.c:13: /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/sh/include/asm/machvec.h:15:27: error: asm/machtypes.h: No such file or directory make[2]: *** [init/main.o] Error 1 <-- snip --> So we simply move machtypes.h back to its original place. asm-offsets.h is still generated there regardless, until such a time that we find a better place to stash auto-generated files. Reported-by: Adrian Bunk Signed-off-by: Paul Mundt

sh: Kill off stray mach-rsk7203 reference.

2008-07-29T16:01:08Z

Signed-off-by: Paul Mundt

sh: Move out individual boards without mach groups.

2008-07-29T15:13:39Z

Signed-off-by: Paul Mundt