License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 14:07:57 +00:00
|
|
|
# SPDX-License-Identifier: GPL-2.0
|
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 05:49:09 +00:00
|
|
|
comment "Machine Types"
|
|
|
|
|
|
2011-12-26 19:32:02 +00: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 05:49:09 +00: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.
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2011-12-26 19:32:02 +00: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 05:49:09 +00:00
|
|
|
config PILOT
|
2010-11-02 02:05:29 +00:00
|
|
|
bool
|
2005-04-16 22:20:36 +00: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 05:49:09 +00:00
|
|
|
select PILOT
|
2005-04-16 22:20:36 +00:00
|
|
|
help
|
|
|
|
|
Support for the Palm Pilot 1000/5000, Personal/Pro and PalmIII.
|
|
|
|
|
|
|
|
|
|
config XCOPILOT_BUGS
|
2006-12-04 06:40:58 +00:00
|
|
|
bool "(X)Copilot support"
|
2005-04-16 22:20:36 +00: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
|
2006-12-04 06:40:58 +00:00
|
|
|
bool "Allow user to access IO directly"
|
2005-04-16 22:20:36 +00:00
|
|
|
depends on (UCSIMM || UCDIMM || DRAGEN2)
|
|
|
|
|
help
|
|
|
|
|
Disable the CPU internal registers protection in user mode,
|
2010-11-11 22:57:56 +00:00
|
|
|
to allow a user application to read/write them.
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
|
config INIT_LCD
|
2006-12-04 06:40:58 +00:00
|
|
|
bool "Initialize LCD"
|
2005-04-16 22:20:36 +00:00
|
|
|
depends on (UCSIMM || UCDIMM || DRAGEN2)
|
|
|
|
|
help
|
|
|
|
|
Initialize the LCD controller of the 68x328 processor.
|
|
|
|
|
|
|
|
|
|
config MEMORY_RESERVE
|
2006-12-04 06:40:58 +00:00
|
|
|
int "Memory reservation (MiB)"
|
2005-04-16 22:20:36 +00:00
|
|
|
depends on (UCSIMM || UCDIMM)
|
|
|
|
|
help
|
|
|
|
|
Reserve certain memory regions on 68x328 based boards.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
2005-09-02 00:42:52 +00:00
|
|
|
config M5235EVB
|
|
|
|
|
bool "Freescale M5235EVB support"
|
|
|
|
|
depends on M523x
|
|
|
|
|
help
|
|
|
|
|
Support for the Freescale M5235EVB board.
|
|
|
|
|
|
2005-04-16 22:20:36 +00: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.
|
|
|
|
|
|
2007-07-25 12:07:20 +00: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 05:49:09 +00:00
|
|
|
|
2007-07-25 12:07:20 +00:00
|
|
|
config WILDFIREMOD
|
|
|
|
|
bool "Intec Automation Inc. WildFire module support"
|
|
|
|
|
depends on M528x
|
|
|
|
|
help
|
|
|
|
|
Support for the Intec Automation Inc. WildFire module.
|
2005-04-16 22:20:36 +00: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.
|
|
|
|
|
|
2016-10-06 18:41:35 +00:00
|
|
|
config AMCORE
|
|
|
|
|
bool "Sysam AMCORE board support"
|
|
|
|
|
depends on M5307
|
|
|
|
|
help
|
|
|
|
|
Support for the Sysam AMCORE open-hardware generic board.
|
|
|
|
|
|
2017-10-12 22:42:51 +00:00
|
|
|
config STMARK2
|
|
|
|
|
bool "Sysam stmark2 board support"
|
|
|
|
|
depends on M5441x
|
|
|
|
|
help
|
|
|
|
|
Support for the Sysam stmark2 open-hardware generic board.
|
|
|
|
|
|
2011-03-06 13:20:19 +00:00
|
|
|
config FIREBEE
|
|
|
|
|
bool "FireBee board support"
|
|
|
|
|
depends on M547x
|
|
|
|
|
help
|
|
|
|
|
Support for the FireBee ColdFire 5475 based board.
|
|
|
|
|
|
2005-04-16 22:20:36 +00: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.
|
|
|
|
|
|
2005-09-02 00:42:52 +00: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 05:49:09 +00:00
|
|
|
if !MMU || COLDFIRE
|
|
|
|
|
|
|
|
|
|
comment "Machine Options"
|
|
|
|
|
|
2009-09-18 17:49:36 +00: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
|
|
|
|
|
|
2005-09-02 00:42:52 +00: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.
|
|
|
|
|
|
2006-06-26 06:32:59 +00: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
|
2010-05-19 11:30:49 +00:00
|
|
|
hex "Size of RAM (in bytes), or 0 for automatic"
|
2006-06-26 06:32:59 +00: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
|
2006-10-03 20:21:02 +00:00
|
|
|
Define the address of the system vectors. Commonly this is
|
2006-06-26 06:32:59 +00: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.
|
|
|
|
|
|
2011-03-06 11:53:28 +00: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.
|
|
|
|
|
|
2006-06-26 06:32:59 +00: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.
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2006-06-28 06:39:19 +00: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
|
2006-11-30 04:22:59 +00:00
|
|
|
68000 type variants the vectors are at the base of the boot device
|
2006-06-28 06:39:19 +00: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.
|
|
|
|
|
|
2005-04-16 22:20:36 +00: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
|
2006-06-26 06:32:59 +00: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.
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
|
endchoice
|
|
|
|
|
|
2008-05-12 21:02:05 +00:00
|
|
|
endif
|
