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.
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.
This option enables support for the Apple Macintosh series of computers. If you plan to use this kernel on a Mac, say Y here and browse the documentation available at <http://www.mac.linux-m68k.org/>; otherwise say N.
Say Y here if you want to run Linux on an MC680x0-based Apollo Domain workstation such as the DN3500.
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.
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.
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.
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.
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.
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.
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.
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.
Support for the Palm Pilot 1000/5000, Personal/Pro and PalmIII.
Support the bugs of Xcopilot.
Support for the Arcturus Networks uCsimm module.
Support for the Arcturus Networks uDsimm module.
Support for the DragenEngine II board.
Disable the CPU internal registers protection in user mode, to allow a user application to read/write them.
Initialize the LCD controller of the 68x328 processor.
Reserve certain memory regions on 68x328 based boards.
Support for the Arnewsh 5206 board.
Support for the Motorola M5206eC3 board.
Support for the Motorola M5206eLITE board.
Support for the Freescale M5235EVB board.
Support for the Motorola M5249C3 board.
Support for the Motorola M5272C3 board.
Support for the Intec Automation Inc. WildFire.
Support for the Intec Automation Inc. WildFire module.
Support for the Arnewsh 5307 board.
Support for the Motorola M5307C3 board.
Support for the SnapGear SecureEdge/MP3 platform.
Support for the Motorola M5407C3 board.
Support for the Sysam AMCORE open-hardware generic board.
Support for the Sysam stmark2 open-hardware generic board.
Support for the FireBee ColdFire 5475 based board.
Support for the Feith Cleopatra boards.
Support for the Feith CANCam board.
Support for the Feith SCALES board.
Support for the SnapGear NETtel/SecureEdge/SnapGear boards.
Support for the Netburner MOD-5272 board.
If you say Y here kernel will try to collect command line parameters from the initial u-boot stack.
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.
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.
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.
Define the address of the system vectors. Commonly this is 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.
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.
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.
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.
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.
Define the address that the ROM region starts at. Some platforms use this to set their chip select region accordingly for the boot device.
This is almost always the same as the base of the ROM. Since on all 68000 type variants the vectors are at the base of the boot device on system startup.
Define the start address of the system image in ROM. Commonly this is strait after the ROM vectors.
Size of the ROM device. On some platforms this is used to setup the chip select that controls the boot ROM device.
Choose the memory type that the kernel will be running in.
The kernel will be resident in RAM when running.
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.