diff options
author | Linus Torvalds <torvalds@ppc970.osdl.org> | 2005-04-16 15:20:36 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@ppc970.osdl.org> | 2005-04-16 15:20:36 -0700 |
commit | 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 (patch) | |
tree | 0bba044c4ce775e45a88a51686b5d9f90697ea9d /arch/frv/Kconfig | |
download | linux-1da177e4c3f41524e886b7f1b8a0c1fc7321cac2.tar.bz2 |
Linux-2.6.12-rc2v2.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!
Diffstat (limited to 'arch/frv/Kconfig')
-rw-r--r-- | arch/frv/Kconfig | 357 |
1 files changed, 357 insertions, 0 deletions
diff --git a/arch/frv/Kconfig b/arch/frv/Kconfig new file mode 100644 index 000000000000..2b19372767eb --- /dev/null +++ b/arch/frv/Kconfig @@ -0,0 +1,357 @@ +# +# For a description of the syntax of this configuration file, +# see Documentation/kbuild/kconfig-language.txt. +# +config FRV + bool + default y + +config UID16 + bool + default y + +config RWSEM_GENERIC_SPINLOCK + bool + default y + +config RWSEM_XCHGADD_ALGORITHM + bool + +config GENERIC_FIND_NEXT_BIT + bool + default y + +config GENERIC_CALIBRATE_DELAY + bool + default n + +config GENERIC_HARDIRQS + bool + default n + +mainmenu "Fujitsu FR-V Kernel Configuration" + +source "init/Kconfig" + + +menu "Fujitsu FR-V system setup" + +config MMU + bool "MMU support" + help + This options switches on and off support for the FR-V MMU + (effectively switching between vmlinux and uClinux). Not all FR-V + CPUs support this. Currently only the FR451 has a sufficiently + featured MMU. + +config FRV_OUTOFLINE_ATOMIC_OPS + bool "Out-of-line the FRV atomic operations" + default n + help + Setting this option causes the FR-V atomic operations to be mostly + implemented out-of-line. + + See Documentation/fujitsu/frv/atomic-ops.txt for more information. + +config HIGHMEM + bool "High memory support" + depends on MMU + default y + help + If you wish to use more than 256MB of memory with your MMU based + system, you will need to select this option. The kernel can only see + the memory between 0xC0000000 and 0xD0000000 directly... everything + else must be kmapped. + + The arch is, however, capable of supporting up to 3GB of SDRAM. + +config HIGHPTE + bool "Allocate page tables in highmem" + depends on HIGHMEM + default y + help + The VM uses one page of memory for each page table. For systems + with a lot of RAM, this can be wasteful of precious low memory. + Setting this option will put user-space page tables in high memory. + +choice + prompt "uClinux kernel load address" + depends on !MMU + default UCPAGE_OFFSET_C0000000 + help + This option sets the base address for the uClinux kernel. The kernel + will rearrange the SDRAM layout to start at this address, and move + itself to start there. It must be greater than 0, and it must be + sufficiently less than 0xE0000000 that the SDRAM does not intersect + the I/O region. + + The base address must also be aligned such that the SDRAM controller + can decode it. For instance, a 512MB SDRAM bank must be 512MB aligned. + +config UCPAGE_OFFSET_20000000 + bool "0x20000000" + +config UCPAGE_OFFSET_40000000 + bool "0x40000000" + +config UCPAGE_OFFSET_60000000 + bool "0x60000000" + +config UCPAGE_OFFSET_80000000 + bool "0x80000000" + +config UCPAGE_OFFSET_A0000000 + bool "0xA0000000" + +config UCPAGE_OFFSET_C0000000 + bool "0xC0000000 (Recommended)" + +endchoice + +config PROTECT_KERNEL + bool "Protect core kernel against userspace" + depends on !MMU + default y + help + Selecting this option causes the uClinux kernel to change the + permittivity of DAMPR register covering the core kernel image to + prevent userspace accessing the underlying memory directly. + +choice + prompt "CPU Caching mode" + default FRV_DEFL_CACHE_WBACK + help + This option determines the default caching mode for the kernel. + + Write-Back caching mode involves the all reads and writes causing + the affected cacheline to be read into the cache first before being + operated upon. Memory is not then updated by a write until the cache + is filled and a cacheline needs to be displaced from the cache to + make room. Only at that point is it written back. + + Write-Behind caching is similar to Write-Back caching, except that a + write won't fetch a cacheline into the cache if there isn't already + one there; it will write directly to memory instead. + + Write-Through caching only fetches cachelines from memory on a + read. Writes always get written directly to memory. If the affected + cacheline is also in cache, it will be updated too. + + The final option is to turn of caching entirely. + + Note that not all CPUs support Write-Behind caching. If the CPU on + which the kernel is running doesn't, it'll fall back to Write-Back + caching. + +config FRV_DEFL_CACHE_WBACK + bool "Write-Back" + +config FRV_DEFL_CACHE_WBEHIND + bool "Write-Behind" + +config FRV_DEFL_CACHE_WTHRU + bool "Write-Through" + +config FRV_DEFL_CACHE_DISABLED + bool "Disabled" + +endchoice + +menu "CPU core support" + +config CPU_FR401 + bool "Include FR401 core support" + depends on !MMU + default y + help + This enables support for the FR401, FR401A and FR403 CPUs + +config CPU_FR405 + bool "Include FR405 core support" + depends on !MMU + default y + help + This enables support for the FR405 CPU + +config CPU_FR451 + bool "Include FR451 core support" + default y + help + This enables support for the FR451 CPU + +config CPU_FR451_COMPILE + bool "Specifically compile for FR451 core" + depends on CPU_FR451 && !CPU_FR401 && !CPU_FR405 && !CPU_FR551 + default y + help + This causes appropriate flags to be passed to the compiler to + optimise for the FR451 CPU + +config CPU_FR551 + bool "Include FR551 core support" + depends on !MMU + default y + help + This enables support for the FR555 CPU + +config CPU_FR551_COMPILE + bool "Specifically compile for FR551 core" + depends on CPU_FR551 && !CPU_FR401 && !CPU_FR405 && !CPU_FR451 + default y + help + This causes appropriate flags to be passed to the compiler to + optimise for the FR555 CPU + +config FRV_L1_CACHE_SHIFT + int + default "5" if CPU_FR401 || CPU_FR405 || CPU_FR451 + default "6" if CPU_FR551 + +endmenu + +choice + prompt "System support" + default MB93091_VDK + +config MB93091_VDK + bool "MB93091 CPU board with or without motherboard" + +config MB93093_PDK + bool "MB93093 PDK unit" + +endchoice + +if MB93091_VDK +choice + prompt "Motherboard support" + default MB93090_MB00 + +config MB93090_MB00 + bool "Use the MB93090-MB00 motherboard" + help + Select this option if the MB93091 CPU board is going to be used with + a MB93090-MB00 VDK motherboard + +config MB93091_NO_MB + bool "Use standalone" + help + Select this option if the MB93091 CPU board is going to be used + without a motherboard + +endchoice +endif + +choice + prompt "GP-Relative data support" + default GPREL_DATA_8 + help + This option controls what data, if any, should be placed in the GP + relative data sections. Using this means that the compiler can + generate accesses to the data using GR16-relative addressing which + is faster than absolute instructions and saves space (2 instructions + per access). + + However, the GPREL region is limited in size because the immediate + value used in the load and store instructions is limited to a 12-bit + signed number. + + So if the linker starts complaining that accesses to GPREL data are + out of range, try changing this option from the default. + + Note that modules will always be compiled with this feature disabled + as the module data will not be in range of the GP base address. + +config GPREL_DATA_8 + bool "Put data objects of up to 8 bytes into GP-REL" + +config GPREL_DATA_4 + bool "Put data objects of up to 4 bytes into GP-REL" + +config GPREL_DATA_NONE + bool "Don't use GP-REL" + +endchoice + +config PCI + bool "Use PCI" + depends on MB93090_MB00 + default y + help + Some FR-V systems (such as the MB93090-MB00 VDK) have PCI + onboard. If you have one of these boards and you wish to use the PCI + facilities, say Y here. + + The PCI-HOWTO, available from + <http://www.tldp.org/docs.html#howto>, contains valuable + information about which PCI hardware does work under Linux and which + doesn't. + +config RESERVE_DMA_COHERENT + bool "Reserve DMA coherent memory" + depends on PCI && !MMU + default y + help + Many PCI drivers require access to uncached memory for DMA device + communications (such as is done with some Ethernet buffer rings). If + a fully featured MMU is available, this can be done through page + table settings, but if not, a region has to be set aside and marked + with a special DAMPR register. + + Setting this option causes uClinux to set aside a portion of the + available memory for use in this manner. The memory will then be + unavailable for normal kernel use. + +source "drivers/pci/Kconfig" + +config PCMCIA + tristate "Use PCMCIA" + help + Say Y here if you want to attach PCMCIA- or PC-cards to your FR-V + board. These are credit-card size devices such as network cards, + modems or hard drives often used with laptops computers. There are + actually two varieties of these cards: the older 16 bit PCMCIA cards + and the newer 32 bit CardBus cards. If you want to use CardBus + cards, you need to say Y here and also to "CardBus support" below. + + To use your PC-cards, you will need supporting software from David + Hinds pcmcia-cs package (see the file <file:Documentation/Changes> + for location). Please also read the PCMCIA-HOWTO, available from + <http://www.tldp.org/docs.html#howto>. + + To compile this driver as modules, choose M here: the + modules will be called pcmcia_core and ds. + +#config MATH_EMULATION +# bool "Math emulation support (EXPERIMENTAL)" +# depends on EXPERIMENTAL +# help +# At some point in the future, this will cause floating-point math +# instructions to be emulated by the kernel on machines that lack a +# floating-point math coprocessor. Thrill-seekers and chronically +# sleep-deprived psychotic hacker types can say Y now, everyone else +# should probably wait a while. + +menu "Power management options" +source kernel/power/Kconfig +endmenu + +endmenu + + +menu "Executable formats" + +source "fs/Kconfig.binfmt" + +endmenu + +source "drivers/Kconfig" + +source "fs/Kconfig" + +source "arch/frv/Kconfig.debug" + +source "security/Kconfig" + +source "crypto/Kconfig" + +source "lib/Kconfig" |