nuttx/Kconfig

#
# For a description of the syntax of this configuration file,
# see misc/tools/kconfig-language.txt.
#

mainmenu "Nuttx/$ARCH Configuration"

config APPSDIR
	string
	option env="APPSDIR"

# This is a temporary kludge to let the build system know that we are using the new
# configuration system

config NUTTX_NEWCONFIG
	bool
	default y

menu "Build Setup"
config EXPERIMENTAL
	bool "Prompt for development and/or incomplete code/drivers"

choice
	prompt "Build Host Platform"
	default HOST_LINUX

config HOST_LINUX
	bool "Linux"

config HOST_OSX
	bool "OSX"

config HOST_WINDOWS
	bool "Windows"

config HOST_OTHER
	bool "Other"

endchoice

choice
	prompt "Windows Build Environment"
	default WINDOWS_CYGWIN
	depends on HOST_WINDOWS

config WINDOWS_NATIVE
	bool "Windows Native"
	---help---
		Build natively in a CMD.exe environment with Windows style paths (like C:\cgywin\home)

config WINDOWS_CYGWIN
	bool "Cygwin"
	---help---
		Build natively in a Cygwin environment with POSIX style paths (like /cygdrive/c/cgywin/home)

config WINDOWS_MSYS
	bool "MSYS"
	---help---
		Build natively in a Cygwin environment with POSIX style paths (like /cygdrive/c/cgywin/home)

config WINDOWS_OTHER
	bool "Windows POSIX-like environment"
	---help---
		Build natively in another POSIX-like environment.  Additional support may be necessary

endchoice

config WINDOWS_MKLINK
	bool "Use mklink"
	default n
	depends on WINDOWS_NATIVE
	---help---
		Use the mklink command to set up symbolic links when NuttX is
		configured.  Otherwise, configuration directories will be copied to
		establish the configuration.

		If directories are copied, then some confusion can result ("Which
		version of the file did I modify?").  In that case, it is recommended
		that you re-build using 'make clean_context all'.  That will cause the
		configured directories to be recopied on each build.

		NOTE: This option also (1) that you have administrator privileges, (2)
		that you are using Windows 2000 or better, and (3) that you are using
		the NTFS file system.  Select 'n' is that is not the case.

menu "Build Configuration"

config APPS_DIR
	string "Application directory"
	default "../apps" if !WINDOWS_NATIVE
	default "..\apps" if WINDOWS_NATIVE
	---help---
		Identifies the directory that builds the
		application to link with NuttX.  Default: ../apps This symbol must be assigned
		to the path to the application build directory *relative* to
		the NuttX top build direcory. If you had an application
		directory and the NuttX directory each in separate directory
		trees like this:

			build
			|-nuttx
			|  |
			|  `- Makefile
			`-application
			|
			`- Makefile
		
		Then you would set APPS_DIR=../application.

		The application direction must contain Makefile and this make
		file must support the following targets:
		
		1)libapps$(LIBEXT) (usually libapps.a). libapps.a is a static
		library ( an archive) that contains all of application object
		files.
		
		2)clean. Do whatever is appropriate to clean the application
		directories for a fresh build.
		
		3)distclean. Clean everthing -- auto-generated files, symbolic
		links etc. -- so that the directory contents are the same as
		the contents in your configuration management system.
		This is only done when you change the NuttX configuration.
		
		4)depend. Make or update the application build dependencies.
		
		When this application is invoked it will receive the setting TOPDIR like:
		
		$(MAKE) -C $(CONFIG_APPS_DIR) TOPDIR="$(TOPDIR)" <target>
		
		TOPDIR is the full path to the NuttX directory. It can be used, for
		example, to include makefile fragments (e.g., .config or Make.defs)
		or to set up include file paths.

config BUILD_2PASS
	bool "Two pass build"
	default n
	---help---
		Enables the two pass build options.

		Two-pass build options.  If the 2 pass build option is selected, then these
		options configure the make system build a extra link object. This link object
		is assumed to be an incremental (relative) link object, but could be a static
		library (archive) (some modification to this Makefile would be required if
		PASS1_TARGET generates an archive). Pass 1 1ncremental (relative) link
		objects should be put into the processor-specific source directory (where other
		link objects will be created).  If the pass1 obect is an archive, it could
		go anywhere.

if BUILD_2PASS
config PASS1_TARGET
	string "Pass one target"
	default "all"
	---help---
		The name of the first pass build target.  This
		can be specific build target, a special build target (all, default, etc.)
		or may just be left undefined.

config PASS1_BUILDIR
	string "Pass one build directory"
	default "build"
	---help---
		The path, relative to the top NuttX build
		directory to directory that contains the Makefile to build the
		first pass object.  The Makefile must support the following targets:
		The special target PASS1_TARGET (if defined)
		and the usual depend, clean, and distclean targets.

config PASS1_OBJECT
	string "Pass one object"
	default ""
	---help---
		May be used to include an extra, pass1 object
		into the final link.  This would probably be the object generated
		from the PASS1_TARGET.  It may be available at link time
		in the arch/<architecture>/src directory.

config NUTTX_KERNEL
	bool "NuttX kernel build"
	default n
	---help---
		Builds NuttX as a separately compiled kernel.

config NUTTX_USERSPACE
	hex "Beginning of user-space blob"
	default 0x0
	depends on NUTTX_KERNEL
	---help---
		In the kernel build, the NuttX kernel and the user-space blob are
		built separately linked objects.  NUTTX_USERSPACE provides the
		address where the user-space blob is loaded into memory.  NuttX will
		expect to find and instance of struct userspace_s at this location.

endif
endmenu

menu "Binary Output Formats"

config RRLOAD_BINARY
	bool "rrload binary format"
	default n
	---help---
		Create nuttx.rr in the rrload binary format used with
		BSPs from www.ridgerun.com using the tools/mkimage.sh script.

config INTELHEX_BINARY
	bool "Intel HEX binary format"
	default n
	---help---
		Create the nuttx.hex in the Intel HEX binary format that is
		used with many different loaders. This option will use the GNU objcopy program
		and should not be selected if you are not using the GNU toolchain.

config MOTOROLA_SREC
	bool "Motorola S-Record binary format"
	default n
	---help---
		Create the nuttx.srec in the Motorola S-Record binary format that is
		used with many different loaders. This option will use the GNU objcopy program
		and should not be selected if you are not using the GNU toolchain.

config RAW_BINARY
	bool "Raw binary format"
	default n
	---help---
		Create the nuttx.bin in the raw binary format that is used with many
		different loaders using the GNU objcopy program.  This option
		should not be selected if you are not using the GNU toolchain.
endmenu

menu "Customize Header Files"

config ARCH_STDBOOL_H
	bool "stdbool.h"
	default n
	---help---
		The stdbool.h header file can be found at nuttx/include/stdbool.h.
		However, that header includes logic to redirect the inclusion of an
		architecture specific header file like:

			#ifdef CONFIG_ARCH_STDBOOL_H
			#  include <arch/stdbool.h>
			#else
			...
			#endif

		Recall that that include path, include/arch, is a symbolic link and
		will refer to a version of stdbool.h at nuttx/arch/<architecture>/include/stdbool.h.

config ARCH_MATH_H
	bool "math.h"
	default n
	---help---
		There is also a re-directing version of math.h in the source tree.
		However, it resides out-of-the-way at include/nuttx/math.h because it
		conflicts too often with the system math.h. If ARCH_MATH_H=y is
		defined, however, the top-level makefile will copy the redirecting
		math.h header file from include/nuttx/math.h to include/math.h. math.h
		will then include the architecture-specific version of math.h that you
		must provide at nuttx/arch/>architecture</include/math.h.

			#ifdef CONFIG_ARCH_MATH_H
			#  include <arch/math.h>
			#endif

		So for the architectures that define ARCH_MATH_H=y, include/math.h
		will be the redirecting math.h header file; for the architectures
		that don't select ARCH_MATH_H, the redirecting math.h header file
		will stay out-of-the-way in include/nuttx/.

config ARCH_FLOAT_H
	bool "float.h"
	default n
	---help---
		The float.h header file defines the properties of your floating
		point implementation.  It would always be best to use your
		toolchain's float.h header file but if none is avaiable, a default
		float.h header file will provided if this option is selected.  However
		there is no assurance that the settings in this float.h are actually
		correct for your platform!

config ARCH_STDARG_H
	bool "stdarg.h"
	default n
	---help---
		There is also a redirecting version of stdarg.h in the source tree
		as well. It also resides out-of-the-way at include/nuttx/stdarg.h.
		This is because you should normally use your toolchain's stdarg.h
		file. But sometimes, your toolchain's stdarg.h file may have other
		header file dependencies and so may not be usable in the NuttX build
		environment. In those cases, you may have to create a architecture-
		specific stdarg.h header file at nuttx/arch/<architecture>/include/stdarg.h

		If ARCH_STDARG_H=y is defined, the top-level makefile will copy the
		re-directing stdarg.h header file from include/nuttx/stdarg.h to
		include/stdarg.h. So for the architectures that cannot use their
		toolchain's stdarg.h file, they can use this alternative by defining
		ARCH_STDARG_H=y and providing. If ARCH_STDARG_H, is not defined, then
		the stdarg.h header file will stay out-of-the-way in include/nuttx/.

endmenu

menu "Debug Options"

config DEBUG
	bool "Enable Debug Features"
	default n
	---help---
		Enables built-in debug features.  Selecting this option will (1) Enable
		debug assertions in the code, (2) enable extended parameter testing in
		many functions, and (3) enable support for debug output to the SYSLOG.
		Note that enabling this option by itself does not produce debug output.
		Debug output must also be selected on a subsystem-by-subsystem basis.

config ARCH_HAVE_STACKCHECK
	bool
	default n

if DEBUG
config DEBUG_VERBOSE
	bool "Enable Debug Verbose Output"
	default n
	---help---
		Enables verbose debug output (assuming debug featurses are enabled).
		As a general rule, when DEBUG is enabled only errors will be
		reported in the debug SYSLOG output.  But if you also enable
		DEBUG_VERBOSE, then very chatty (and often annoying) output will be
		generated.  This means there are two levels of debug output:
		errors-only and everything.

comment "Subsystem Debug Options"

config DEBUG_MM
	bool "Memory Manager Debug Output"
	default n
	---help---
		Enable memory management debug SYSLOG output (disabled by default)

config DEBUG_SCHED
	bool "Scheduler Debug Output"
	default n
	---help---
		Enable OS debug SYSLOG output (disabled by default)

config DEBUG_PAGING
	bool "Demand Paging Debug Output"
	default n
	depends on PAGING
	---help---
		Enable demand paging debug SYSLOG output (disabled by default)

config DEBUG_NET
	bool "Network Debug Output"
	default n
	depends on NET
	---help---
		Enable network debug SYSLOG output (disabled by default)

config DEBUG_USB
	bool "USB Debug Output"
	default n
	depends on USBDEV || USBHOST
	---help---
		Enable usb debug SYSLOG output (disabled by default)

config DEBUG_FS
	bool "File System Debug Output"
	default n
	---help---
		Enable file system debug SYSLOG output (disabled by default)

config DEBUG_LIB
	bool "C Library Debug Output"
	default n
	---help---
		Enable C library debug SYSLOG output (disabled by default)

config DEBUG_BINFMT
	bool "Binary Loader Debug Output"
	default n
	---help---
		Enable binary loader debug SYSLOG output (disabled by default)

config DEBUG_GRAPHICS
	bool "Graphics Debug Output"
	default n
	---help---
		Enable NX graphics debug SYSLOG output (disabled by default)

config DEBUG_IRQ
	bool "Interrupt Controller Debug Output"
	default n
	---help---
		Some (but not all) architectures support debug output to verify
		interrupt controller logic.  If supported, then option will enable
		that output.  This may interfere with normal operations!  You
		should *not* enable interrupt controller debug unless you suspect
		that here is a problem with that logic.  On some platforms, this
		option may even cause crashes! Use with care!

config DEBUG_SYSCALL
	bool "SYSCALL Debug Output"
	default n
	depends on NUTTX_KERNEL
	---help---
		Enable very low level output related to system calls.  This gives
		you basically a poor man's version of strace.

config DEBUG_STACK
	bool "Stack usage debug hooks"
	default n
	depends on ARCH_HAVE_STACKCHECK
	---help---
		Enable hooks to check stack usage.  Only supported by a few architectures.

comment "Driver Debug Options"

config DEBUG_LCD
	bool "Low-level LCD Debug Output"
	default n
	depends on LCD
	---help---
		Enable low level debug SYSLOG output from the LCD driver (disabled
		by default).  Support for this debug option is board-specific and
		may not be available for some boards.

config DEBUG_LEDS
	bool "Low-level LED Debug Output"
	default n
	depends on ARCH_HAVE_LEDS
	---help---
		Enable low level debug from board-specific LED logic.  Support for
		this debug option is board-specific and may not be available for
		some boards.

config DEBUG_INPUT
	bool "Input Device Debug Output"
	default n
	depends on INPUT
	---help---
		Enable low level debug SYSLOG output from the input device drivers
		such as mice and touchscreens (disabled by default).  Support for
		this debug option is board-specific and may not be available for
		some boards.

config DEBUG_ANALOG
	bool "Analog Device Debug Output"
	default n
	---help---
		Enable low level debug SYSLOG output from the analog device drivers
		such as A/D and D/A converters (disabled by default).  Support for
		this debug option is architecture-specific and may not be available
		for some MCUs.

config DEBUG_I2C
	bool "I2C Debug Output"
	default n
	depends on I2C
	---help---
		Enable I2C driver debug SYSLOG output (disabled by default).
		Support for this debug option is architecture-specific and may not
		be available for some MCUs.

config DEBUG_SPI
	bool "SPI Debug Output"
	default n
	depends on SPI
	---help---
		Enable I2C driver debug SYSLOG output (disabled by default).
		Support for this debug option is architecture-specific and may not
		be available for some MCUs.

config DEBUG_CAN
	bool "CAN Debug Output"
	default n
	depends on CAN
	---help---
		Enable CAN driver debug SYSLOG output (disabled by default).
		Support for this debug option is architecture-specific and may not
		be available for some MCUs.

config DEBUG_SDIO
	bool "SDIO Debug Output"
	default n
	depends on MMCSD_SDIO
	---help---
		Enable SDIO driver debug SYSLOG output (disabled by default).
		Support for this debug option is architecture-specific and may not
		be available for some MCUs.

config DEBUG_GPIO
	bool "GPIO Debug Output"
	default n
	---help---
		Enable GPIO-releated debug SYSLOG output (disabled by default).
		Support for this debug option is architecture-specific and may not
		be available for some MCUs.

config DEBUG_DMA
	bool "DMA Debug Output"
	default n
	depends on ARCH_DMA
	---help---
		Enable DMA-releated debug SYSLOG output (disabled by default).
		Support for this debug option is architecture-specific and may not
		be available for some MCUs.

config DEBUG_RTC
	bool "RTC Debug Output"
	default n
	depends on RTC
	---help---
		Enable RTC driver debug SYSLOG output (disabled by default).
		Support for this debug option is architecture-specific and may not
		be available for some MCUs.

config DEBUG_WATCHDOG
	bool "Watchdog Timer Debug Output"
	default n
	depends on WATCHDOG
	---help---
		Enable watchdog timer debug SYSLOG output (disabled by default).
		Support for this debug option is architecture-specific and may not
		be available for some MCUs.

config DEBUG_AUDIO
	bool "Audio Device Debug Output"
	default n
	---help---
		Enable low level debug SYSLOG output from the audio subsystem and
		device drivers. (disabled by default).  Support for this debug option
		is architecture-specific and may not be available for some MCUs.

endif

config DEBUG_SYMBOLS
	bool "Generate Debug Symbols"
	default n
	---help---
		Build without optimization and with debug symbols (needed
		for use with a debugger).
endmenu
endmenu

menu "System Type"
source "arch/Kconfig"
endmenu

menu "Board Selection"
source "configs/Kconfig"
endmenu

menu "RTOS Features"
source sched/Kconfig
if NUTTX_KERNEL
source syscall/Kconfig
endif
endmenu

menu "Device Drivers"
source drivers/Kconfig
endmenu

menu "Networking Support"
source net/Kconfig
endmenu

menu "File Systems"
source fs/Kconfig
endmenu

menu "Graphics Support"
source graphics/Kconfig
endmenu

menu "Memory Management"
source mm/Kconfig
endmenu

menu "Audio Support"
source audio/Kconfig
endmenu

menu "Binary Formats"
source binfmt/Kconfig
endmenu

menu "Library Routines"
source libc/Kconfig
source libxx/Kconfig
endmenu

menu "Application Configuration"
source "$APPSDIR/Kconfig"
endmenu