The vsyscall targets are presently not cleaned up, so just handle it in
the archclean rule.
Reported-by: Magnus Damm <damm@igel.co.jp>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This implements a simple case that just iterates through the common
cases, looking at UTS_MACHINE for hints.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This introduces a BITS export that can handily be picked up by Makefiles
for cleaner sharing. Reflect its use in arch/sh/boot/compressed/ in
preparation for unifying the Makefiles.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Tie this in to the Makefile directly, where we already know what we are
running on. This tidies up the linker script a bit, and is prep work for
unifying the arch/sh/boot/compressed linker scripts.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
There is no real reason to use this anymore, as the build system
generally knows what it is doing with regards to cflags mangling.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
RSK+ platforms have quite a few characteristics in common, so roll them
together in to a shiny new RSK mach-type.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This was removed in the libgcc integration, but there are still some
compilers that need this. We also relax the rules on the ISA tuning in
the cases where there are no matches for the CPU tuning and adopt the
-any default, which matches the intent of the isa-y target list. This
compensates for mismatches where binutils supports a wide array of
targets whilst the compiler is much more restricted.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This moves in the necessary libgcc bits for SUPERH32 and drops the
libgcc linking for the regular targets. This in turn allows us to rip
out quite a few hacks both in sh_ksyms_32 and arch/sh/Makefile.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
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 <lethal@linux-sh.org>
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 <lethal@linux-sh.org>
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<cpu-family> 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 <lethal@linux-sh.org>
Commit f15cbe6f1a
(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 <bunk@kernel.org>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
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 <bunk@kernel.org>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This flattens out the board directories in to individual mach groups,
we will use this for getting rid of unneeded directories, simplifying
the build system, and becoming more coherent with the refactored
arch/sh/include topology.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This follows the sparc changes a439fe51a1.
Most of the moving about was done with Sam's directions at:
http://marc.info/?l=linux-sh&m=121724823706062&w=2
with subsequent hacking and fixups entirely my fault.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This adds initial support for the Renesas R0P7785LC0011RL board.
This patch supports 29bit address mode only.
Signed-off-by: Yoshihiro Shimoda <shimoda.yoshihiro@renesas.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This patch adds basic support for the SH7763RDP board.
This supports a basic stuff provided in SH7763, like SCIF,
NOR Flash and USB host.
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu.nobuhiro@renesas.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This board is SH7723 base board.
This has SCIF, LCDC, USB Host controler, NOR/NAND Flash, Sound,
Ether and other.
This patch supports SCIF, NOR Flash.
Signed-off-by: Yusuke Goda <goda.yusuke@renesas.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Presently the --fdpic specifier and the --isa matching clash when
building with FDPIC toolchains. As we have no interest in building the
kernel with --fdpic in the first place, always try to add in -mno-fdpic
to the default flags.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
SH_MPC1211 has been marked as BROKEN for some time.
Unless someone is working on reviving it now, I'd therefore suggest this
patch to remove it.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Add support for Solution Engine SH7721 board(MS7721RP01).
Signed-off-by: Yoshihiro Shimoda <shimoda.yoshihiro@renesas.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
When building the kernel without passing the O= command line parameter
there's no point to use absolute paths for them.
Usually relative paths are preferred because they survive directory
moves, work across networked file systems and chrooted environments.
Absolute paths are still used if an output directory is given.
Signed-off-by: Franck Bui-Huu <fbuihuu@gmail.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
The only board-specific bits that existed here were for setting up the
IRQs, which are now handled by the SH7710 CPU support code instead. As
there's nothing else to do for setup, kill off the board support code
and have the defconfig use the generic machvec instead.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This patch adds basic support for the Migo-R board.
Only simple stuff provided by the cpu specific sh7722 code is in place now,
like serial console port, timers and usb gadget. There is also partial support
for the smc91c111 ethernet controller - unfortunately some driver header file
also needs patching (not included here) to make the driver get IRQ sense
information from the platform data.
Signed-off-by: Magnus Damm <damm@igel.co.jp>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Add support for Renesas Technology Europe SDK7780 board.
Signed-off-by: Nicholas Beck <nbeck@mpc-data.co.uk>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Some of Sam's new work in the kbuild queue depend on ## concatenation
within the linker script, which doesn't work when -traditional is
enabled. -traditional is a legacy remnant anyways, and we no longer
require it for anything, so kill it off completely.
Noted-by: Andreas Schwab <schwab@suse.de>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This patch removes redundant irq handling code together with unused
consistent alloc code. R2D uart setup code is changed to use
sm501-regs.h and unused header files are removed.
Signed-off-by: Magnus Damm <damm@igel.co.jp>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This was using the absolute path, which was confusing the make target.
Switch it to just 'zImage', as per powerpc.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
