# Kconfig - ARM Cortex-M platform configuration options

#
# Copyright (c) 2014-2015 Wind River Systems, Inc.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#

config ISA_THUMB2
	bool
	# Omit prompt to signify "hidden" option
	default n
	help
	From: http://www.arm.com/products/processors/technologies/instruction-set-architectures.php

	Thumb-2 technology is the instruction set underlying the ARM Cortex
	architecture which provides enhanced levels of performance, energy
	efficiency, and code density for a wide range of embedded
	applications.

	Thumb-2 technology builds on the success of Thumb, the innovative
	high code density instruction set for ARM microprocessor cores, to
	increase the power of the ARM microprocessor core available to
	developers of low cost, high performance systems.

	The technology is backwards compatible with existing ARM and Thumb
	solutions, while significantly extending the features available to
	the Thumb instructions set. This allows more of the application to
	benefit from the best in class code density of Thumb.

	For performance optimised code Thumb-2 technology uses 31 percent
	less memory to reduce system cost, while providing up to 38 percent
	higher performance than existing high density code, which can be used
	to prolong battery-life or to enrich the product feature set. Thumb-2
	technology is featured in the  processor, and in all ARMv7
	architecture-based processors.

config CPU_CORTEX_M3_M4
	bool
	# Omit prompt to signify "hidden" option
	default n
	select ISA_THUMB2
	help
	This option signifies the use of either a Cortex-M3 or Cortex-M4 CPU.

config CPU_CORTEX_M3
	bool
	# Omit prompt to signify "hidden" option
	select CPU_CORTEX_M3_M4
	help
	This option signifies the use of a Cortex-M3 CPU

config CPU_CORTEX_M4
	bool
	# Omit prompt to signify "hidden" option
	select CPU_CORTEX_M3_M4
	help
	This option signifies the use of a Cortex-M4 CPU

menu "ARM Cortex-M options"
	depends on CPU_CORTEX_M

config LDREX_STREX_AVAILABLE
	bool
	default y

config DATA_ENDIANNESS_LITTLE
	bool
	default y
	help
	This is driven by the processor implementation, since it is fixed in
	hardware. The board should set this value to 'n' if the data is
	implemented as big endian.

config STACK_ALIGN_DOUBLE_WORD
	bool
	prompt "Align stacks on double-words (8 octets)"
	default y
	help
	This is needed to conform to AAPCS, the procedure call standard for
	the ARM. It wastes stack space.

config NUM_IRQ_PRIO_BITS
	int
	#hidden option, implemented by board
	help
	Cortex-M chips can implement up to 8 bits of interrupt priorities,
	for a maximum of 256 priorities. Most chips implement fewer than 8.

	The board must define the correct value.

config RUNTIME_NMI
	bool
	prompt "Attach an NMI handler at runtime"
	default n
	help
	The kernel provides a simple NMI handler that simply hangs in a tight
	loop if triggered. This fills the requirement that there must be an
	NMI handler installed when the CPU boots. If a custom handler is
	needed, enable this option and attach it via _NmiHandlerSet().

config FAULT_DUMP
	int
	prompt "Fault dump level"
	default 2
	range 0 2
	help
	Different levels for display information when a fault occurs.

	2: The default. Display specific and verbose information. Consumes
		the most memory (long strings).

	1: Display general and short information. Consumes less memory
		(short strings).

	0: Off.

config XIP
	default y

config SRAM_SIZE
	int "SRAM Size in kB"
	help
	This option specifies the size of the SRAM in kB.  It is normally set by
	the board's defconfig file and the user should generally avoid modifying
	it via the menu configuration.

config SRAM_BASE_ADDRESS
	hex "SRAM Base Address"
	help
	This option specifies the base address of the SRAM on the board.  It is
	normally set by the board's defconfig file and the user should generally
	avoid modifying it via the menu configuration.

config FLASH_SIZE
	int "Flash Size in kB"
	help
	This option specifies the size of the flash in kB.  It is normally set by
	the board's defconfig file and the user should generally avoid modifying
	it via the menu configuration.

config FLASH_BASE_ADDRESS
	hex "Flash Base Address"
	help
	This option specifies the base address of the flash on the board.  It is
	normally set by the board's defconfig file and the user should generally
	avoid modifying it via the menu configuration.
endmenu

menu "ARM Cortex-M3/M4 options"
	depends on CPU_CORTEX_M3_M4

config IRQ_OFFLOAD
	bool "Enable IRQ offload"
	default n
	help
	Enable irq_offload() API which allows functions to be synchronously
	run in interrupt context. Adds some overhead to context switching.
	Mainly useful for test cases.

config SW_ISR_TABLE
	bool
	prompt "Enable software interrupt handler table"
	default y
	help
	Enable an interrupt handler table implemented in software. This
	table, unlike ISRs connected directly in the vector table, allow
	a parameter to be passed to the interrupt handlers. Also, invoking
	the exeception/interrupt exit stub is automatically done.

	This has to be enabled for dynamically connecting interrupt handlers
	at runtime (SW_ISR_TABLE_DYNAMIC).

config SW_ISR_TABLE_DYNAMIC
	bool
	prompt "Allow installing interrupt handlers at runtime"
	depends on SW_ISR_TABLE
	default n
	help
	This option enables irq_connect_dynamic(). It moves the ISR table to
	SRAM so that it is writable. This has the side-effect of removing
	write-protection on the ISR table.

config IRQ_VECTOR_TABLE_CUSTOM
	bool
	prompt "Projects provide a custom static IRQ part of vector table"
	depends on !SW_ISR_TABLE
	default n
	help
	Projects, not the board, provide the IRQ part of the vector table.

	This is the table of interrupt handlers with the best potential
	performance, but is the less flexible.

	The ISRs are installed directly in the vector table, thus are
	directly called by the CPU when an interrupt is taken. This adds
	the least overhead when handling an interrupt.

	Downsides:

	- ISRs cannot have a parameter
	- ISRs cannot be connected at runtime
	- ISRs must notify the kernel manually by invoking _IntExit() when
	  then are about to return.

config IRQ_VECTOR_TABLE_SOC
	bool
	# omit prompt to signify a "hidden" option
	depends on SW_ISR_TABLE || !IRQ_VECTOR_TABLE_CUSTOM
	default y
	help
	Not user-selectable, helps build system logic.

config ZERO_LATENCY_IRQS
	bool
	prompt "Enable zero-latency interrupts"
	default n
	help
	Interrupt locking is done by setting exception masking to priority
	one, thus allowing exception of priority zero to still come in. By
	default, the kernel verifies, via __ASSERT() statements, that the
	interrupt priority is not set to zero when either connecting them or
	setting their priority. Enabling this option disables the check,
	thus allowing setting the priority of interrupts to zero.

	Note that this is a somewhat dangerous option: ISRs of priority zero
	interrupts cannot use any kernel functionality.

config ARCH_HAS_TASK_ABORT
	bool
	# omit prompt to signify a "hidden" option
	default y

config ARCH_HAS_NANO_FIBER_ABORT
	bool
	# omit prompt to signify a "hidden" option
	default y

endmenu