This code has been untouched since it was merged many years ago, and has
severely bitrotted since, suggesting that the board has no real users
left. Notice of intent to remove has been sent out over the last few
years, with no takers. Kill it off.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Only the secureedge5410 was ever supported by this code, so make the
board specification explicit rather than perpetuating a mach group.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Now that compressed image loading is possible for sdk7786, drop the
vmlinux.bin default image target and update the defconfig accordingly.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Nothing is using this, kill it off. Fixing up access sizes can be done
with trapped I/O for anyone wanting to make use of this for devices that
need it, everything else is already pure MMIO.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This stubs in some preliminary board support for the RTE SDK7786.
This is quite stunted at the moment, and primarily builds on top of the
system FPGA. FPGA IRQs are handled via CPU IRL masking for simplicity,
with initial peripheral support restricted to the debug ethernet.
Signed-off-by: Matt Fleming <matt@console-pimps.org>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This makes vmlinux.bin generation an explicit make target, as opposed to
just a dependency for some of the other targets.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Move the AP325RXA board code from a single board file
to a separate directory. This to make it easy to add
support for sdram sleep mode code.
Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Add an uImage.bin target to allow uncompressed uImages.
Useful for boards with busted u-boot decompression like
the rsk7203 on my desk.
Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This adds preliminary support for the EcoVec board.
Signed-off-by: Kuninori Morimoto <morimoto.kuninori@renesas.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This is a first cut at a generic DWARF unwinder for the kernel. It's
still lacking DWARF64 support and the DWARF expression support hasn't
been tested very well but it is generating proper stacktraces on SH for
WARN_ON() and NULL dereferences.
Signed-off-by: Matt Fleming <matt@console-pimps.org>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This patch contains support for the romImage build target V2.
The resulting romImage file should be burned to rom
or flash and could be used as small boot loader.
Board code should keep their setup code in the file
romimage.h located in their mach include directory.
Signed-off-by: Magnus Damm <damm@igel.co.jp>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This patch adds basic kfr2r09 board support. Only
the SCIF1 console is supported with this patch, but
this patch and a proper sh7724 configuration is all
that is needed. Combine with an initramfs to have a
small RAM based kernel and distribution booted as
zImage from RAM via JTAG.
Signed-off-by: Magnus Damm <damm@igel.co.jp>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This builds on the bzip2/lzma zImage support change and wires it up for
uImages. Based on the blackfin implementation.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This adds a general CONFIG_MCOUNT in order to permit mcount generation
without ftrace support. This is primarily for allowing platforms to
enable aggressive stack overflow checking without having to enable ftrace
support. Based on the sparc64 implementation.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
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>
