hollalinux
/
linux-sg2042
mirror of https://github.com/sophgo/linux-riscv.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
linux-sg2042/arch/m68k/Kconfig.machine

451 lines
12 KiB
Plaintext
Raw Normal View History

m68k: reorganize Kconfig options to improve mmu/non-mmu selections The current mmu and non-mmu Kconfig files can be merged to form a more general selection of options. The current break up of options is due to the simple brute force merge from the m68k and m68knommu arch directories. Many of the options are not at all specific to having the MMU enabled or not. They are actually associated with a particular CPU type or platform type. Ultimately as we support all processors with the MMU disabled we need many of these options to be selectable without the MMU option enabled. And likewise some of the ColdFire processors, which currently are only supported with the MMU disabled, do have MMU hardware, and will need to have options selected on CPU type, not MMU disabled. This patch removes the old mmu and non-mmu Kconfigs and instead breaks up the configuration into four areas: cpu, machine, bus, devices. The Kconfig.cpu lists all the options associated with selecting a CPU, and includes options specific to each CPU type as well. Kconfig.machine lists all options associated with selecting a machine type. Almost always the machines selectable is restricted by the chosen CPU. Kconfig.bus contains options associated with selecting bus types on the various machine types. That includes PCI bus, PCMCIA bus, etc. Kconfig.devices contains options for drivers and driver associated options. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2011-06-20 13:49:09 +08:00
comment "Machine Types"
m68k/Kconfig: Separate classic m68k and coldfire early While you can build multiplatform kernels for machines with classic m68k processors, you cannot mix support for classic m68k and coldfire processors. To avoid such hybrid kernels, introduce CONFIG_M68KCLASSIC as an antipole for CONFIG_COLDFIRE, and make all specific processor support depend on one of them. All classic m68k machine support also needs to depend on this. The defaults (CONFIG_M68KCLASSIC if MMU, CONFIG_COLDFIRE if !MMU) are chosen such to make most of the existing configs build and work. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2011-12-27 03:32:02 +08:00
if M68KCLASSIC
m68k: reorganize Kconfig options to improve mmu/non-mmu selections The current mmu and non-mmu Kconfig files can be merged to form a more general selection of options. The current break up of options is due to the simple brute force merge from the m68k and m68knommu arch directories. Many of the options are not at all specific to having the MMU enabled or not. They are actually associated with a particular CPU type or platform type. Ultimately as we support all processors with the MMU disabled we need many of these options to be selectable without the MMU option enabled. And likewise some of the ColdFire processors, which currently are only supported with the MMU disabled, do have MMU hardware, and will need to have options selected on CPU type, not MMU disabled. This patch removes the old mmu and non-mmu Kconfigs and instead breaks up the configuration into four areas: cpu, machine, bus, devices. The Kconfig.cpu lists all the options associated with selecting a CPU, and includes options specific to each CPU type as well. Kconfig.machine lists all options associated with selecting a machine type. Almost always the machines selectable is restricted by the chosen CPU. Kconfig.bus contains options associated with selecting bus types on the various machine types. That includes PCI bus, PCMCIA bus, etc. Kconfig.devices contains options for drivers and driver associated options. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2011-06-20 13:49:09 +08:00
config AMIGA
bool "Amiga support"
depends on MMU
select MMU_MOTOROLA if MMU
help
This option enables support for the Amiga series of computers. If
you plan to use this kernel on an Amiga, say Y here and browse the
material available in <file:Documentation/m68k>; otherwise say N.
config ATARI
bool "Atari support"
depends on MMU
select MMU_MOTOROLA if MMU
help
This option enables support for the 68000-based Atari series of
computers (including the TT, Falcon and Medusa). If you plan to use
this kernel on an Atari, say Y here and browse the material
available in <file:Documentation/m68k>; otherwise say N.
config MAC
bool "Macintosh support"
depends on MMU
select MMU_MOTOROLA if MMU
help
This option enables support for the Apple Macintosh series of
computers (yes, there is experimental support now, at least for part
of the series).
Say N unless you're willing to code the remaining necessary support.
;)
config APOLLO
bool "Apollo support"
depends on MMU
select MMU_MOTOROLA if MMU
help
Say Y here if you want to run Linux on an MC680x0-based Apollo
Domain workstation such as the DN3500.
config VME
bool "VME (Motorola and BVM) support"
depends on MMU
select MMU_MOTOROLA if MMU
help
Say Y here if you want to build a kernel for a 680x0 based VME
board. Boards currently supported include Motorola boards MVME147,
MVME162, MVME166, MVME167, MVME172, and MVME177. BVME4000 and
BVME6000 boards from BVM Ltd are also supported.
config MVME147
bool "MVME147 support"
depends on MMU
depends on VME
help
Say Y to include support for early Motorola VME boards. This will
build a kernel which can run on MVME147 single-board computers. If
you select this option you will have to select the appropriate
drivers for SCSI, Ethernet and serial ports later on.
config MVME16x
bool "MVME162, 166 and 167 support"
depends on MMU
depends on VME
help
Say Y to include support for Motorola VME boards. This will build a
kernel which can run on MVME162, MVME166, MVME167, MVME172, and
MVME177 boards. If you select this option you will have to select
the appropriate drivers for SCSI, Ethernet and serial ports later
on.
config BVME6000
bool "BVME4000 and BVME6000 support"
depends on MMU
depends on VME
help
Say Y to include support for VME boards from BVM Ltd. This will
build a kernel which can run on BVME4000 and BVME6000 boards. If
you select this option you will have to select the appropriate
drivers for SCSI, Ethernet and serial ports later on.
config HP300
bool "HP9000/300 and HP9000/400 support"
depends on MMU
select MMU_MOTOROLA if MMU
help
This option enables support for the HP9000/300 and HP9000/400 series
of workstations. Support for these machines is still somewhat
experimental. If you plan to try to use the kernel on such a machine
say Y here.
Everybody else says N.
config SUN3X
bool "Sun3x support"
depends on MMU
select MMU_MOTOROLA if MMU
select M68030
help
This option enables support for the Sun 3x series of workstations.
Be warned that this support is very experimental.
Note that Sun 3x kernels are not compatible with Sun 3 hardware.
General Linux information on the Sun 3x series (now discontinued)
is at <http://www.angelfire.com/ca2/tech68k/sun3.html>.
If you don't want to compile a kernel for a Sun 3x, say N.
config Q40
bool "Q40/Q60 support"
depends on MMU
select MMU_MOTOROLA if MMU
help
The Q40 is a Motorola 68040-based successor to the Sinclair QL
manufactured in Germany. There is an official Q40 home page at
<http://www.q40.de/>. This option enables support for the Q40 and
Q60. Select your CPU below. For 68LC060 don't forget to enable FPU
emulation.
config SUN3
bool "Sun3 support"
depends on MMU
depends on !MMU_MOTOROLA
select MMU_SUN3 if MMU
select M68020
help
This option enables support for the Sun 3 series of workstations
(3/50, 3/60, 3/1xx, 3/2xx systems). Enabling this option requires
that all other hardware types must be disabled, as Sun 3 kernels
are incompatible with all other m68k targets (including Sun 3x!).
If you don't want to compile a kernel exclusively for a Sun 3, say N.
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 06:20:36 +08:00
m68k/Kconfig: Separate classic m68k and coldfire early While you can build multiplatform kernels for machines with classic m68k processors, you cannot mix support for classic m68k and coldfire processors. To avoid such hybrid kernels, introduce CONFIG_M68KCLASSIC as an antipole for CONFIG_COLDFIRE, and make all specific processor support depend on one of them. All classic m68k machine support also needs to depend on this. The defaults (CONFIG_M68KCLASSIC if MMU, CONFIG_COLDFIRE if !MMU) are chosen such to make most of the existing configs build and work. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2011-12-27 03:32:02 +08:00
endif # M68KCLASSIC
m68k: reorganize Kconfig options to improve mmu/non-mmu selections The current mmu and non-mmu Kconfig files can be merged to form a more general selection of options. The current break up of options is due to the simple brute force merge from the m68k and m68knommu arch directories. Many of the options are not at all specific to having the MMU enabled or not. They are actually associated with a particular CPU type or platform type. Ultimately as we support all processors with the MMU disabled we need many of these options to be selectable without the MMU option enabled. And likewise some of the ColdFire processors, which currently are only supported with the MMU disabled, do have MMU hardware, and will need to have options selected on CPU type, not MMU disabled. This patch removes the old mmu and non-mmu Kconfigs and instead breaks up the configuration into four areas: cpu, machine, bus, devices. The Kconfig.cpu lists all the options associated with selecting a CPU, and includes options specific to each CPU type as well. Kconfig.machine lists all options associated with selecting a machine type. Almost always the machines selectable is restricted by the chosen CPU. Kconfig.bus contains options associated with selecting bus types on the various machine types. That includes PCI bus, PCMCIA bus, etc. Kconfig.devices contains options for drivers and driver associated options. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2011-06-20 13:49:09 +08:00
config PILOT
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 10:05:29 +08:00
bool
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 06:20:36 +08:00
config PILOT3
bool "Pilot 1000/5000, PalmPilot Personal/Pro, or PalmIII support"
depends on M68328
m68k: reorganize Kconfig options to improve mmu/non-mmu selections The current mmu and non-mmu Kconfig files can be merged to form a more general selection of options. The current break up of options is due to the simple brute force merge from the m68k and m68knommu arch directories. Many of the options are not at all specific to having the MMU enabled or not. They are actually associated with a particular CPU type or platform type. Ultimately as we support all processors with the MMU disabled we need many of these options to be selectable without the MMU option enabled. And likewise some of the ColdFire processors, which currently are only supported with the MMU disabled, do have MMU hardware, and will need to have options selected on CPU type, not MMU disabled. This patch removes the old mmu and non-mmu Kconfigs and instead breaks up the configuration into four areas: cpu, machine, bus, devices. The Kconfig.cpu lists all the options associated with selecting a CPU, and includes options specific to each CPU type as well. Kconfig.machine lists all options associated with selecting a machine type. Almost always the machines selectable is restricted by the chosen CPU. Kconfig.bus contains options associated with selecting bus types on the various machine types. That includes PCI bus, PCMCIA bus, etc. Kconfig.devices contains options for drivers and driver associated options. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2011-06-20 13:49:09 +08:00
select PILOT
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 06:20:36 +08:00
help
Support for the Palm Pilot 1000/5000, Personal/Pro and PalmIII.
config XCOPILOT_BUGS
[PATCH] m68knommu: formatting cleanup in Kconfig Formatting and a spelling cleanup in m68knommu Kconfig. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-04 14:40:58 +08:00
bool "(X)Copilot support"
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 06:20:36 +08:00
depends on PILOT3
help
Support the bugs of Xcopilot.
config UCSIMM
bool "uCsimm module support"
depends on M68EZ328
help
Support for the Arcturus Networks uCsimm module.
config UCDIMM
bool "uDsimm module support"
depends on M68VZ328
help
Support for the Arcturus Networks uDsimm module.
config DRAGEN2
bool "DragenEngine II board support"
depends on M68VZ328
help
Support for the DragenEngine II board.
config DIRECT_IO_ACCESS
[PATCH] m68knommu: formatting cleanup in Kconfig Formatting and a spelling cleanup in m68knommu Kconfig. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-04 14:40:58 +08:00
bool "Allow user to access IO directly"
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 06:20:36 +08:00
depends on (UCSIMM || UCDIMM || DRAGEN2)
help
Disable the CPU internal registers protection in user mode,
m68knommu: arch/m68knommu/Kconfig whitespace cleanup Replace 8 spaces, or even 7, by TAB at begin of lines. Signed-off-by: Philippe De Muyter <phdm@macqel.be> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2010-11-12 06:57:56 +08:00
to allow a user application to read/write them.
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 06:20:36 +08:00
config INIT_LCD
[PATCH] m68knommu: formatting cleanup in Kconfig Formatting and a spelling cleanup in m68knommu Kconfig. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-04 14:40:58 +08:00
bool "Initialize LCD"
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 06:20:36 +08:00
depends on (UCSIMM || UCDIMM || DRAGEN2)
help
Initialize the LCD controller of the 68x328 processor.
config MEMORY_RESERVE
[PATCH] m68knommu: formatting cleanup in Kconfig Formatting and a spelling cleanup in m68knommu Kconfig. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-04 14:40:58 +08:00
int "Memory reservation (MiB)"
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 06:20:36 +08:00
depends on (UCSIMM || UCDIMM)
help
Reserve certain memory regions on 68x328 based boards.
config UCQUICC
bool "Lineo uCquicc board support"
depends on M68360
help
Support for the Lineo uCquicc board.
config ARN5206
bool "Arnewsh 5206 board support"
depends on M5206
help
Support for the Arnewsh 5206 board.
config M5206eC3
bool "Motorola M5206eC3 board support"
depends on M5206e
help
Support for the Motorola M5206eC3 board.
config ELITE
bool "Motorola M5206eLITE board support"
depends on M5206e
help
Support for the Motorola M5206eLITE board.
[PATCH] m68knommu: new family (523x) and board config support New architecture and board configuration support for m68knommu. . add 523x ColdFire support . add support for SOM5282 and MOD5272 boards . break up the 527x to be separate 5271 and 5275. There is some subtle differences that (like RAM config) that need to be dealt with . add option to support selecting 4k kernel stack Signed-off-by: Greg Ungerer <gerg@uclinux.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-02 08:42:52 +08:00
config M5235EVB
bool "Freescale M5235EVB support"
depends on M523x
help
Support for the Freescale M5235EVB board.
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 06:20:36 +08:00
config M5249C3
bool "Motorola M5249C3 board support"
depends on M5249
help
Support for the Motorola M5249C3 board.
config M5272C3
bool "Motorola M5272C3 board support"
depends on M5272
help
Support for the Motorola M5272C3 board.
m68knommu: add configure support for Intec boards Add configure support for the Intec Wildfire and WildFireMod boards. Signed-Off-By: Steve Bennett <steveb@workware.net.au> Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-25 20:07:20 +08:00
config WILDFIRE
bool "Intec Automation Inc. WildFire board support"
depends on M528x
help
Support for the Intec Automation Inc. WildFire.
m68k: reorganize Kconfig options to improve mmu/non-mmu selections The current mmu and non-mmu Kconfig files can be merged to form a more general selection of options. The current break up of options is due to the simple brute force merge from the m68k and m68knommu arch directories. Many of the options are not at all specific to having the MMU enabled or not. They are actually associated with a particular CPU type or platform type. Ultimately as we support all processors with the MMU disabled we need many of these options to be selectable without the MMU option enabled. And likewise some of the ColdFire processors, which currently are only supported with the MMU disabled, do have MMU hardware, and will need to have options selected on CPU type, not MMU disabled. This patch removes the old mmu and non-mmu Kconfigs and instead breaks up the configuration into four areas: cpu, machine, bus, devices. The Kconfig.cpu lists all the options associated with selecting a CPU, and includes options specific to each CPU type as well. Kconfig.machine lists all options associated with selecting a machine type. Almost always the machines selectable is restricted by the chosen CPU. Kconfig.bus contains options associated with selecting bus types on the various machine types. That includes PCI bus, PCMCIA bus, etc. Kconfig.devices contains options for drivers and driver associated options. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2011-06-20 13:49:09 +08:00
m68knommu: add configure support for Intec boards Add configure support for the Intec Wildfire and WildFireMod boards. Signed-Off-By: Steve Bennett <steveb@workware.net.au> Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-25 20:07:20 +08:00
config WILDFIREMOD
bool "Intec Automation Inc. WildFire module support"
depends on M528x
help
Support for the Intec Automation Inc. WildFire module.
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 06:20:36 +08:00
config ARN5307
bool "Arnewsh 5307 board support"
depends on M5307
help
Support for the Arnewsh 5307 board.
config M5307C3
bool "Motorola M5307C3 board support"
depends on M5307
help
Support for the Motorola M5307C3 board.
config SECUREEDGEMP3
bool "SnapGear SecureEdge/MP3 platform support"
depends on M5307
help
Support for the SnapGear SecureEdge/MP3 platform.
config M5407C3
bool "Motorola M5407C3 board support"
depends on M5407
help
Support for the Motorola M5407C3 board.
m68knommu: add basic support for the ColdFire based FireBee board The FireBee is a ColdFire 5475 based board. Add a configuration option to support it, and the basic platform flash layout code. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2011-03-06 21:20:19 +08:00
config FIREBEE
bool "FireBee board support"
depends on M547x
help
Support for the FireBee ColdFire 5475 based board.
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 06:20:36 +08:00
config CLEOPATRA
bool "Feith CLEOPATRA board support"
depends on (M5307 || M5407)
help
Support for the Feith Cleopatra boards.
config CANCam
bool "Feith CANCam board support"
depends on M5272
help
Support for the Feith CANCam board.
config SCALES
bool "Feith SCALES board support"
depends on M5272
help
Support for the Feith SCALES board.
config NETtel
bool "SecureEdge/NETtel board support"
depends on (M5206e || M5272 || M5307)
help
Support for the SnapGear NETtel/SecureEdge/SnapGear boards.
[PATCH] m68knommu: new family (523x) and board config support New architecture and board configuration support for m68knommu. . add 523x ColdFire support . add support for SOM5282 and MOD5272 boards . break up the 527x to be separate 5271 and 5275. There is some subtle differences that (like RAM config) that need to be dealt with . add option to support selecting 4k kernel stack Signed-off-by: Greg Ungerer <gerg@uclinux.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-02 08:42:52 +08:00
config MOD5272
bool "Netburner MOD-5272 board support"
depends on M5272
help
Support for the Netburner MOD-5272 board.
m68k: reorganize Kconfig options to improve mmu/non-mmu selections The current mmu and non-mmu Kconfig files can be merged to form a more general selection of options. The current break up of options is due to the simple brute force merge from the m68k and m68knommu arch directories. Many of the options are not at all specific to having the MMU enabled or not. They are actually associated with a particular CPU type or platform type. Ultimately as we support all processors with the MMU disabled we need many of these options to be selectable without the MMU option enabled. And likewise some of the ColdFire processors, which currently are only supported with the MMU disabled, do have MMU hardware, and will need to have options selected on CPU type, not MMU disabled. This patch removes the old mmu and non-mmu Kconfigs and instead breaks up the configuration into four areas: cpu, machine, bus, devices. The Kconfig.cpu lists all the options associated with selecting a CPU, and includes options specific to each CPU type as well. Kconfig.machine lists all options associated with selecting a machine type. Almost always the machines selectable is restricted by the chosen CPU. Kconfig.bus contains options associated with selecting bus types on the various machine types. That includes PCI bus, PCMCIA bus, etc. Kconfig.devices contains options for drivers and driver associated options. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2011-06-20 13:49:09 +08:00
if !MMU || COLDFIRE
comment "Machine Options"
m68knommu: add uboot commandline argument passing support This patch adds m68knommu support for getting the kernel command line arguments from uboot, including the passing of an initrd image from uboot. We use this on a 5270/5271 based board, and have used it on the 5271evb development board. It is based on a patch found in the linux-2.6-denx git tree, although that tree seems to have had lots of other changes since which are not in the main Linus kernel. I believe this will work on all coldfires, although other m68knommu might be missing the _init_sp stuff in head.S as far as I can tell. I only have the coldfire to test on. Signed-off-by: Lennart Sorensen <lsorense@csclub.uwaterloo.ca> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2009-09-19 01:49:36 +08:00
config UBOOT
bool "Support for U-Boot command line parameters"
help
If you say Y here kernel will try to collect command
line parameters from the initial u-boot stack.
default n
[PATCH] m68knommu: new family (523x) and board config support New architecture and board configuration support for m68knommu. . add 523x ColdFire support . add support for SOM5282 and MOD5272 boards . break up the 527x to be separate 5271 and 5275. There is some subtle differences that (like RAM config) that need to be dealt with . add option to support selecting 4k kernel stack Signed-off-by: Greg Ungerer <gerg@uclinux.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-02 08:42:52 +08:00
config 4KSTACKS
bool "Use 4Kb for kernel stacks instead of 8Kb"
default y
help
If you say Y here the kernel will use a 4Kb stacksize for the
kernel stack attached to each process/thread. This facilitates
running more threads on a system and also reduces the pressure
on the VM subsystem for higher order allocations.
[PATCH] m68knommu: create configurable RAM setup Reworked the way RAM regions are defined. Instead of coding all the variations for each board type we now just configure RAM base and size in the usual Kconfig setup. This much simplifies the code, and makes it a lot more flexible when setting up new boards or board varients. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 14:32:59 +08:00
comment "RAM configuration"
config RAMBASE
hex "Address of the base of RAM"
default "0"
help
Define the address that RAM starts at. On many platforms this is
0, the base of the address space. And this is the default. Some
platforms choose to setup their RAM at other addresses within the
processor address space.
config RAMSIZE
m68knommu: improve short help of m68knommu/Kconfig/RAMSIZE for '0' case While it is explained in the long help text, meaning of '0' for RAMSIZE is easily overlooked because is not mentioned in the short help text. Add that. Signed-off-by: Philippe De Muyter <phdm@macqel.be> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2010-05-19 19:30:49 +08:00
hex "Size of RAM (in bytes), or 0 for automatic"
[PATCH] m68knommu: create configurable RAM setup Reworked the way RAM regions are defined. Instead of coding all the variations for each board type we now just configure RAM base and size in the usual Kconfig setup. This much simplifies the code, and makes it a lot more flexible when setting up new boards or board varients. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 14:32:59 +08:00
default "0x400000"
help
Define the size of the system RAM. If you select 0 then the
kernel will try to probe the RAM size at runtime. This is not
supported on all CPU types.
config VECTORBASE
hex "Address of the base of system vectors"
default "0"
help
Attack of "the the"s in arch The patch below corrects multiple occurances of "the the" typos across several files, both in source comments and KConfig files. There is no actual code changed, only text. Note this only affects the /arch directory, and I believe I could find many more elsewhere. :) Signed-off-by: Adrian Bunk <bunk@stusta.de>
2006-10-04 04:21:02 +08:00
Define the address of the system vectors. Commonly this is
[PATCH] m68knommu: create configurable RAM setup Reworked the way RAM regions are defined. Instead of coding all the variations for each board type we now just configure RAM base and size in the usual Kconfig setup. This much simplifies the code, and makes it a lot more flexible when setting up new boards or board varients. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 14:32:59 +08:00
put at the start of RAM, but it doesn't have to be. On ColdFire
platforms this address is programmed into the VBR register, thus
actually setting the address to use.
m68knommu: make ColdFire internal peripheral region configurable Most ColdFire CPUs have an internal peripheral set that can be mapped at a user selectable address. Different ColdFire parts either use an MBAR register of an IPSBAR register to map the peripheral region. Most boards use the Freescale default mappings - but not all. Make the setting of the MBAR or IPSBAR register configurable. And only make the selection available on the appropriate ColdFire CPU types. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
2011-03-06 19:53:28 +08:00
config MBAR
hex "Address of the MBAR (internal peripherals)"
default "0x10000000"
depends on HAVE_MBAR
help
Define the address of the internal system peripherals. This value
is set in the processors MBAR register. This is generally setup by
the boot loader, and will not be written by the kernel. By far most
ColdFire boards use the default 0x10000000 value, so if unsure then
use this.
config IPSBAR
hex "Address of the IPSBAR (internal peripherals)"
default "0x40000000"
depends on HAVE_IPSBAR
help
Define the address of the internal system peripherals. This value
is set in the processors IPSBAR register. This is generally setup by
the boot loader, and will not be written by the kernel. By far most
ColdFire boards use the default 0x40000000 value, so if unsure then
use this.
[PATCH] m68knommu: create configurable RAM setup Reworked the way RAM regions are defined. Instead of coding all the variations for each board type we now just configure RAM base and size in the usual Kconfig setup. This much simplifies the code, and makes it a lot more flexible when setting up new boards or board varients. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 14:32:59 +08:00
config KERNELBASE
hex "Address of the base of kernel code"
default "0x400"
help
Typically on m68k systems the kernel will not start at the base
of RAM, but usually some small offset from it. Define the start
address of the kernel here. The most common setup will have the
processor vectors at the base of RAM and then the start of the
kernel. On some platforms some RAM is reserved for boot loaders
and the kernel starts after that. The 0x400 default was based on
a system with the RAM based at address 0, and leaving enough room
for the theoretical maximum number of 256 vectors.
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 06:20:36 +08:00
[PATCH] m68knommu: configuration options for ROM region Use Kconfig options to setup the optional ROM region used on some platforms. We used to define this in the linker script on a per board basis. The configure options are more flexible and clean up the linker script a lot. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-28 14:39:19 +08:00
comment "ROM configuration"
config ROM
bool "Specify ROM linker regions"
default n
help
Define a ROM region for the linker script. This creates a kernel
that can be stored in flash, with possibly the text, and data
regions being copied out to RAM at startup.
config ROMBASE
hex "Address of the base of ROM device"
default "0"
depends on ROM
help
Define the address that the ROM region starts at. Some platforms
use this to set their chip select region accordingly for the boot
device.
config ROMVEC
hex "Address of the base of the ROM vectors"
default "0"
depends on ROM
help
This is almost always the same as the base of the ROM. Since on all
Fix misc Kconfig typos Fix various Kconfig typos. Signed-off-by: Matt LaPlante <kernel1@cyberdogtech.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
2006-11-30 12:22:59 +08:00
68000 type variants the vectors are at the base of the boot device
[PATCH] m68knommu: configuration options for ROM region Use Kconfig options to setup the optional ROM region used on some platforms. We used to define this in the linker script on a per board basis. The configure options are more flexible and clean up the linker script a lot. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-28 14:39:19 +08:00
on system startup.
config ROMSTART
hex "Address of the base of system image in ROM"
default "0x400"
depends on ROM
help
Define the start address of the system image in ROM. Commonly this
is strait after the ROM vectors.
config ROMSIZE
hex "Size of the ROM device"
default "0x100000"
depends on ROM
help
Size of the ROM device. On some platforms this is used to setup
the chip select that controls the boot ROM device.
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 06:20:36 +08:00
choice
prompt "Kernel executes from"
---help---
Choose the memory type that the kernel will be running in.
config RAMKERNEL
bool "RAM"
help
The kernel will be resident in RAM when running.
config ROMKERNEL
bool "ROM"
help
[PATCH] m68knommu: create configurable RAM setup Reworked the way RAM regions are defined. Instead of coding all the variations for each board type we now just configure RAM base and size in the usual Kconfig setup. This much simplifies the code, and makes it a lot more flexible when setting up new boards or board varients. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 14:32:59 +08:00
The kernel will be resident in FLASH/ROM when running. This is
often referred to as Execute-in-Place (XIP), since the kernel
code executes from the position it is stored in the FLASH/ROM.
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 06:20:36 +08:00
endchoice
m68knommu: ColdFire add support for kernel preemption (missing chunk) As the subject says this patch adds the support for kernel preemption on m68knommu Coldfire. I thing the same changes could be applied to 68360 & 68328 but since I don't have the HW, I don't touch it. Kconfig enables the preemption item only on coldfire. This is a missing chunk from Sebastian's original patch that I lost from the first submission. Signed-off-by: Sebastian Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-05-13 05:02:05 +08:00
endif