Select this to build a kernel which aims to support multiple boards, generally using a flattened device tree passed from the bootloader using the boot protocol defined in the UHI (Unified Hosting Interface) specification.
Support for the Texas Instruments AR7 System-on-a-Chip family: TNETD7100, 7200 and 7300.
Support for Atheros AR231x and Atheros AR531x based boards
Support for the Atheros AR71XX/AR724X/AR913X SoCs.
Build a generic DT-based kernel image that boots on select BCM33xx cable modem chips, BCM63xx DSL chips, and BCM7xxx set-top box chips. Note that CONFIG_CPU_BIG_ENDIAN/CONFIG_CPU_LITTLE_ENDIAN must be set appropriately for your board.
Support for BCM47XX based boards
Support for BCM63XX based boards
This enables support for DEC's MIPS based workstations. For details see the Linux/MIPS FAQ on <http://www.linux-mips.org/> and the DECstation porting pages on <http://decstation.unix-ag.org/>. If you have one of the following DECstation Models you definitely want to choose R4xx0 for the CPU Type: DECstation 5000/50 DECstation 5000/150 DECstation 5000/260 DECsystem 5900/260 otherwise choose R3000.
This a family of machines based on the MIPS R4030 chipset which was used by several vendors to build RISC/os and Windows NT workstations. Members include the Acer PICA, MIPS Magnum 4000, MIPS Millennium and Olivetti M700-10 workstations.
This enables support for the Loongson-1 family of machines. Loongson-1 is a family of 32-bit MIPS-compatible SoCs developed by the Institute of Computing Technology (ICT), Chinese Academy of Sciences (CAS).
This enables the support of early Loongson-2E/F family of machines.
This enables the support of Loongson-2/3 family of machines. Loongson-2 and Loongson-3 are 64-bit general-purpose processors with GS264/GS464/GS464E/GS464V microarchitecture (except old Loongson-2E and Loongson-2F which will be removed), developed by the Institute of Computing Technology (ICT), Chinese Academy of Sciences (CAS).
This enables support for the IMG Pistachio SoC platform.
This enables support for the MIPS Technologies Malta evaluation board.
This enables support for the Microchip PIC32 family of platforms. Microchip PIC32 is a family of general-purpose 32 bit MIPS core microcontrollers.
This are the SGI Indy, Challenge S and Indigo2, as well as certain OEM variants like the Tandem CMN B006S. To compile a Linux kernel that runs on these, say Y here.
This are the SGI Origin 200, Origin 2000 and Onyx 2 Graphics workstations. To compile a Linux kernel that runs on these, say Y here.
This is the SGI Indigo2 with R10000 processor. To compile a Linux kernel that runs on these, say Y here.
These are the SGI Octane and Octane2 graphics workstations. To compile a Linux kernel that runs on these, say Y here.
If you want this kernel to run on SGI O2 workstation, say Y here.
The SNI RM200/300/400 are MIPS-based machines manufactured by Siemens Nixdorf Informationssysteme (SNI), parent company of Pyramid Technology and now in turn merged with Fujitsu. Say Y here to support this machine type.
Support the Mikrotik(tm) RouterBoard 532 series, based on the IDT RC32434 SoC.
This option supports all of the Octeon reference boards from Cavium Networks. It builds a kernel that dynamically determines the Octeon CPU type and supports all known board reference implementations. Some of the supported boards are: EBT3000 EBH3000 EBH3100 Thunder Kodama Hikari Say Y here for most Octeon reference boards.
Support for systems based on Netlogic XLR and XLS processors. Say Y here if you have a XLR or XLS based board.
This board is based on Netlogic XLP Processor. Say Y here if you have a XLP based board.
Selected if the platform supports relocating the kernel. The platform must provide plat_get_fdt() if it selects CONFIG_USE_OF to allow access to command line and entropy sources.
Some MIPS machines can be configured for either little or big endian byte order. These modes require different kernels and a different Linux distribution. In general there is one preferred byteorder for a particular system but some systems are just as commonly used in the one or the other endianness.
The Loongson GSx64(GS264/GS464/GS464E/GS464V) series of processor cores implements the MIPS64R2 instruction set with many extensions, including most 64-bit Loongson-2 (2H, 2K) and Loongson-3 (3A1000, 3B1000, 3B1500, 3A2000, 3A3000 and 3A4000) processors. However, old Loongson-2E/2F is not covered here and will be removed in future.
New Loongson-3 cores (since Loongson-3A R2, as opposed to Loongson-3A R1, Loongson-3B R1 and Loongson-3B R2) has many enhancements, such as FTLB, L1-VCache, EI/DI/Wait/Prefetch instruction, DSP/DSPr2 ASE, User Local register, Read-Inhibit/Execute-Inhibit, SFB (Store Fill Buffer), Fast TLB refill support, etc. This option enable those enhancements which are not probed at run time. If you want a generic kernel to run on all Loongson 3 machines, please say 'N' here. If you want a high-performance kernel to run on new Loongson-3 machines only, please say 'Y' here.
Loongson-3 processors have the llsc issues which require workarounds. Without workarounds the system may hang unexpectedly. Newer Loongson-3 will fix these issues and no workarounds are needed. The workarounds have no significant side effect on them but may decrease the performance of the system so this option should be disabled unless the kernel is intended to be run on old systems. If unsure, please say Y.
Loongson-3A R4 and newer have the CPUCFG instruction available for userland to query CPU capabilities, much like CPUID on x86. This option provides emulation of the instruction on older Loongson cores, back to Loongson-3A1000. If unsure, please say Y.
The Loongson 2E processor implements the MIPS III instruction set with many extensions. It has an internal FPGA northbridge, which is compatible to bonito64.
The Loongson 2F processor implements the MIPS III instruction set with many extensions. Loongson2F have built-in DDR2 and PCIX controller. The PCIX controller have a similar programming interface with FPGA northbridge used in Loongson2E.
The Loongson 1B is a 32-bit SoC, which implements the MIPS32 Release 1 instruction set and part of the MIPS32 Release 2 instruction set.
The Loongson 1C is a 32-bit SoC, which implements the MIPS32 Release 1 instruction set and part of the MIPS32 Release 2 instruction set.
Choose this option to build a kernel for release 1 or later of the MIPS32 architecture. Most modern embedded systems with a 32-bit MIPS processor are based on a MIPS32 processor. If you know the specific type of processor in your system, choose those that one otherwise CPU_MIPS32_R1 is a safe bet for any MIPS32 system. Release 2 of the MIPS32 architecture is available since several years so chances are you even have a MIPS32 Release 2 processor in which case you should choose CPU_MIPS32_R2 instead for better performance.
Choose this option to build a kernel for release 2 or later of the MIPS32 architecture. Most modern embedded systems with a 32-bit MIPS processor are based on a MIPS32 processor. If you know the specific type of processor in your system, choose those that one otherwise CPU_MIPS32_R1 is a safe bet for any MIPS32 system.
Choose this option to build a kernel for release 5 or later of the MIPS32 architecture. New MIPS processors, starting with the Warrior family, are based on a MIPS32r5 processor. If you own an older processor, you probably need to select MIPS32r1 or MIPS32r2 instead.
Choose this option to build a kernel for release 6 or later of the MIPS32 architecture. New MIPS processors, starting with the Warrior family, are based on a MIPS32r6 processor. If you own an older processor, you probably need to select MIPS32r1 or MIPS32r2 instead.
Choose this option to build a kernel for release 1 or later of the MIPS64 architecture. Many modern embedded systems with a 64-bit MIPS processor are based on a MIPS64 processor. If you know the specific type of processor in your system, choose those that one otherwise CPU_MIPS64_R1 is a safe bet for any MIPS64 system. Release 2 of the MIPS64 architecture is available since several years so chances are you even have a MIPS64 Release 2 processor in which case you should choose CPU_MIPS64_R2 instead for better performance.
Choose this option to build a kernel for release 2 or later of the MIPS64 architecture. Many modern embedded systems with a 64-bit MIPS processor are based on a MIPS64 processor. If you know the specific type of processor in your system, choose those that one otherwise CPU_MIPS64_R1 is a safe bet for any MIPS64 system.
Choose this option to build a kernel for release 5 or later of the MIPS64 architecture. This is a intermediate MIPS architecture release partly implementing release 6 features. Though there is no any hardware known to be based on this release.
Choose this option to build a kernel for release 6 or later of the MIPS64 architecture. New MIPS processors, starting with the Warrior family, are based on a MIPS64r6 processor. If you own an older processor, you probably need to select MIPS64r1 or MIPS64r2 instead.
Choose this option to build a kernel for MIPS Warrior P5600 CPU. It's based on MIPS32r5 ISA with XPA, EVA, dual/quad issue exec pipes, MMU with two-levels TLB, UCA, MSA, MDU core level features and system level features like up to six P5600 calculation cores, CM2 with L2 cache, IOCU/IOMMU (though might be unused depending on the system- specific IP core configuration), GIC, CPC, virtualisation module, eJTAG and PDtrace.
Please make sure to pick the right CPU type. Linux/MIPS is not designed to be generic, i.e. Kernels compiled for R3000 CPUs will *not* work on R4000 machines and vice versa. However, since most of the supported machines have an R4000 (or similar) CPU, R4x00 might be a safe bet. If the resulting kernel does not work, try to recompile with R3000.
The options selects support for the NEC VR4100 series of processors. Only choose this option if you have one of these processors as a kernel built with this option will not run on any other type of processor or vice versa.
MIPS Technologies R4300-series processors.
MIPS Technologies R4000-series processors other than 4300, including the R4000, R4400, R4600, and 4700.
MIPS Technologies R5000-series processors other than the Nevada.
NEC VR5500 and VR5500A series processors implement 64-bit MIPS IV instruction set.
QED / PMC-Sierra RM52xx-series ("Nevada") processors.
MIPS Technologies R10000-series processors.
The Cavium Octeon processor is a highly integrated chip containing many ethernet hardware widgets for networking tasks. The processor can have up to 16 Mips64v2 cores and 8 integrated gigabit ethernets. Full details can be found at http://www.caviumnetworks.com.
Support for BMIPS32/3300/4350/4380 and BMIPS5000 processors.
Netlogic Microsystems XLR/XLS processors.
Netlogic Microsystems XLP processors.
Choose this option to build a kernel for release 2 or later of the MIPS32 architecture including features from the 3.5 release such as support for Enhanced Virtual Addressing (EVA).
Choose this option if you want to enable the Enhanced Virtual Addressing (EVA) on your MIPS32 core (such as proAptiv). One of its primary benefits is an increase in the maximum size of lowmem (up to 3GB). If unsure, say 'N' here.
Choose this option to build a kernel for release 2 or later of the MIPS32 architecture including features from release 5 such as support for Extended Physical Addressing (XPA).
Choose this option if you want to enable the Extended Physical Addressing (XPA) on your MIPS32 core (such as P5600 series). The benefit is to increase physical addressing equal to or greater than 40 bits. Note that this has the side effect of turning on 64-bit addressing which in turn makes the PTEs 64-bit in size. If unsure, say 'N' here.
Loongson 2F01 / 2F02 processors have the NOP & JUMP issues which require workarounds. Without workarounds the system may hang unexpectedly. For more information please refer to the gas -mfix-loongson2f-nop and -mfix-loongson2f-jump options. Loongson 2F03 and later have fixed these issues and no workarounds are needed. The workarounds have no significant side effect on them but may decrease the performance of the system so this option should be disabled unless the kernel is intended to be run on 2F01 or 2F02 systems. If unsure, please say Y.
Reflects the ISA revision being targeted by the kernel build. This is effectively the Kconfig equivalent of MIPS_ISA_REV.
You should only select this option if you have a workload that actually benefits from 64-bit processing or if your machine has large memory. You will only be presented a single option in this menu if your system does not support both 32-bit and 64-bit kernels.
Select this option if you want to build a 32-bit kernel.
Select this option if you want to build a 64-bit kernel.
Support a maximum at least 48 bits of application virtual memory. Default is 40 bits or less, depending on the CPU. For page sizes 16k and above, this option results in a small memory overhead for page tables. For 4k page size, a fourth level of page tables is added which imposes both a memory overhead as well as slower TLB fault handling. If unsure, say N.
This option select the standard 4kB Linux page size. On some R3000-family processors this is the only available page size. Using 4kB page size will minimize memory consumption and is therefore recommended for low memory systems.
Using 8kB page size will result in higher performance kernel at the price of higher memory consumption. This option is available only on cnMIPS processors. Note that you will need a suitable Linux distribution to support this.
Using 16kB page size will result in higher performance kernel at the price of higher memory consumption. This option is available on all non-R3000 family processors. Note that you will need a suitable Linux distribution to support this.
Using 32kB page size will result in higher performance kernel at the price of higher memory consumption. This option is available only on cnMIPS cores. Note that you will need a suitable Linux distribution to support this.
Using 64kB page size will result in higher performance kernel at the price of higher memory consumption. This option is available on all non-R3000 family processor. Not that at the time of this writing this option is still high experimental.
The kernel memory allocator divides physically contiguous memory blocks into "zones", where each zone is a power of two number of pages. This option selects the largest power of two that the kernel keeps in the memory allocator. If you need to allocate very large blocks of physically contiguous memory, then you may need to increase this value. This config option is actually maximum order plus one. For example, a value of 11 means that the largest free memory block is 2^10 pages. The page size is not necessarily 4KB. Keep this in mind when choosing a value for this option.
Instead of using the CPU to zero and copy pages, use a Data Mover channel. These DMA channels are otherwise unused by the standard SiByte Linux port. Seems to give a small performance benefit.
Select y to include support for floating point in the kernel including initialization of FPU hardware, FP context save & restore and emulation of an FPU where necessary. Without this support any userland program attempting to use floating point instructions will receive a SIGILL. If you know that your userland will not attempt to use floating point instructions then you can say n here to shrink the kernel a little. If unsure, say y.
This is a kernel model which is known as SMVP. This is supported on cores with the MT ASE and uses the available VPEs to implement virtual processors which supports SMP. This is equivalent to the Intel Hyperthreading feature. For further information go to <http://www.imgtec.com/mips/mips-multithreading.asp>.
SMT scheduler support improves the CPU scheduler's decision making when dealing with MIPS MT enabled cores at a cost of slightly increased overhead in some places. If unsure say N here.
Choose this option if you want to run non-R6 MIPS userland code. Even if you say 'Y' here, the emulator will still be disabled by default. You can enable it using the 'mipsr2emu' kernel option. The only reason this is a build-time option is to save ~14K from the final kernel image.
Indicates that the platform supports the VPE loader, and provides physical_memsize.
Includes a loader for loading an elf relocatable object onto another VPE and running it.
The loader can use memory that is present but has been hidden from Linux using the kernel command line option "mem=xxMB". It's up to you to ensure the amount you put in the option and the space your program requires is less or equal to the amount physically present.
Select this if you are using a bootloader which implements the "CMP framework" protocol (ie. YAMON) and want your kernel to make use of its ability to start secondary CPUs. Unless you have a specific need, you should use CONFIG_MIPS_CPS instead of this.
Select this if you wish to run an SMP kernel across multiple cores within a MIPS Coherent Processing System. When this option is enabled the kernel will probe for other cores and boot them with no external assistance. It is safe to enable this when hardware support is unavailable.
Select this if you want neither microMIPS nor SmartMIPS support
SmartMIPS is a extension of the MIPS32 architecture aimed at increased security at both hardware and software level for smartcards. Enabling this option will allow proper use of the SmartMIPS instructions by Linux applications. However a kernel with this option will not work on a MIPS core without SmartMIPS core. If you don't know you probably don't have SmartMIPS and should say N here.
When this option is enabled the kernel will be built using the microMIPS ISA
MIPS SIMD Architecture (MSA) introduces 128 bit wide vector registers and a set of SIMD instructions to operate on them. When this option is enabled the kernel will support allocating & switching MSA vector register contexts. If you know that your kernel will only be running on CPUs which do not support MSA or that your userland will not be making use of it then you may wish to say N here to reduce the size & complexity of your kernel. If unsure, say Y.
CPU lacks support for unaligned load and store instructions: LWL, LWR, SWL, SWR (Load/store word left/right). LDL, LDR, SDL, SDR (Load/store doubleword left/right, for 64bit systems).
This option must be set if a kernel might be executed on a MIPS16- enabled CPU even if MIPS16 is not actually being used. In other words, it makes the kernel MIPS16-tolerant.
Say Y to compile the kernel to support NUMA (Non-Uniform Memory Access). This option improves performance on systems with more than two nodes; on two node systems it is generally better to leave it disabled; on single node systems leave this option disabled.
This builds a kernel image that retains relocation information so it can be loaded someplace besides the default 1MB. The relocations make the kernel binary about 15% larger, but are discarded at runtime
A table of relocation data will be appended to the kernel binary and parsed at boot to fix up the relocated kernel. This option allows the amount of space reserved for the table to be adjusted, although the default of 1Mb should be ok in most cases. The build will fail and a valid size suggested if this is too small. If unsure, leave at the default value.
Randomizes the physical and virtual address at which the kernel image is loaded, as a security feature that deters exploit attempts relying on knowledge of the location of kernel internals. Entropy is generated using any coprocessor 0 registers available. The kernel will be offset by up to RANDOMIZE_BASE_MAX_OFFSET. If unsure, say N.
When kASLR is active, this provides the maximum offset that will be applied to the kernel image. It should be set according to the amount of physical RAM available in the target system minus PHYSICAL_START and must be a power of 2. This is limited by the size of KSEG0, 256Mb on 32-bit or 1Gb with EVA or 64-bit. The default is 16Mb.
Enable hardware performance counter support for perf events. If disabled, perf events will use software events only.
Enabled scanning of DMI to identify machine quirks. Say Y here unless you have verified that your setup is not affected by entries in the DMI blacklist. Required by PNP BIOS code.
This enables support for systems with more than one CPU. If you have a system with only one CPU, say N. If you have a system with more than one CPU, say Y. If you say N here, the kernel will run on uni- and multiprocessor machines, but will use only one CPU of a multiprocessor machine. If you say Y here, the kernel will run on many, but not all, uniprocessor machines. On a uniprocessor machine, the kernel will run faster if you say N here. People using multiprocessor machines who say Y here should also say Y to "Enhanced Real Time Clock Support", below. See also the SMP-HOWTO available at <https://www.tldp.org/docs.html#howto>. If you don't know what to do here, say N.
Say Y here to allow turning CPUs off and on. CPUs can be controlled through /sys/devices/system/cpu. (Note: power management support will enable this option automatically on SMP systems. ) Say N if you want to disable CPU hotplug.
This allows you to specify the maximum number of CPUs which this kernel will support. The maximum supported value is 32 for 32-bit kernel and 64 for 64-bit kernels; the minimum value which makes sense is 1 for Qemu (useful only for kernel debugging purposes) and 2 for all others. This is purely to save memory - each supported CPU adds approximately eight kilobytes to the kernel image. For best performance should round up your number of processors to the next power of two.
Allows the configuration of the timer frequency. config HZ_24 bool "24 HZ" if SYS_SUPPORTS_24HZ || SYS_SUPPORTS_ARBIT_HZ config HZ_48 bool "48 HZ" if SYS_SUPPORTS_48HZ || SYS_SUPPORTS_ARBIT_HZ config HZ_100 bool "100 HZ" if SYS_SUPPORTS_100HZ || SYS_SUPPORTS_ARBIT_HZ config HZ_128 bool "128 HZ" if SYS_SUPPORTS_128HZ || SYS_SUPPORTS_ARBIT_HZ config HZ_250 bool "250 HZ" if SYS_SUPPORTS_250HZ || SYS_SUPPORTS_ARBIT_HZ config HZ_256 bool "256 HZ" if SYS_SUPPORTS_256HZ || SYS_SUPPORTS_ARBIT_HZ config HZ_1000 bool "1000 HZ" if SYS_SUPPORTS_1000HZ || SYS_SUPPORTS_ARBIT_HZ config HZ_1024 bool "1024 HZ" if SYS_SUPPORTS_1024HZ || SYS_SUPPORTS_ARBIT_HZ
kexec is a system call that implements the ability to shutdown your current kernel, and to start another kernel. It is like a reboot but it is independent of the system firmware. And like a reboot you can start any kernel with it, not just Linux. The name comes from the similarity to the exec system call. It is an ongoing process to be certain the hardware in a machine is properly shutdown, so do not be surprised if this code does not initially work for you. As of this writing the exact hardware interface is strongly in flux, so no good recommendation can be made.
Generate crash dump after being started by kexec. This should be normally only set in special crash dump kernels which are loaded in the main kernel with kexec-tools into a specially reserved region and then later executed after a crash by kdump/kexec. The crash dump kernel must be compiled to a memory address not used by the main kernel or firmware using PHYSICAL_START.
This gives the CKSEG0 or KSEG0 address where the kernel is loaded. If you plan to use kernel for capturing the crash dump change this value to start of the reserved region (the "X" value as specified in the "crashkernel=YM@XM" command line boot parameter passed to the panic-ed kernel).
When this is enabled, the kernel will support use of 64-bit floating point registers with binaries using the O32 ABI along with the EF_MIPS_FP64 ELF header flag (typically built with -mfp64). On 32-bit MIPS systems this support is at the cost of increasing the size and complexity of the compiled FPU emulator. Thus if you are running a MIPS32 system and know that none of your userland binaries will require 64-bit floating point, you may wish to reduce the size of your kernel & potentially improve FP emulation performance by saying N here. Although binutils currently supports use of this flag the details concerning its effect upon the O32 ABI in userland are still being worked on. In order to avoid userland becoming dependent upon current behaviour before the details have been finalised, this option should be considered experimental and only enabled by those working upon said details. If unsure, say N.
Do not enable appended dtb support.
With this option, the boot code will look for a device tree binary DTB) included in the vmlinux ELF section .appended_dtb. By default it is empty and the DTB can be appended using binutils command objcopy: objcopy --update-section .appended_dtb=<filename>.dtb vmlinux This is meant as a backward compatibility convenience for those systems with a bootloader that can't be upgraded to accommodate the documented boot protocol using a device tree.
With this option, the boot code will look for a device tree binary DTB) appended to raw vmlinux.bin or vmlinuz.bin. (e.g. cat vmlinux.bin <filename>.dtb > vmlinux_w_dtb). This is meant as a backward compatibility convenience for those systems with a bootloader that can't be upgraded to accommodate the documented boot protocol using a device tree. Beware that there is very little in terms of protection against this option being confused by leftover garbage in memory that might look like a DTB header after a reboot if no actual DTB is appended to vmlinux.bin. Do not leave this option active in a production kernel if you don't intend to always append a DTB.
TURBOchannel is a DEC (now Compaq (now HP)) bus for Alpha and MIPS processors. TURBOchannel programming specifications are available at: <ftp://ftp.hp.com/pub/alphaserver/archive/triadd/> and: <http://www.computer-refuge.org/classiccmp/ftp.digital.com/pub/DEC/TriAdd/> Linux driver support status is documented at: <http://www.linux-mips.org/wiki/DECstation>
Select this option if you want to run o32 binaries. These are pure 32-bit binaries as used by the 32-bit Linux/MIPS port. Most of existing binaries are in this format. If unsure, say Y.
Select this option if you want to run n32 binaries. These are 64-bit binaries using 32-bit quantities for addressing and certain data that would normally be 64-bit. They are used in special cases. If unsure, say N.