Commit graph

28 commits

Author SHA1 Message Date
Steven King
bea8bcb12d m68knommu: Add support for the Coldfire m5441x.
Add support for the Coldfire 5441x (54410/54415/54416/54417/54418).  Currently
we only support noMMU mode.  It requires the PIT patch posted previously as it
uses the PIT instead of the dma timer as a clock source so we can get all that
GENERIC_CLOCKEVENTS goodness.  It also adds some simple clk definitions and
very simple minded power management.  The gpio code is tweeked and some
additional devices are added to devices.c.  The Makefile uses -mv4e as
apparently, the only difference a v4m (m5441x) and a v4e is the later has a
FPU, which I don't think should matter to us in the kernel.

Signed-off-by: Steven King <sfking@fdwdc.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-07-16 09:59:21 +10:00
Steven King
04e037aa4e m68knommu: Add support for the Coldfire 5251/5253
Basic support for the Coldfire 5251/5253.

Signed-off-by: Steven king <sfking@fdwdc.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-07-16 09:59:21 +10:00
Linus Torvalds
06930b94d1 Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu
Pull m68knommu tree from Greg Ungerer:
 "More merge and clean up of MMU and non-MMU common files, namely
  signal.c and dma.c.  There is also a simplification of the ColdFire
  GPIO setup tables.  Using a couple of simple macros we make the init
  tables really small and easy to read, and save a couple of thousand
  lines of code.  Also a move of all the ColdFire subarch support files
  into the existing coldfire directory.  The sub-directories just ended
  up duplicating Makefiles and now only contain really simple pieces of
  code.  This saves quite a few lines of code too.

  As always a couple of bugs fixes thrown in too.  Oh and a new
  defconfig for the ColdFire platforms that support having the MMU
  enabled."

* 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu: (39 commits)
  m68k: add a defconfig for the M5475EVB ColdFire with MMU board
  m68knommu: unaligned.h fix for M68000 core
  m68k: merge the MMU and non-MMU versions of the arch dma code
  m68knommu: reorganize the no-MMU cache flushing to match m68k
  m68knommu: move the 54xx platform code into the common ColdFire code directory
  m68knommu: move the 532x platform code into the common ColdFire code directory
  m68knommu: move the 5407 platform code into the common ColdFire code directory
  m68knommu: move the 5307 platform code into the common ColdFire code directory
  m68knommu: move the 528x platform code into the common ColdFire code directory
  m68knommu: move the 527x platform code into the common ColdFire code directory
  m68knommu: move the 5272 platform code into the common ColdFire code directory
  m68knommu: move the 5249 platform code into the common ColdFire code directory
  m68knommu: move the 523x platform code into the common ColdFire code directory
  m68knommu: move the 520x platform code into the common ColdFire code directory
  m68knommu: move the 5206 platform code into the common ColdFire code directory
  m68knommu: simplify the ColdFire 5407 GPIO struct setup
  m68knommu: simplify the ColdFire 532x GPIO struct setup
  m68knommu: simplify the ColdFire 5307 GPIO struct setup
  m68knommu: simplify the ColdFire 528x GPIO struct setup
  m68knommu: simplify the ColdFire 527x GPIO struct setup
  ...
2012-05-21 19:15:03 -07:00
Greg Ungerer
453549d2e5 m68knommu: move the 54xx platform code into the common ColdFire code directory
All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-20 21:22:07 +10:00
Greg Ungerer
e33e73f560 m68knommu: move the 532x platform code into the common ColdFire code directory
All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-20 21:22:06 +10:00
Greg Ungerer
9f8c8c072d m68knommu: move the 5407 platform code into the common ColdFire code directory
All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-20 21:22:05 +10:00
Greg Ungerer
136f148f61 m68knommu: move the 5307 platform code into the common ColdFire code directory
All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-20 21:22:04 +10:00
Greg Ungerer
76148ab8b7 m68knommu: move the 528x platform code into the common ColdFire code directory
All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-20 21:22:04 +10:00
Greg Ungerer
60fb32ca61 m68knommu: move the 527x platform code into the common ColdFire code directory
All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-20 21:22:03 +10:00
Greg Ungerer
40711ccb22 m68knommu: move the 5272 platform code into the common ColdFire code directory
All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-20 21:22:02 +10:00
Greg Ungerer
2d11251168 m68knommu: move the 5249 platform code into the common ColdFire code directory
All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-20 21:22:01 +10:00
Greg Ungerer
4bf648fa98 m68knommu: move the 523x platform code into the common ColdFire code directory
All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-20 21:22:00 +10:00
Greg Ungerer
a654730ec1 m68knommu: move the 520x platform code into the common ColdFire code directory
All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-20 21:21:59 +10:00
Greg Ungerer
daacd5cc25 m68knommu: move the 5206 platform code into the common ColdFire code directory
All these separate directories for each ColdFire CPU SoC varient seems like
overkill. The majority of them only contain a single small config file. Move
these into the common ColdFire code directory.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2012-05-20 21:21:58 +10:00
Geert Uytterhoeven
f25e918e35 m68k: Setup CROSS_COMPILE at the top
CROSS_COMPILE must be setup before using e.g. cc-option (and a few other
as-*, cc-*, ld-* macros), else they will check against the wrong compiler
when cross-compiling, and may invoke the cross compiler with wrong or
suboptimal compiler options.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Greg Ungerer<gerg@uclinux.org>
2012-05-16 14:02:04 +02:00
Greg Ungerer
281eff5322 m68k: merge mmu and non-mmu arch Makefiles
Most of the build logic is the same for the mmu and non-mmu m68k targets.
Merge the top level architecture Makefiles back into a single Makefile.

For the most part this is just adding the non-mmu processor types and
their specific cflags and other options into the mmu Makefile.

Note that all the BOARD setting logic that was in the non-mmu Makefile
is completely removed. It was no longer being used at all.

This has been build and run tested on ColdFire targets and ARAnyM.
It has been build tested on all the m68k defconfig targets using a
gcc-4.5.1 based toolchain.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
2011-10-18 14:22:25 +10:00
Greg Ungerer
66d857b08b m68k: merge m68k and m68knommu arch directories
There is a lot of common code that could be shared between the m68k
and m68knommu arch branches. It makes sense to merge the two branches
into a single directory structure so that we can more easily share
that common code.

This is a brute force merge, based on a script from Stephen King
<sfking@fdwdc.com>, which was originally written by Arnd Bergmann
<arnd@arndb.de>.

> The script was inspired by the script Sam Ravnborg used to merge the
> includes from m68knommu. For those files common to both arches but
> differing in content, the m68k version of the file is renamed to
> <file>_mm.<ext> and the m68knommu version of the file is moved into the
> corresponding m68k directory and renamed <file>_no.<ext> and a small
> wrapper file <file>.<ext> is used to select between the two version. Files
> that are common to both but don't differ are removed from the m68knommu
> tree and files and directories that are unique to the m68knommu tree are
> moved to the m68k tree. Finally, the arch/m68knommu tree is removed.
>
> To select between the the versions of the files, the wrapper uses
>
> #ifdef CONFIG_MMU
> #include <file>_mm.<ext>
> #else
> #include <file>_no.<ext>
> #endif

On top of this file merge I have done a simplistic merge of m68k and
m68knommu Kconfig, which primarily attempts to keep existing options and
menus in place. Other than a handful of options being moved it produces
identical .config outputs on m68k and m68knommu targets I tested it on.

With this in place there is now quite a bit of scope for merge cleanups
in future patches.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2011-03-25 14:05:13 +10:00
Petr Stehlik
65cd577d5e m68k/atari: Initial ARAnyM support
Add improved support for running under the ARAnyM emulator
(Atari Running on Any Machine - http://aranym.org/).

[michael, geert: Cleanups and updates]

Signed-off-by: Petr Stehlik <pstehlik@sophics.cz>
Signed-off-by: Michael Schmitz <schmitz@debian.org>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2011-03-16 19:10:41 +01:00
Sam Ravnborg
6588169d51 kbuild: allow assignment to {A,C,LD}FLAGS_MODULE on the command line
It is now possible to assign options to AS, CC and LD
on the command line - which is only used when building modules.

{A,C,LD}FLAGS_MODULE was all used both in the top-level Makefile
in the arch makefiles, thus users had no way to specify
additional options to AS, CC, LD when building modules
without overriding the original value.

Introduce a new set of variables KBUILD_{A,C,LD}FLAGS_MODULE
that is used by arch specific files and free up
{A,C,LD}FLAGS_MODULE so they can be assigned on
the command line.

All arch Makefiles that used the old variables has been updated.

Note: Previously we had a MODFLAGS variable for both
AS and CC. But in favour of consistency this was dropped.
So in some cases arch Makefile has one assignmnet replaced by
two assignmnets.

Note2: MODFLAGS was not documented and is dropped
without any notice. I do not expect much/any breakage
from this.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Denys Vlasenko <vda.linux@googlemail.com>
Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Chen Liqin <liqin.chen@sunplusct.com>
Acked-by: Mike Frysinger <vapier@gentoo.org> [blackfin]
Acked-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com> [avr32]
Signed-off-by: Michal Marek <mmarek@suse.cz>
2010-08-03 14:09:45 +02:00
Laurent Vivier
612bfc9e63 m68k: Add install target
This patch enables the use of "make install" on m68k architecture
to copy kernel to /boot.

Signed-off-by: Laurent Vivier <Laurent@lvivier.info>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2009-03-26 21:15:26 +01:00
Adrian Bunk
b739912efc m68k: make multi_defconfig the default defconfig
It seems to match the intention behind multi_defconfig to make it the
default defconfig.

Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-07-20 17:24:38 -07:00
Adrian Bunk
ef85ecbf11 m68k: use KBUILD_DEFCONFIG
The default defconfig should be one from arch/m68k/configs/

arch/m68k/defconfig was not exactly identical to amiga_defconfig but
also considering how long they have been without any update that doesn't
seem to have been on purpose.

Signed-off-by: Adrian Bunk <adrian.bunk@movial.fi>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-04 14:42:20 -07:00
Geert Uytterhoeven
6f7127db31 m68k: Use cc-cross-prefix
The cc-cross-prefix is new and developed on request from Geert Uytterhoeven.

With cc-cross-prefix it is now much easier to have a few default cross compile
prefixes and defaulting to none - if none of them were present.  ARCH
maintainers are expected to pick up this feature soon.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Andreas Schwab <schwab@suse.de>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-05 09:44:23 -08:00
Sam Ravnborg
a0f97e06a4 kbuild: enable 'make CFLAGS=...' to add additional options to CC
The variable CFLAGS is a wellknown variable and the usage by
kbuild may result in unexpected behaviour.
On top of that several people over time has asked for a way to
pass in additional flags to gcc.

This patch replace use of CFLAGS with KBUILD_CFLAGS all over the
tree and enabling one to use:
make CFLAGS=...
to specify additional gcc commandline options.

One usecase is when trying to find gcc bugs but other
use cases has been requested too.

Patch was tested on following architectures:
alpha, arm, i386, x86_64, mips, sparc, sparc64, ia64, m68k

Test was simple to do a defconfig build, apply the patch and check
that nothing got rebuild.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2007-10-14 22:21:35 +02:00
Roman Zippel
fbe9c96129 m68k: runtime patching infrastructure
Add the basic infrastructure to allow runtime patching of kernel and modules
to optimize a few functions with parameters, which are only calculated once
during bootup and are otherwise constant.  Use this for the conversion between
virtual and physical addresses.

Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-31 07:58:13 -07:00
Geert Uytterhoeven
ec0203e753 m68k: CROSS_COMPILE = m68k-linux-gnu-
Recent cross-compilers are called m68k-linux-gnu-gcc instead of m68k-linux-gcc

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-04 17:59:05 -07:00
Sam Ravnborg
0013a85454 kbuild: m68k,parisc,ppc,ppc64,s390,xtensa use generic asm-offsets.h support
Delete obsoleted parts form arch makefiles and rename to asm-offsets.h

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2005-09-09 20:57:26 +02:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00