OpenE2K/linux
6
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
fb14921862
linux/arch/m68k/Makefile_no

125 lines
4.0 KiB
Plaintext
Raw Normal View History

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-17 00:20:36 +02:00
#
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-22 04:39:27 +01:00
# arch/m68k/Makefile
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-17 00:20:36 +02:00
#
# This file is subject to the terms and conditions of the GNU General Public
# License. See the file "COPYING" in the main directory of this archive
# for more details.
#
# (C) Copyright 2002, Greg Ungerer <gerg@snapgear.com>
#
platform-$(CONFIG_M68328) := 68328
platform-$(CONFIG_M68EZ328) := 68EZ328
platform-$(CONFIG_M68VZ328) := 68VZ328
platform-$(CONFIG_M68360) := 68360
platform-$(CONFIG_M5206) := 5206
platform-$(CONFIG_M5206e) := 5206e
[PATCH] m68knommu: add ColdFire 5208 and M5208EVB build support Add build support for the new Freescale 5208 ColdFire processor, and its M5208EVB eval board. Patch originally from Matt Waddel. Signed-off-by: Greg Ungerer <gerg@uclinux.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-07 05:09:50 +01:00
platform-$(CONFIG_M520x) := 520x
[PATCH] m68knommu: 523x ColdFire processor support in arch Makefile Add support for the 523x ColdFire family of processors Signed-off-by: Greg Ungerer <gerg@uclinux.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-02 02:42:52 +02:00
platform-$(CONFIG_M523x) := 523x
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-17 00:20:36 +02:00
platform-$(CONFIG_M5249) := 5249
platform-$(CONFIG_M527x) := 527x
platform-$(CONFIG_M5272) := 5272
platform-$(CONFIG_M528x) := 528x
platform-$(CONFIG_M5307) := 5307
[PATCH] m68knommu: build support for the Freescale 532x CPU family Add build support for the M523x ColdFire CPU family. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-27 04:50:53 +02:00
platform-$(CONFIG_M532x) := 532x
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-17 00:20:36 +02:00
platform-$(CONFIG_M5407) := 5407
m68knommu: make Coldfire 548x support more generic The ColdFire 547x family of processors is very similar to the ColdFire 548x series. Almost all of the support for them is the same. Make the code supporting the 548x more gneric, so it will be capable of supporting both families. For the most part this is a renaming excerise to make the support code more obviously apply to both families. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2010-11-02 03:05:29 +01:00
platform-$(CONFIG_M54xx) := 54xx
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-17 00:20:36 +02:00
PLATFORM := $(platform-y)
board-$(CONFIG_PILOT) := pilot
m68knommu: add build support for more Arcturus boards Add build support for the new Arcturus boards. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-25 14:07:20 +02:00
board-$(CONFIG_UC5272) := UC5272
board-$(CONFIG_UC5282) := UC5282
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-17 00:20:36 +02:00
board-$(CONFIG_UCSIMM) := ucsimm
board-$(CONFIG_UCDIMM) := ucdimm
board-$(CONFIG_UCQUICC) := uCquicc
board-$(CONFIG_DRAGEN2) := de2
board-$(CONFIG_ARNEWSH) := ARNEWSH
[PATCH] m68knommu: add ColdFire 5208 and M5208EVB build support Add build support for the new Freescale 5208 ColdFire processor, and its M5208EVB eval board. Patch originally from Matt Waddel. Signed-off-by: Greg Ungerer <gerg@uclinux.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-07 05:09:50 +01:00
board-$(CONFIG_FREESCALE) := FREESCALE
[PATCH] m68knommu: 523x ColdFire processor support in arch Makefile Add support for the 523x ColdFire family of processors Signed-off-by: Greg Ungerer <gerg@uclinux.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-02 02:42:52 +02:00
board-$(CONFIG_M5235EVB) := M5235EVB
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-17 00:20:36 +02:00
board-$(CONFIG_M5271EVB) := M5271EVB
board-$(CONFIG_M5275EVB) := M5275EVB
board-$(CONFIG_M5282EVB) := M5282EVB
board-$(CONFIG_ELITE) := eLITE
board-$(CONFIG_NETtel) := NETtel
board-$(CONFIG_SECUREEDGEMP3) := MP3
board-$(CONFIG_CLEOPATRA) := CLEOPATRA
board-$(CONFIG_senTec) := senTec
board-$(CONFIG_SNEHA) := SNEHA
[PATCH] m68knommu: add ColdFire 5208 and M5208EVB build support Add build support for the new Freescale 5208 ColdFire processor, and its M5208EVB eval board. Patch originally from Matt Waddel. Signed-off-by: Greg Ungerer <gerg@uclinux.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-07 05:09:50 +01:00
board-$(CONFIG_M5208EVB) := M5208EVB
[PATCH] m68knommu: 523x ColdFire processor support in arch Makefile Add support for the 523x ColdFire family of processors Signed-off-by: Greg Ungerer <gerg@uclinux.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-02 02:42:52 +02:00
board-$(CONFIG_MOD5272) := MOD5272
[PATCH] m68knommu: build support for the Avnet/5282 board Add support for the Avnet/5282 board. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-27 04:49:11 +02:00
board-$(CONFIG_AVNET) := AVNET
m68knommu: add make support for Savant/Rosie1 board Add make support for the Savant/Rosie1 board. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-23 06:37:54 +02:00
board-$(CONFIG_SAVANT) := SAVANT
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-17 00:20:36 +02:00
BOARD := $(board-y)
model-$(CONFIG_RAMKERNEL) := ram
model-$(CONFIG_ROMKERNEL) := rom
MODEL := $(model-y)
#
# Some code support is grouped together for a common cpu-subclass (for
# example all ColdFire cpu's are very similar). Determine the sub-class
# for the selected cpu. ONLY need to define this for the non-base member
# of the family.
#
m68knommu: modify Makefiles to support common coldfire directory Modify Makefiles to support separate coldfire platform directory. Currently the common ColdFire CPU family code sits in the arch/m68knommu/platform/5307 directory. This is confusing, the files containing this common code are in no way specific to the 5307 ColdFire. Create an arch/m68knommu/platform/coldfire directory to contain this common code. Other m68knommu CPU varients do not need use this code though, so it doesn't make sense to move it to arch/m68knommu/kernel. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-01 08:37:56 +01:00
cpuclass-$(CONFIG_M5206) := coldfire
cpuclass-$(CONFIG_M5206e) := coldfire
cpuclass-$(CONFIG_M520x) := coldfire
cpuclass-$(CONFIG_M523x) := coldfire
cpuclass-$(CONFIG_M5249) := coldfire
cpuclass-$(CONFIG_M527x) := coldfire
cpuclass-$(CONFIG_M5272) := coldfire
cpuclass-$(CONFIG_M528x) := coldfire
cpuclass-$(CONFIG_M5307) := coldfire
cpuclass-$(CONFIG_M532x) := coldfire
cpuclass-$(CONFIG_M5407) := coldfire
m68knommu: make Coldfire 548x support more generic The ColdFire 547x family of processors is very similar to the ColdFire 548x series. Almost all of the support for them is the same. Make the code supporting the 548x more gneric, so it will be capable of supporting both families. For the most part this is a renaming excerise to make the support code more obviously apply to both families. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2010-11-02 03:05:29 +01:00
cpuclass-$(CONFIG_M54xx) := coldfire
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-17 00:20:36 +02:00
cpuclass-$(CONFIG_M68328) := 68328
cpuclass-$(CONFIG_M68EZ328) := 68328
cpuclass-$(CONFIG_M68VZ328) := 68328
cpuclass-$(CONFIG_M68360) := 68360
CPUCLASS := $(cpuclass-y)
ifneq ($(CPUCLASS),$(PLATFORM))
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-22 04:39:27 +01:00
CLASSDIR := arch/m68k/platform/$(cpuclass-y)/
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-17 00:20:36 +02:00
endif
export PLATFORM BOARD MODEL CPUCLASS
#
# Some CFLAG additions based on specific CPU type.
#
m68knommu: improve compile arch switch settings Modern versions of gcc have a better range of ColdFire optimization switches for the vairous ColdFire family members. Use these when we can. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2009-03-30 02:29:45 +02:00
cflags-$(CONFIG_M5206) := $(call cc-option,-mcpu=5206,-m5200)
m68knommu: switch to using -mcpu= flags for ColdFire targets Gcc has deprecated the use of the following ColdFire cpu options: -m5206e, -m528x, -m5307 and -m5407. In there place we should use the equivilent -mcpu= option and setting. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2010-11-18 03:52:08 +01:00
cflags-$(CONFIG_M5206e) := $(call cc-option,-mcpu=5206e,-m5200)
m68knommu: improve compile arch switch settings Modern versions of gcc have a better range of ColdFire optimization switches for the vairous ColdFire family members. Use these when we can. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2009-03-30 02:29:45 +02:00
cflags-$(CONFIG_M520x) := $(call cc-option,-mcpu=5208,-m5200)
m68knommu: add ffs and __ffs plattform which support ISA A+ or ISA C the ff1 and bitrev opcode appears in ISA C and ISA A+ what isn't supported by all plattforms. The assembly optimization is automaticly enabled if the compiler understand the required cpu keyword. My m5235 seems to boot and run fine so far. Signed-off-by: Sebastian Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2008-05-09 16:10:37 +02:00
cflags-$(CONFIG_M523x) := $(call cc-option,-mcpu=523x,-m5307)
m68knommu: improve compile arch switch settings Modern versions of gcc have a better range of ColdFire optimization switches for the vairous ColdFire family members. Use these when we can. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2009-03-30 02:29:45 +02:00
cflags-$(CONFIG_M5249) := $(call cc-option,-mcpu=5249,-m5200)
m68knommu: add ffs and __ffs plattform which support ISA A+ or ISA C the ff1 and bitrev opcode appears in ISA C and ISA A+ what isn't supported by all plattforms. The assembly optimization is automaticly enabled if the compiler understand the required cpu keyword. My m5235 seems to boot and run fine so far. Signed-off-by: Sebastian Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2008-05-09 16:10:37 +02:00
cflags-$(CONFIG_M5271) := $(call cc-option,-mcpu=5271,-m5307)
m68knommu: correct the CC flags for Coldfire M5272 targets Signed-off-by: Philip Nye <philipn@engarts.com> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2010-01-12 01:18:03 +01:00
cflags-$(CONFIG_M5272) := $(call cc-option,-mcpu=5272,-m5307)
m68knommu: add ffs and __ffs plattform which support ISA A+ or ISA C the ff1 and bitrev opcode appears in ISA C and ISA A+ what isn't supported by all plattforms. The assembly optimization is automaticly enabled if the compiler understand the required cpu keyword. My m5235 seems to boot and run fine so far. Signed-off-by: Sebastian Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2008-05-09 16:10:37 +02:00
cflags-$(CONFIG_M5275) := $(call cc-option,-mcpu=5275,-m5307)
m68knommu: switch to using -mcpu= flags for ColdFire targets Gcc has deprecated the use of the following ColdFire cpu options: -m5206e, -m528x, -m5307 and -m5407. In there place we should use the equivilent -mcpu= option and setting. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2010-11-18 03:52:08 +01:00
cflags-$(CONFIG_M528x) := $(call cc-option,-mcpu=528x,-m5307)
cflags-$(CONFIG_M5307) := $(call cc-option,-mcpu=5307,-m5200)
m68knommu: add ffs and __ffs plattform which support ISA A+ or ISA C the ff1 and bitrev opcode appears in ISA C and ISA A+ what isn't supported by all plattforms. The assembly optimization is automaticly enabled if the compiler understand the required cpu keyword. My m5235 seems to boot and run fine so far. Signed-off-by: Sebastian Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2008-05-09 16:10:37 +02:00
cflags-$(CONFIG_M532x) := $(call cc-option,-mcpu=532x,-m5307)
m68knommu: switch to using -mcpu= flags for ColdFire targets Gcc has deprecated the use of the following ColdFire cpu options: -m5206e, -m528x, -m5307 and -m5407. In there place we should use the equivilent -mcpu= option and setting. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2010-11-18 03:52:08 +01:00
cflags-$(CONFIG_M5407) := $(call cc-option,-mcpu=5407,-m5200)
cflags-$(CONFIG_M54xx) := $(call cc-option,-mcpu=5475,-m5200)
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-17 00:20:36 +02:00
cflags-$(CONFIG_M68328) := -m68000
cflags-$(CONFIG_M68EZ328) := -m68000
cflags-$(CONFIG_M68VZ328) := -m68000
cflags-$(CONFIG_M68360) := -m68332
kbuild: enable 'make AFLAGS=...' to add additional options to AS The variable AFLAGS 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 AFLAGS with KBUILD_AFLAGS all over the tree. Patch was tested on following architectures: alpha, arm, i386, x86_64, mips, sparc, sparc64, ia64, m68k, s390 Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2007-10-15 21:59:31 +02:00
KBUILD_AFLAGS += $(cflags-y)
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-17 00:20:36 +02:00
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
KBUILD_CFLAGS += $(cflags-y)
KBUILD_CFLAGS += -D__linux__
KBUILD_CFLAGS += -DUTS_SYSNAME=\"uClinux\"
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-17 00:20:36 +02:00
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-22 04:39:27 +01:00
head-y := arch/m68k/platform/$(cpuclass-y)/head.o
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-17 00:20:36 +02:00
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-22 04:39:27 +01:00
core-y += arch/m68k/kernel/ \
arch/m68k/mm/ \
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-17 00:20:36 +02:00
$(CLASSDIR) \
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-22 04:39:27 +01:00
arch/m68k/platform/$(PLATFORM)/
libs-y += arch/m68k/lib/
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-17 00:20:36 +02:00
archclean:
m68knommu: fix make archclean Remove build reference to arch/m68knommu/boot directory, it doesn't exist. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-23 06:37:54 +02:00
Reference in New Issue Copy Permalink