2012-04-06 17:49:35 +02:00
|
|
|
#
|
|
|
|
# For a description of the syntax of this configuration file,
|
2015-06-28 16:08:57 +02:00
|
|
|
# see the file kconfig-language.txt in the NuttX tools repository.
|
2012-04-06 17:49:35 +02:00
|
|
|
#
|
2012-04-11 04:04:59 +02:00
|
|
|
|
|
|
|
choice
|
|
|
|
prompt "CPU Architecture"
|
|
|
|
default ARCH_ARM
|
|
|
|
|
|
|
|
config ARCH_ARM
|
|
|
|
bool "ARM"
|
2021-12-25 16:06:55 +01:00
|
|
|
select ARCH_HAVE_BACKTRACE
|
2012-09-09 17:43:18 +02:00
|
|
|
select ARCH_HAVE_INTERRUPTSTACK
|
2023-07-05 15:43:50 +02:00
|
|
|
select ARCH_HAVE_FORK
|
2013-09-24 19:45:13 +02:00
|
|
|
select ARCH_HAVE_STACKCHECK
|
2014-01-24 15:07:27 +01:00
|
|
|
select ARCH_HAVE_CUSTOMOPT
|
2019-09-16 19:47:26 +02:00
|
|
|
select ARCH_HAVE_STDARG_H
|
2022-03-09 09:34:04 +01:00
|
|
|
select ARCH_HAVE_SETJMP if !ARCH_TOOLCHAIN_IAR
|
2020-07-22 15:21:42 +02:00
|
|
|
select ARCH_HAVE_SYSCALL_HOOKS
|
2021-01-30 20:24:56 +01:00
|
|
|
select ARCH_HAVE_RDWR_MEM_CPU_RUN
|
2023-07-19 23:28:37 +02:00
|
|
|
select ARCH_HAVE_TCBINFO
|
2021-12-03 14:35:39 +01:00
|
|
|
select ARCH_HAVE_THREAD_LOCAL
|
2012-04-11 04:04:59 +02:00
|
|
|
---help---
|
|
|
|
The ARM architectures
|
|
|
|
|
2022-06-18 13:26:10 +02:00
|
|
|
config ARCH_ARM64
|
|
|
|
bool "ARM64"
|
2023-03-17 08:49:43 +01:00
|
|
|
select ALARM_ARCH
|
2022-06-18 13:26:10 +02:00
|
|
|
select ARCH_HAVE_BACKTRACE
|
|
|
|
select ARCH_HAVE_INTERRUPTSTACK
|
|
|
|
select ARCH_HAVE_STACKCHECK
|
|
|
|
select ARCH_HAVE_CUSTOMOPT
|
|
|
|
select ARCH_HAVE_STDARG_H
|
2023-07-06 08:10:58 +02:00
|
|
|
select ARCH_HAVE_SETJMP
|
2022-06-18 13:26:10 +02:00
|
|
|
select ARCH_HAVE_SYSCALL_HOOKS
|
|
|
|
select ARCH_HAVE_RDWR_MEM_CPU_RUN
|
2023-07-19 23:28:37 +02:00
|
|
|
select ARCH_HAVE_TCBINFO
|
2022-06-18 13:26:10 +02:00
|
|
|
select ARCH_HAVE_THREAD_LOCAL
|
2023-07-21 09:34:55 +02:00
|
|
|
select ARCH_HAVE_PERF_EVENTS
|
2023-03-17 08:49:43 +01:00
|
|
|
select ONESHOT
|
2022-06-18 13:26:10 +02:00
|
|
|
---help---
|
|
|
|
The ARM64 architectures
|
|
|
|
|
2012-04-11 04:04:59 +02:00
|
|
|
config ARCH_AVR
|
|
|
|
bool "AVR"
|
2012-08-17 16:07:48 +02:00
|
|
|
select ARCH_NOINTC
|
2012-09-09 17:43:18 +02:00
|
|
|
select ARCH_HAVE_INTERRUPTSTACK
|
2014-01-24 15:07:27 +01:00
|
|
|
select ARCH_HAVE_CUSTOMOPT
|
2012-04-11 04:04:59 +02:00
|
|
|
---help---
|
2012-08-14 00:27:06 +02:00
|
|
|
Atmel 8-bit bit AVR and 32-bit AVR32 architectures
|
2012-04-11 04:04:59 +02:00
|
|
|
|
|
|
|
config ARCH_HC
|
|
|
|
bool "Freescale HC"
|
2012-08-17 16:07:48 +02:00
|
|
|
select ARCH_NOINTC
|
2012-09-09 17:43:18 +02:00
|
|
|
select ARCH_HAVE_INTERRUPTSTACK
|
2012-04-11 04:04:59 +02:00
|
|
|
---help---
|
|
|
|
Freescale HC architectures (M9S12)
|
|
|
|
|
|
|
|
config ARCH_MIPS
|
|
|
|
bool "MIPS"
|
2012-09-09 17:43:18 +02:00
|
|
|
select ARCH_HAVE_INTERRUPTSTACK
|
2014-01-24 15:07:27 +01:00
|
|
|
select ARCH_HAVE_CUSTOMOPT
|
2012-04-11 04:04:59 +02:00
|
|
|
---help---
|
|
|
|
MIPS architectures (PIC32)
|
|
|
|
|
2016-11-01 01:41:36 +01:00
|
|
|
config ARCH_MISOC
|
|
|
|
bool "MISOC"
|
|
|
|
select ARCH_HAVE_INTERRUPTSTACK
|
|
|
|
select ARCH_HAVE_CUSTOMOPT
|
2019-09-16 19:47:26 +02:00
|
|
|
select ARCH_HAVE_STDARG_H
|
2016-11-01 01:41:36 +01:00
|
|
|
---help---
|
|
|
|
MISOC
|
|
|
|
|
2016-08-06 22:03:38 +02:00
|
|
|
config ARCH_RENESAS
|
2012-08-17 16:07:48 +02:00
|
|
|
bool "Renesas"
|
|
|
|
select ARCH_NOINTC
|
2012-09-09 17:43:18 +02:00
|
|
|
select ARCH_HAVE_INTERRUPTSTACK
|
2012-04-11 04:04:59 +02:00
|
|
|
---help---
|
|
|
|
Renesas architectures (SH and M16C).
|
|
|
|
|
2016-10-16 17:47:07 +02:00
|
|
|
config ARCH_RISCV
|
|
|
|
bool "RISC-V"
|
2021-12-25 16:06:55 +01:00
|
|
|
select ARCH_HAVE_BACKTRACE
|
2023-05-16 09:41:49 +02:00
|
|
|
select ARCH_HAVE_CPUINFO
|
2016-10-16 17:47:07 +02:00
|
|
|
select ARCH_HAVE_INTERRUPTSTACK
|
2019-11-28 21:37:24 +01:00
|
|
|
select ARCH_HAVE_STACKCHECK
|
2023-07-05 15:43:50 +02:00
|
|
|
select ARCH_HAVE_FORK
|
2016-10-16 17:47:07 +02:00
|
|
|
select ARCH_HAVE_CUSTOMOPT
|
2022-03-08 14:17:58 +01:00
|
|
|
select ARCH_HAVE_SETJMP
|
2019-09-16 19:47:26 +02:00
|
|
|
select ARCH_HAVE_STDARG_H
|
2020-07-22 15:21:42 +02:00
|
|
|
select ARCH_HAVE_SYSCALL_HOOKS
|
2021-01-30 20:24:56 +01:00
|
|
|
select ARCH_HAVE_RDWR_MEM_CPU_RUN
|
2023-07-19 23:28:37 +02:00
|
|
|
select ARCH_HAVE_TCBINFO
|
2021-12-12 15:41:32 +01:00
|
|
|
select ARCH_HAVE_THREAD_LOCAL
|
2024-05-06 07:54:09 +02:00
|
|
|
select ARCH_HAVE_POWEROFF
|
2023-06-07 13:02:48 +02:00
|
|
|
select ARCH_HAVE_LAZYFPU if ARCH_HAVE_FPU
|
2016-10-16 17:47:07 +02:00
|
|
|
---help---
|
|
|
|
RISC-V 32 and 64-bit RV32 / RV64 architectures.
|
|
|
|
|
2012-04-11 04:04:59 +02:00
|
|
|
config ARCH_SIM
|
|
|
|
bool "Simulation"
|
2021-12-25 16:06:55 +01:00
|
|
|
select ARCH_HAVE_BACKTRACE
|
2016-02-11 00:29:04 +01:00
|
|
|
select ARCH_HAVE_MULTICPU
|
2020-02-12 18:53:05 +01:00
|
|
|
select ARCH_HAVE_RTC_SUBSECONDS
|
2020-07-14 05:19:58 +02:00
|
|
|
select ARCH_HAVE_SERIAL_TERMIOS
|
2022-03-07 13:08:12 +01:00
|
|
|
select ARCH_HAVE_SYSCALL_HOOKS
|
2014-08-07 19:39:16 +02:00
|
|
|
select ARCH_HAVE_TICKLESS
|
2015-07-04 15:22:38 +02:00
|
|
|
select ARCH_HAVE_POWEROFF
|
2019-03-04 21:22:50 +01:00
|
|
|
select ARCH_HAVE_TESTSET
|
2024-05-23 10:59:01 +02:00
|
|
|
select ARCH_HAVE_FORK if !HOST_WINDOWS
|
2021-04-05 07:01:15 +02:00
|
|
|
select ARCH_HAVE_SETJMP
|
2022-03-14 12:20:08 +01:00
|
|
|
select ARCH_HAVE_CUSTOMOPT
|
2023-07-19 23:28:37 +02:00
|
|
|
select ARCH_HAVE_TCBINFO
|
2023-04-23 05:00:46 +02:00
|
|
|
select ARCH_HAVE_TEXT_HEAP
|
2021-04-05 07:01:15 +02:00
|
|
|
select ARCH_SETJMP_H
|
2020-02-06 15:45:05 +01:00
|
|
|
select ALARM_ARCH
|
|
|
|
select ONESHOT
|
2016-06-21 17:59:09 +02:00
|
|
|
select SERIAL_CONSOLE
|
2021-02-02 10:50:56 +01:00
|
|
|
select SERIAL_IFLOWCONTROL
|
2023-02-03 11:44:03 +01:00
|
|
|
select SCHED_HPWORK
|
2023-06-15 13:51:28 +02:00
|
|
|
select ARCH_HAVE_CPUINFO
|
2012-04-11 04:04:59 +02:00
|
|
|
---help---
|
2020-02-23 09:50:23 +01:00
|
|
|
Linux/Cygwin user-mode simulation.
|
2012-04-11 04:04:59 +02:00
|
|
|
|
2020-03-04 13:56:08 +01:00
|
|
|
config ARCH_X86
|
2012-04-11 04:04:59 +02:00
|
|
|
bool "x86"
|
2023-07-19 23:28:37 +02:00
|
|
|
select ARCH_HAVE_TCBINFO
|
2012-04-11 04:04:59 +02:00
|
|
|
---help---
|
2020-03-04 13:56:08 +01:00
|
|
|
Intel x86 architectures.
|
2020-03-04 00:29:13 +01:00
|
|
|
|
|
|
|
config ARCH_X86_64
|
|
|
|
bool "x86_64"
|
2023-07-19 23:28:37 +02:00
|
|
|
select ARCH_HAVE_TCBINFO
|
2024-02-26 17:31:05 +01:00
|
|
|
select ARCH_HAVE_FPU
|
|
|
|
select ARCH_HAVE_DPFPU
|
2024-04-03 11:54:31 +02:00
|
|
|
select ARCH_HAVE_MULTICPU
|
2024-02-23 14:27:23 +01:00
|
|
|
select ARCH_HAVE_TESTSET
|
2024-04-22 12:52:55 +02:00
|
|
|
select ARCH_HAVE_INTERRUPTSTACK
|
2024-04-25 10:59:38 +02:00
|
|
|
select ARCH_HAVE_CUSTOMOPT
|
2020-05-31 20:41:11 +02:00
|
|
|
select LIBC_ARCH_ELF_64BIT if LIBC_ARCH_ELF
|
2024-05-22 16:42:23 +02:00
|
|
|
select ARCH_TOOLCHAIN_GNU
|
2020-03-04 00:29:13 +01:00
|
|
|
---help---
|
|
|
|
x86-64 architectures.
|
2012-04-11 04:04:59 +02:00
|
|
|
|
2016-10-12 22:50:28 +02:00
|
|
|
config ARCH_XTENSA
|
|
|
|
bool "Xtensa"
|
2021-12-25 16:06:55 +01:00
|
|
|
select ARCH_HAVE_BACKTRACE
|
2023-04-26 15:33:36 +02:00
|
|
|
select ARCH_HAVE_CPUINFO
|
2020-10-12 13:49:58 +02:00
|
|
|
select ARCH_HAVE_INTERRUPTSTACK
|
2016-12-23 22:51:33 +01:00
|
|
|
select ARCH_HAVE_STACKCHECK
|
2016-12-17 16:07:24 +01:00
|
|
|
select ARCH_HAVE_CUSTOMOPT
|
2023-07-19 23:28:37 +02:00
|
|
|
select ARCH_HAVE_TCBINFO
|
2021-08-09 14:48:23 +02:00
|
|
|
select ARCH_HAVE_STDARG_H
|
2021-11-02 10:25:03 +01:00
|
|
|
select ARCH_HAVE_SETJMP if ARCH_TOOLCHAIN_GNU
|
2021-11-26 14:45:46 +01:00
|
|
|
select ARCH_HAVE_SYSCALL_HOOKS
|
2023-07-21 09:34:55 +02:00
|
|
|
select ARCH_HAVE_PERF_EVENTS
|
2016-10-12 22:50:28 +02:00
|
|
|
---help---
|
2016-10-13 22:37:28 +02:00
|
|
|
Cadence® Tensilica® Xtensa® actictures.
|
2016-10-12 22:50:28 +02:00
|
|
|
|
2012-04-11 04:04:59 +02:00
|
|
|
config ARCH_Z16
|
|
|
|
bool "ZNEO"
|
2012-09-06 01:02:43 +02:00
|
|
|
select ARCH_HAVE_HEAP2
|
2012-04-11 04:04:59 +02:00
|
|
|
---help---
|
|
|
|
ZiLOG ZNEO 16-bit architectures (z16f).
|
|
|
|
|
|
|
|
config ARCH_Z80
|
|
|
|
bool "z80"
|
2012-09-06 01:02:43 +02:00
|
|
|
select ARCH_HAVE_HEAP2
|
2012-04-11 04:04:59 +02:00
|
|
|
---help---
|
|
|
|
ZiLOG 8-bit architectures (z80, ez80, z8).
|
|
|
|
|
2018-04-26 19:22:28 +02:00
|
|
|
config ARCH_OR1K
|
|
|
|
bool "OpenRISC"
|
|
|
|
---help---
|
|
|
|
OpenRISC architectures.
|
|
|
|
|
2022-01-15 07:01:10 +01:00
|
|
|
config ARCH_SPARC
|
|
|
|
bool "SPARC"
|
|
|
|
select ARCH_HAVE_INTERRUPTSTACK
|
|
|
|
select ARCH_HAVE_CUSTOMOPT
|
2023-07-19 23:28:37 +02:00
|
|
|
select ARCH_HAVE_TCBINFO
|
2022-01-15 07:01:10 +01:00
|
|
|
---help---
|
|
|
|
SPARC architectures (SPARC V8)
|
|
|
|
|
2024-02-18 08:54:41 +01:00
|
|
|
config ARCH_TRICORE
|
|
|
|
bool "Infineon TriCore"
|
|
|
|
select ARCH_HAVE_INTERRUPTSTACK
|
|
|
|
select ARCH_HAVE_STACKCHECK
|
|
|
|
select ARCH_HAVE_CUSTOMOPT
|
|
|
|
select ARCH_HAVE_TCBINFO
|
|
|
|
---help---
|
|
|
|
Infineon 32-bit AURIX TriCore architectures
|
|
|
|
|
2012-04-11 04:04:59 +02:00
|
|
|
endchoice
|
|
|
|
|
|
|
|
config ARCH
|
|
|
|
string
|
2016-08-06 22:03:38 +02:00
|
|
|
default "arm" if ARCH_ARM
|
2022-06-18 13:26:10 +02:00
|
|
|
default "arm64" if ARCH_ARM64
|
2016-08-06 22:03:38 +02:00
|
|
|
default "avr" if ARCH_AVR
|
|
|
|
default "hc" if ARCH_HC
|
|
|
|
default "mips" if ARCH_MIPS
|
2016-11-01 01:41:36 +01:00
|
|
|
default "misoc" if ARCH_MISOC
|
2016-08-06 22:03:38 +02:00
|
|
|
default "renesas" if ARCH_RENESAS
|
2016-10-16 17:47:07 +02:00
|
|
|
default "risc-v" if ARCH_RISCV
|
2016-08-06 22:03:38 +02:00
|
|
|
default "sim" if ARCH_SIM
|
|
|
|
default "x86" if ARCH_X86
|
2023-03-19 16:41:18 +01:00
|
|
|
default "x86_64" if ARCH_X86_64
|
2016-10-12 22:50:28 +02:00
|
|
|
default "xtensa" if ARCH_XTENSA
|
2016-08-06 22:03:38 +02:00
|
|
|
default "z16" if ARCH_Z16
|
|
|
|
default "z80" if ARCH_Z80
|
2018-04-26 19:22:28 +02:00
|
|
|
default "or1k" if ARCH_OR1K
|
2022-01-15 07:01:10 +01:00
|
|
|
default "sparc" if ARCH_SPARC
|
2024-02-18 08:54:41 +01:00
|
|
|
default "tricore" if ARCH_TRICORE
|
2012-04-11 04:04:59 +02:00
|
|
|
|
2021-07-20 13:10:10 +02:00
|
|
|
source "arch/arm/Kconfig"
|
2022-06-18 13:26:10 +02:00
|
|
|
source "arch/arm64/Kconfig"
|
2021-07-20 13:10:10 +02:00
|
|
|
source "arch/avr/Kconfig"
|
|
|
|
source "arch/hc/Kconfig"
|
|
|
|
source "arch/mips/Kconfig"
|
|
|
|
source "arch/misoc/Kconfig"
|
|
|
|
source "arch/renesas/Kconfig"
|
|
|
|
source "arch/risc-v/Kconfig"
|
|
|
|
source "arch/sim/Kconfig"
|
|
|
|
source "arch/x86/Kconfig"
|
|
|
|
source "arch/x86_64/Kconfig"
|
|
|
|
source "arch/xtensa/Kconfig"
|
|
|
|
source "arch/z16/Kconfig"
|
|
|
|
source "arch/z80/Kconfig"
|
|
|
|
source "arch/or1k/Kconfig"
|
2022-01-15 07:01:10 +01:00
|
|
|
source "arch/sparc/Kconfig"
|
2024-02-18 08:54:41 +01:00
|
|
|
source "arch/tricore/Kconfig"
|
2012-08-17 16:07:48 +02:00
|
|
|
|
2020-10-15 05:29:59 +02:00
|
|
|
config ARCH_CHIP_CUSTOM
|
2023-09-24 13:26:13 +02:00
|
|
|
bool "Custom Chip Support"
|
2020-10-15 05:29:59 +02:00
|
|
|
default n
|
|
|
|
|
|
|
|
if ARCH_CHIP_CUSTOM
|
|
|
|
menu "Custom Chip Configuration"
|
|
|
|
|
|
|
|
config ARCH_CHIP_CUSTOM_NAME
|
|
|
|
string "Custom chip name"
|
|
|
|
default ""
|
|
|
|
---help---
|
|
|
|
This is a name for the chip. It is not used except to return the
|
|
|
|
information via the NSH uname command.
|
|
|
|
|
|
|
|
config ARCH_CHIP_CUSTOM_DIR
|
|
|
|
string "Custom chip directory"
|
|
|
|
default ""
|
|
|
|
---help---
|
|
|
|
If the custom chip configuration is selected, then it is necessary
|
|
|
|
to also tell the build system where it can find the chip directory
|
|
|
|
for the custom chip.
|
|
|
|
|
|
|
|
In this case, the chip directory is assumed to lie outside the
|
|
|
|
NuttX directory. The provided path must then be a full, absolute
|
|
|
|
path to some location outside of the NuttX source tree (like
|
|
|
|
"~/projects/mychip").
|
|
|
|
|
|
|
|
config ARCH_CHIP_CUSTOM_DIR_RELPATH
|
|
|
|
bool "Relative custom chip directory"
|
|
|
|
default y
|
|
|
|
---help---
|
|
|
|
Specifies that the chip directory is relative to the NuttX directory.
|
|
|
|
|
|
|
|
endmenu # Custom Chip Configuration
|
|
|
|
endif #ARCH_CHIP_CUSTOM
|
|
|
|
|
2023-02-07 06:56:13 +01:00
|
|
|
source "$BINDIR/arch/dummy/Kconfig"
|
2020-10-15 05:29:59 +02:00
|
|
|
|
2017-05-14 00:01:38 +02:00
|
|
|
config ARCH_TOOLCHAIN_IAR
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
2017-05-13 19:44:12 +02:00
|
|
|
config ARCH_TOOLCHAIN_GNU
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
2022-04-19 12:26:33 +02:00
|
|
|
config ARCH_TOOLCHAIN_CLANG
|
|
|
|
bool
|
|
|
|
select ARCH_TOOLCHAIN_GNU
|
|
|
|
default n
|
|
|
|
|
2024-02-18 08:37:51 +01:00
|
|
|
config ARCH_TOOLCHAIN_TASKING
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
2024-06-20 08:58:19 +02:00
|
|
|
config ARCH_TOOLCHAIN_GHS
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
2018-08-24 16:30:01 +02:00
|
|
|
config ARCH_GNU_NO_WEAKFUNCTIONS
|
|
|
|
bool
|
|
|
|
depends on ARCH_TOOLCHAIN_GNU
|
|
|
|
default n
|
|
|
|
---help---
|
|
|
|
Disable support for weak functions.
|
|
|
|
|
2020-02-17 13:19:25 +01:00
|
|
|
config ARCH_SIZET_LONG
|
|
|
|
bool "size_t is type long"
|
|
|
|
default n
|
|
|
|
---help---
|
|
|
|
size_t may be type long or type int. This matters for some
|
|
|
|
C++ library routines because the NuttX size_t might not have
|
|
|
|
the same underlying type as your toolchain's size_t.
|
|
|
|
|
2021-10-26 08:57:15 +02:00
|
|
|
config ARCH_COVERAGE
|
|
|
|
bool "Enable code coverage analysis"
|
|
|
|
select HAVE_CXXINITIALIZE
|
|
|
|
default n
|
|
|
|
---help---
|
|
|
|
Generate code coverage
|
|
|
|
|
2022-08-20 00:38:35 +02:00
|
|
|
config ARCH_COVERAGE_ALL
|
|
|
|
bool "Enable code coverage for the entire image"
|
|
|
|
depends on ARCH_COVERAGE
|
2023-07-15 18:44:32 +02:00
|
|
|
default n
|
2022-08-20 00:38:35 +02:00
|
|
|
---help---
|
|
|
|
This option activates code coverage instrumentation for the
|
|
|
|
entire image. If you don't enable this option, you have to
|
|
|
|
explicitly specify "-fprofile-generate -ftest-coverage" for
|
|
|
|
the files/directories you want to check. Enabling this option
|
|
|
|
will get image size increased and performance decreased
|
|
|
|
significantly.
|
|
|
|
|
2023-10-08 12:20:43 +02:00
|
|
|
config ARCH_INSTRUMENT_ALL
|
|
|
|
bool "Instrument All"
|
|
|
|
default n
|
|
|
|
---help---
|
|
|
|
Add instrument to all source files. we can use instrument_register
|
|
|
|
to register the instrument function.
|
|
|
|
|
2012-08-17 16:07:48 +02:00
|
|
|
comment "Architecture Options"
|
|
|
|
|
|
|
|
config ARCH_NOINTC
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
2013-01-14 23:06:19 +01:00
|
|
|
config ARCH_VECNOTIRQ
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
2018-08-25 17:10:30 +02:00
|
|
|
config ARCH_HAVE_IRQTRIGGER
|
2018-08-24 16:24:38 +02:00
|
|
|
bool
|
|
|
|
default n
|
|
|
|
depends on !ARCH_NOINTC
|
|
|
|
|
2012-09-11 00:26:37 +02:00
|
|
|
config ARCH_DMA
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
2023-09-29 11:29:18 +02:00
|
|
|
config ARCH_DMA_NO_FLASH_TRANSFER
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
2013-12-20 15:42:54 +01:00
|
|
|
config ARCH_HAVE_IRQPRIO
|
2012-11-29 19:44:02 +01:00
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
2019-03-19 17:37:13 +01:00
|
|
|
config ARCH_ICACHE
|
2014-07-27 18:03:33 +02:00
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
2021-10-19 06:15:43 +02:00
|
|
|
config ARCH_ICACHE_LOCK
|
|
|
|
bool
|
|
|
|
depends on ARCH_ICACHE
|
|
|
|
default n
|
|
|
|
|
2019-03-19 17:37:13 +01:00
|
|
|
config ARCH_DCACHE
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
2021-10-19 06:15:43 +02:00
|
|
|
config ARCH_DCACHE_LOCK
|
|
|
|
bool
|
|
|
|
depends on ARCH_DCACHE
|
|
|
|
default n
|
|
|
|
|
2019-03-19 17:37:13 +01:00
|
|
|
config ARCH_L2CACHE
|
2014-08-24 22:12:45 +02:00
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
2014-08-24 14:42:11 +02:00
|
|
|
config ARCH_HAVE_ADDRENV
|
2012-12-11 19:04:04 +01:00
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
2014-08-24 20:54:37 +02:00
|
|
|
config ARCH_NEED_ADDRENV_MAPPING
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
2021-06-25 16:07:23 +02:00
|
|
|
config ARCH_HAVE_EXTRA_HEAPS
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
---help---
|
|
|
|
Special memory regions used as separate heaps
|
|
|
|
|
2021-06-18 01:47:45 +02:00
|
|
|
config ARCH_HAVE_TEXT_HEAP
|
2021-06-25 16:07:23 +02:00
|
|
|
bool
|
2020-03-09 05:03:49 +01:00
|
|
|
default n
|
2021-06-25 16:07:23 +02:00
|
|
|
---help---
|
|
|
|
Special memory region for dynamic code loading
|
2020-03-09 05:03:49 +01:00
|
|
|
|
2024-05-20 05:11:01 +02:00
|
|
|
config ARCH_HAVE_TEXT_HEAP_SEPARATE_DATA_ADDRESS
|
2024-05-15 02:23:13 +02:00
|
|
|
bool
|
|
|
|
default n
|
|
|
|
---help---
|
|
|
|
Textheap might have separate instruction/data mappings
|
|
|
|
|
2024-05-20 05:11:01 +02:00
|
|
|
config ARCH_HAVE_TEXT_HEAP_WORD_ALIGNED_READ
|
2024-05-15 02:23:13 +02:00
|
|
|
bool
|
|
|
|
default n
|
|
|
|
---help---
|
|
|
|
Loads from the instruction mapping of textheap need to be word-aligned
|
|
|
|
|
2023-10-05 03:27:10 +02:00
|
|
|
config ARCH_HAVE_DATA_HEAP
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
---help---
|
|
|
|
Special memory region for dynamic data loading
|
|
|
|
|
2023-08-22 19:11:24 +02:00
|
|
|
config ARCH_HAVE_COPY_SECTION
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
---help---
|
|
|
|
Section copying for dynamic code loading
|
|
|
|
|
2016-02-11 00:30:29 +01:00
|
|
|
config ARCH_HAVE_MULTICPU
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
2023-07-05 15:43:50 +02:00
|
|
|
config ARCH_HAVE_FORK
|
2013-01-07 22:41:20 +01:00
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
2019-03-19 17:26:15 +01:00
|
|
|
config ARCH_HAVE_FPU
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
|
|
|
config ARCH_HAVE_DPFPU
|
|
|
|
bool
|
|
|
|
default n
|
2022-02-28 10:26:15 +01:00
|
|
|
select ARCH_HAVE_FPU
|
2019-03-19 17:26:15 +01:00
|
|
|
|
2024-01-15 13:48:09 +01:00
|
|
|
config ARCH_HAVE_QPFPU
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
select ARCH_HAVE_DPFPU
|
|
|
|
|
2023-06-07 13:02:48 +02:00
|
|
|
config ARCH_HAVE_LAZYFPU
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
depends on ARCH_HAVE_FPU
|
|
|
|
|
2013-07-19 19:43:04 +02:00
|
|
|
config ARCH_HAVE_MMU
|
|
|
|
bool
|
2014-01-28 17:42:49 +01:00
|
|
|
default n
|
|
|
|
|
2014-08-29 22:47:22 +02:00
|
|
|
config ARCH_HAVE_MPU
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
2014-01-28 17:42:49 +01:00
|
|
|
config ARCH_NAND_HWECC
|
|
|
|
bool
|
|
|
|
default n
|
2013-07-19 19:43:04 +02:00
|
|
|
|
2014-04-30 23:32:06 +02:00
|
|
|
config ARCH_HAVE_EXTCLK
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
2015-07-03 14:53:51 +02:00
|
|
|
config ARCH_HAVE_POWEROFF
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
2017-11-13 16:08:39 +01:00
|
|
|
config ARCH_HAVE_PROGMEM
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
2021-03-01 15:59:14 +01:00
|
|
|
config ARCH_HAVE_PROGMEM_READ
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
depends on ARCH_HAVE_PROGMEM
|
|
|
|
|
2015-07-04 18:39:24 +02:00
|
|
|
config ARCH_HAVE_RESET
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
2019-03-04 21:22:50 +01:00
|
|
|
config ARCH_HAVE_TESTSET
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
2021-12-03 14:35:39 +01:00
|
|
|
config ARCH_HAVE_THREAD_LOCAL
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
2018-02-04 19:22:03 +01:00
|
|
|
config ARCH_HAVE_FETCHADD
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
2017-04-21 16:45:57 +02:00
|
|
|
config ARCH_HAVE_RTC_SUBSECONDS
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
2020-06-16 16:02:03 +02:00
|
|
|
config ARCH_HAVE_SYSCALL_HOOKS
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
---help---
|
|
|
|
Indicates that the architecture supports the system call hooks as
|
|
|
|
required if CONFIG_SCHED_INSTRUMENTATION_SYSCALL is enabled. Refer
|
|
|
|
to sched/Kconfig for additional information.
|
|
|
|
|
2021-07-30 06:15:43 +02:00
|
|
|
config ARCH_HAVE_BACKTRACE
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
2023-09-06 14:25:56 +02:00
|
|
|
config ARCH_HAVE_DEBUG
|
|
|
|
bool "Architecture have debug support"
|
|
|
|
default n
|
|
|
|
|
2023-07-21 09:34:55 +02:00
|
|
|
config ARCH_HAVE_PERF_EVENTS
|
|
|
|
bool
|
|
|
|
default n
|
2023-08-08 05:12:41 +02:00
|
|
|
---help---
|
|
|
|
The architecture supports hardware performance counting.
|
|
|
|
|
|
|
|
config ARCH_PERF_EVENTS
|
|
|
|
bool "Configure hardware performance counting"
|
2024-02-01 05:49:33 +01:00
|
|
|
default y if SCHED_CRITMONITOR || SCHED_IRQMONITOR || RPMSG_PING || SEGGER_SYSVIEW
|
2023-09-29 16:18:46 +02:00
|
|
|
default n
|
2023-08-08 05:12:41 +02:00
|
|
|
depends on ARCH_HAVE_PERF_EVENTS
|
2023-07-21 09:34:55 +02:00
|
|
|
---help---
|
|
|
|
Enable hardware performance counter support for perf events. If
|
|
|
|
disabled, perf events will use software events only.
|
|
|
|
|
2021-09-24 12:25:17 +02:00
|
|
|
config ARCH_HAVE_BOOTLOADER
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
2023-03-15 13:48:40 +01:00
|
|
|
config ARCH_HAVE_CPUINFO
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
2023-07-19 23:28:37 +02:00
|
|
|
config ARCH_HAVE_TCBINFO
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
2023-06-27 02:03:20 +02:00
|
|
|
config ARCH_HAVE_ELF_EXECUTABLE
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
2023-07-30 16:17:58 +02:00
|
|
|
config ARCH_HAVE_TRUSTZONE
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
---help---
|
|
|
|
Automatically selected to indicate that the ARM CPU supports
|
|
|
|
TrustZone.
|
|
|
|
|
|
|
|
choice
|
|
|
|
prompt "TrustZone Configuration"
|
2024-03-12 10:45:45 +01:00
|
|
|
default ARCH_TRUSTZONE_DISABLED
|
2023-07-30 16:17:58 +02:00
|
|
|
depends on ARCH_HAVE_TRUSTZONE
|
|
|
|
|
2024-03-12 10:45:45 +01:00
|
|
|
config ARCH_TRUSTZONE_DISABLED
|
|
|
|
bool "TrustZone disabled, all CPUs operate in secure state"
|
|
|
|
|
2023-07-30 16:17:58 +02:00
|
|
|
config ARCH_TRUSTZONE_SECURE
|
2024-03-12 10:45:45 +01:00
|
|
|
bool "TrustZone enabled, all CPUs operate secure state"
|
2023-07-30 16:17:58 +02:00
|
|
|
|
|
|
|
config ARCH_TRUSTZONE_NONSECURE
|
2024-03-12 10:45:45 +01:00
|
|
|
bool "TrustZone enabled, all CPUs operate non-secure state"
|
2023-07-30 16:17:58 +02:00
|
|
|
|
|
|
|
endchoice # TrustZone Configuration
|
|
|
|
|
2019-03-19 17:26:15 +01:00
|
|
|
config ARCH_FPU
|
|
|
|
bool "FPU support"
|
|
|
|
default y
|
|
|
|
depends on ARCH_HAVE_FPU
|
|
|
|
---help---
|
|
|
|
Build in support for the Floating Point Unit (FPU).
|
|
|
|
Check your chip specifications first; not all chips support the FPU.
|
|
|
|
|
|
|
|
config ARCH_DPFPU
|
|
|
|
bool "Double precision FPU support"
|
|
|
|
default y
|
|
|
|
depends on ARCH_FPU && ARCH_HAVE_DPFPU
|
|
|
|
---help---
|
|
|
|
Enable toolchain support for double precision (64-bit) floating
|
|
|
|
point if both the toolchain and the hardware support it.
|
|
|
|
|
2024-01-15 13:48:09 +01:00
|
|
|
config ARCH_QPFPU
|
|
|
|
bool "Quad-Precision FPU support"
|
|
|
|
default y
|
|
|
|
depends on ARCH_FPU && ARCH_HAVE_DPFPU && ARCH_HAVE_QPFPU
|
|
|
|
---help---
|
|
|
|
Enable toolchain support for quadruple precision (128 bits or 16 bytes) floating
|
|
|
|
point if both the toolchain and the hardware support it.
|
|
|
|
|
2023-06-07 13:02:48 +02:00
|
|
|
config ARCH_LAZYFPU
|
|
|
|
bool "Enable lazy FPU state save / restore"
|
|
|
|
default n
|
|
|
|
depends on ARCH_FPU && ARCH_HAVE_LAZYFPU
|
|
|
|
---help---
|
|
|
|
Enable lazy FPU state save and restore. Normally FPU state is saved
|
|
|
|
and restored with the integer context registers, if the task is using
|
|
|
|
FPU. The state is typically saved into the task's user stack upon
|
|
|
|
exception entry or context switch out, and restored when the
|
|
|
|
exception returns or context switches back in.
|
|
|
|
|
|
|
|
As the kernel does not use FPU, this can be optimized with the help
|
|
|
|
of the FPU hardware status and a bit of code logic inside the kernel.
|
|
|
|
The logic keeps track of the FPU state, which can be "unused",
|
|
|
|
"dirty" or "clean". A clean state means the FPU has not been used
|
|
|
|
since the last state save, while the dirty state indicates that the
|
|
|
|
FPU has been used.
|
|
|
|
|
|
|
|
The optimization saves / restores FPU registers only if:
|
|
|
|
- A context change has happened, save and restore does not happen
|
|
|
|
during exception entry / return to the same task
|
|
|
|
- FPU is in use (state is not unused) and
|
|
|
|
- FPU status is dirty, i.e. FPU has been used after the last
|
|
|
|
- FPU restore happens when status is in dirty or clean
|
|
|
|
|
|
|
|
This saves CPU time as the FPU registers do not have to be moved in
|
|
|
|
and out when handling an exception that does not result in a context
|
|
|
|
switch.
|
|
|
|
|
|
|
|
The tradeoff with the lazy FPU feature is that it requires a static
|
|
|
|
memory allocation from the task's TCB to store the FPU registers,
|
|
|
|
while the non-lazy style can use stack memory for storing the FPU
|
|
|
|
registers, saving memory as the stack frame for the FPU registers can
|
|
|
|
be skipped if the FPU is not in use.
|
|
|
|
|
2014-08-29 22:47:22 +02:00
|
|
|
config ARCH_USE_MMU
|
|
|
|
bool "Enable MMU"
|
|
|
|
default n
|
|
|
|
depends on ARCH_HAVE_MMU
|
|
|
|
---help---
|
|
|
|
The architecture supports supports an MMU. Enable this option in
|
|
|
|
order to enable use of the MMU. For most architectures, this is
|
|
|
|
not really an option: It is required to use the MMU. In those
|
|
|
|
cases, this selection will always be forced.
|
|
|
|
|
|
|
|
config ARCH_USE_MPU
|
|
|
|
bool "Enable MPU"
|
|
|
|
default n
|
|
|
|
depends on ARCH_HAVE_MPU
|
|
|
|
---help---
|
|
|
|
The architecture supports supports an MPU. Enable this option in
|
|
|
|
order to enable use of the MPU. For most architectures, this option
|
|
|
|
is enabled by other, platform-specific logic. In those cases, this
|
|
|
|
selection will always be forced.
|
|
|
|
|
2021-06-18 01:47:45 +02:00
|
|
|
config ARCH_USE_TEXT_HEAP
|
2021-06-25 16:07:23 +02:00
|
|
|
bool "Enable separate text allocation for dynamic code loading"
|
2020-03-09 05:03:49 +01:00
|
|
|
default n
|
2021-06-18 01:47:45 +02:00
|
|
|
depends on ARCH_HAVE_TEXT_HEAP
|
2020-03-09 05:03:49 +01:00
|
|
|
---help---
|
2021-12-20 15:49:48 +01:00
|
|
|
This option enables architecture-specific memory allocator
|
2021-12-21 08:16:24 +01:00
|
|
|
for dynamic code loading. For example, ESP32 has separate memory
|
2020-03-09 05:03:49 +01:00
|
|
|
regions for instruction and data and the memory region used for
|
|
|
|
usual malloc doesn't work for instruction.
|
|
|
|
|
2023-10-05 03:27:10 +02:00
|
|
|
config ARCH_USE_DATA_HEAP
|
|
|
|
bool "Enable separate data allocation for dynamic data loading"
|
|
|
|
default n
|
|
|
|
depends on ARCH_HAVE_DATA_HEAP
|
|
|
|
---help---
|
|
|
|
This option enables architecture-specific memory allocator
|
|
|
|
for dynamic data loading.
|
|
|
|
|
2014-08-24 17:57:53 +02:00
|
|
|
menuconfig ARCH_ADDRENV
|
2014-08-24 14:42:11 +02:00
|
|
|
bool "Address environments"
|
|
|
|
default n
|
sched/addrenv: Fix system crash when process group has been deleted
There is currently a big problem in the address environment handling which
is that the address environment is released too soon when the process is
exiting. The current MMU mappings will always be the exiting process's, which means
the system needs them AT LEAST until the next context switch happens. If
the next thread is a kernel thread, the address environment is needed for
longer.
Kernel threads "lend" the address environment of the previous user process.
This is beneficial in two ways:
- The kernel processes do not need an allocated address environment
- When a context switch happens from user -> kernel or kernel -> kernel,
the TLB does not need to be flushed. This must be done only when
changing to a different user address environment.
Another issue is when a new process is created; the address environment
of the new process must be temporarily instantiated by up_addrenv_select().
However, the system scheduler does not know that the process has a different
address environment to its own and when / if a context restore happens, the
wrong MMU page directory is restored and the process will either crash or
do something horribly wrong.
The following changes are needed to fix the issues:
- Add mm_curr which is the current address environment of the process
- Add a reference counter to safeguard the address environment
- Whenever an address environment is mapped to MMU, its reference counter
is incremented
- Whenever and address environment is unmapped from MMU, its reference
counter is decremented, and tested. If no more references -> drop the
address environment and release the memory as well
- To limit the context switch delay, the address environment is freed in
a separate low priority clean-up thread (LPWORK)
- When a process temporarily instantiates another process's address
environment, the scheduler will now know of this and will restore the
correct mappings to MMU
Why is this not causing more noticeable issues ? The problem only happens
under the aforementioned special conditions, and if a context switch or
IRQ occurs during this time.
2023-02-03 08:48:51 +01:00
|
|
|
depends on ARCH_HAVE_ADDRENV && SCHED_LPWORK
|
2014-08-24 14:42:11 +02:00
|
|
|
---help---
|
|
|
|
Support per-task address environments using the MMU... i.e., support
|
|
|
|
"processes"
|
|
|
|
|
2023-08-22 19:11:24 +02:00
|
|
|
config ARCH_USE_COPY_SECTION
|
|
|
|
bool "Enable arch copy section by self for dynamic code loading"
|
|
|
|
default n
|
|
|
|
depends on ARCH_HAVE_COPY_SECTION
|
|
|
|
---help---
|
|
|
|
This option enables architecture-specific memory copy for
|
|
|
|
dynamic code loading. For example, Ambiq has MRAM regions
|
|
|
|
for instruction which can't load by the memcpy directly.
|
|
|
|
|
2014-08-24 20:54:37 +02:00
|
|
|
if ARCH_ADDRENV && ARCH_NEED_ADDRENV_MAPPING
|
2014-08-24 17:57:53 +02:00
|
|
|
|
|
|
|
config ARCH_TEXT_VBASE
|
|
|
|
hex "Virtual .text base"
|
|
|
|
---help---
|
|
|
|
The virtual address of the beginning the .text region
|
|
|
|
|
|
|
|
config ARCH_DATA_VBASE
|
|
|
|
hex "Virtual .bss/.data base"
|
|
|
|
---help---
|
|
|
|
The virtual address of the beginning of the .bss/.data region.
|
|
|
|
|
|
|
|
config ARCH_HEAP_VBASE
|
|
|
|
hex "Virtual heap base"
|
|
|
|
---help---
|
|
|
|
The virtual address of the beginning of the heap region.
|
|
|
|
|
2023-01-11 10:56:59 +01:00
|
|
|
config ARCH_VMA_MAPPING
|
|
|
|
bool "Support runtime memory mapping into SHM area"
|
|
|
|
default n
|
|
|
|
|
2024-04-13 23:29:21 +02:00
|
|
|
config ARCH_KVMA_MAPPING
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
2014-09-23 15:11:47 +02:00
|
|
|
config ARCH_SHM_VBASE
|
2014-09-23 16:46:31 +02:00
|
|
|
hex "Shared memory base"
|
2023-01-11 10:56:59 +01:00
|
|
|
depends on ARCH_VMA_MAPPING
|
2014-09-23 15:11:47 +02:00
|
|
|
---help---
|
|
|
|
The virtual address of the beginning of the shared memory region.
|
|
|
|
|
2023-04-13 15:25:22 +02:00
|
|
|
config ARCH_KMAP_VBASE
|
|
|
|
hex "Kernel dynamic virtual mappings base"
|
2024-04-13 23:29:21 +02:00
|
|
|
depends on ARCH_KVMA_MAPPING
|
2023-04-13 15:25:22 +02:00
|
|
|
---help---
|
|
|
|
The virtual address of the beginning of the kernel dynamic mapping
|
|
|
|
region.
|
|
|
|
|
2014-08-24 17:57:53 +02:00
|
|
|
config ARCH_TEXT_NPAGES
|
|
|
|
int "Max .text pages"
|
|
|
|
default 1
|
|
|
|
---help---
|
|
|
|
The maximum number of pages that can allocated for the .text region.
|
|
|
|
This, along with knowledge of the page size, determines the size of
|
|
|
|
the .text virtual address space. Default is 1.
|
|
|
|
|
|
|
|
config ARCH_DATA_NPAGES
|
|
|
|
int "Max .bss/.data pages"
|
|
|
|
default 1
|
|
|
|
---help---
|
|
|
|
The maximum number of pages that can allocated for the .bss/.data
|
|
|
|
region. This, along with knowledge of the page size, determines the
|
|
|
|
size of the .bss/.data virtual address space. Default is 1.
|
|
|
|
|
|
|
|
config ARCH_HEAP_NPAGES
|
|
|
|
int "Max heap pages"
|
|
|
|
default 1
|
|
|
|
---help---
|
|
|
|
The maximum number of pages that can allocated for the heap region.
|
|
|
|
This, along with knowledge of the page size, determines the size of
|
|
|
|
the heap virtual address space. Default is 1.
|
|
|
|
|
2023-01-11 10:56:59 +01:00
|
|
|
if ARCH_VMA_MAPPING
|
2014-09-23 15:11:47 +02:00
|
|
|
|
|
|
|
config ARCH_SHM_MAXREGIONS
|
|
|
|
int "Max shared memory regions"
|
|
|
|
default 1
|
|
|
|
---help---
|
2024-04-17 05:21:22 +02:00
|
|
|
The maximum number of regions that can be used with SysV shared
|
|
|
|
memory interface. This hard-coded value permits static allocation of
|
2014-09-23 15:11:47 +02:00
|
|
|
the shared memory data structures and serves no other purpose.
|
|
|
|
Default is 1.
|
|
|
|
|
|
|
|
config ARCH_SHM_NPAGES
|
2024-04-17 05:21:22 +02:00
|
|
|
int "Max size of userspace VM mapping in pages"
|
2014-09-23 15:11:47 +02:00
|
|
|
default 1
|
|
|
|
---help---
|
2024-04-17 05:21:22 +02:00
|
|
|
The max size of the virtual memory region for shared memory,
|
|
|
|
userspace device mappings etc.
|
2014-09-23 15:11:47 +02:00
|
|
|
|
2023-11-01 15:26:34 +01:00
|
|
|
endif # ARCH_VMA_MAPPING
|
|
|
|
|
2023-04-13 15:25:22 +02:00
|
|
|
config ARCH_KMAP_NPAGES
|
|
|
|
int "Max kernel dynamic mapping pages"
|
|
|
|
default 1
|
2024-04-13 23:29:21 +02:00
|
|
|
depends on ARCH_KVMA_MAPPING
|
2023-04-13 15:25:22 +02:00
|
|
|
---help---
|
|
|
|
The maximum amount of pages that a kernel can use for dynamically
|
|
|
|
mapping physical pages to itself.
|
|
|
|
|
2014-09-13 20:25:32 +02:00
|
|
|
config ARCH_STACK_DYNAMIC
|
2014-09-14 17:10:09 +02:00
|
|
|
bool "Dynamic user stack"
|
|
|
|
default n
|
|
|
|
depends on BUILD_KERNEL && EXPERIMENTAL
|
2014-09-13 20:25:32 +02:00
|
|
|
---help---
|
|
|
|
Select this option if the user process stack resides in its own
|
|
|
|
address space. The naming of this selection implies that dynamic
|
|
|
|
stack allocation is supported. Certainly this option must be set if
|
|
|
|
dynamic stack allocation is supported by a platform. But the more
|
|
|
|
general meaning of this configuration environment is simply that the
|
|
|
|
stack has its own address space.
|
|
|
|
|
2014-09-14 17:10:09 +02:00
|
|
|
NOTE: This option not yet fully implemented in the code base.
|
|
|
|
Hence, it is marked EXPERIMENTAL: Do not enable it unless you plan
|
|
|
|
finish the implementation.
|
2014-09-13 20:25:32 +02:00
|
|
|
|
|
|
|
if ARCH_STACK_DYNAMIC
|
|
|
|
|
|
|
|
config ARCH_STACK_VBASE
|
|
|
|
hex "Virtual stack base"
|
|
|
|
---help---
|
|
|
|
The virtual address of the beginning the stack region
|
|
|
|
|
2014-08-24 17:57:53 +02:00
|
|
|
config ARCH_STACK_NPAGES
|
|
|
|
int "Max. stack pages"
|
|
|
|
default 1
|
|
|
|
---help---
|
|
|
|
The maximum number of pages that can allocated for the stack region.
|
|
|
|
This, along with knowledge of the page size, determines the size of
|
|
|
|
the stack virtual address space. Default is 1.
|
|
|
|
|
2014-09-13 20:25:32 +02:00
|
|
|
endif # ARCH_STACK_DYNAMIC
|
|
|
|
|
2014-09-14 17:10:09 +02:00
|
|
|
config ARCH_KERNEL_STACK
|
|
|
|
bool "Kernel process stack"
|
2023-07-15 19:04:21 +02:00
|
|
|
default LIBC_EXECFUNCS
|
2014-09-14 17:10:09 +02:00
|
|
|
depends on BUILD_KERNEL
|
|
|
|
---help---
|
|
|
|
It this option is selected, then every user process will have two
|
|
|
|
stacks: A large, potentially dynamically sized user stack and small
|
|
|
|
kernel stack that is used during system call process.
|
|
|
|
|
|
|
|
If this option is not selected, then kernel system calls will simply
|
|
|
|
use the caller's user stack. So, in most cases, this option is not
|
|
|
|
required. However, this option is *required* if both BUILD_KERNEL
|
|
|
|
and LIBC_EXECFUNCS are selected. Why? Because when we instantiate
|
|
|
|
and initialize the address environment of the new user process, we
|
|
|
|
will temporarily lose the address environment of the old user
|
|
|
|
process, including its stack contents. The kernel C logic will
|
|
|
|
crash immediately with no valid stack in place.
|
|
|
|
|
|
|
|
When this option is selected, the smaller kernel stack stays in
|
|
|
|
place during system call processing event though the original user
|
|
|
|
stack may or may not be accessible.
|
|
|
|
|
|
|
|
if ARCH_KERNEL_STACK
|
|
|
|
|
|
|
|
config ARCH_KERNEL_STACKSIZE
|
|
|
|
int "Kernel stack size"
|
|
|
|
default 1568
|
|
|
|
---help---
|
2020-02-23 09:50:23 +01:00
|
|
|
The common size of each process's kernel stack
|
2014-09-14 17:10:09 +02:00
|
|
|
|
|
|
|
endif # ARCH_KERNEL_STACK
|
|
|
|
|
2014-09-10 16:41:01 +02:00
|
|
|
config ARCH_PGPOOL_MAPPING
|
|
|
|
bool "Have page pool mapping"
|
|
|
|
default n
|
|
|
|
---help---
|
|
|
|
If there is a MMU mapping in place for the page pool memory, then
|
|
|
|
this mapping can be utilized to simplify some page table operations.
|
|
|
|
Otherwise, a temporary mapping will have to be established each time
|
|
|
|
it is necessary to modify the contents of a page.
|
|
|
|
|
|
|
|
if ARCH_PGPOOL_MAPPING
|
|
|
|
|
|
|
|
config ARCH_PGPOOL_PBASE
|
|
|
|
hex "Page pool physical address"
|
|
|
|
default 0x0
|
|
|
|
---help---
|
|
|
|
The physical address of the start of the page pool memory. This
|
|
|
|
setting is probably equivalent to other platform specific definitions
|
|
|
|
but is required again in order to modularize the common address
|
|
|
|
environment logic.
|
|
|
|
|
|
|
|
config ARCH_PGPOOL_VBASE
|
|
|
|
hex "Page pool virtual address"
|
|
|
|
default 0x0
|
|
|
|
---help---
|
|
|
|
The virtual address of the start of the page pool memory. This
|
|
|
|
setting is probably equivalent to other platform specific definitions
|
|
|
|
but is required again in order to modularize the common address
|
|
|
|
environment logic.
|
|
|
|
|
|
|
|
config ARCH_PGPOOL_SIZE
|
2018-07-09 02:24:45 +02:00
|
|
|
int "Page pool size (bytes)"
|
2014-09-10 16:41:01 +02:00
|
|
|
default 0
|
|
|
|
---help---
|
|
|
|
The size of the page pool memory in bytes. This setting is probably
|
|
|
|
equivalent to other platform specific definitions but is required again
|
|
|
|
in order to modularize the common address environment logic.
|
|
|
|
|
|
|
|
endif # ARCH_PGPOOL_MAPPING
|
2014-08-29 22:47:22 +02:00
|
|
|
endif # ARCH_ADDRENV && ARCH_NEED_ADDRENV_MAPPING
|
2014-08-24 17:57:53 +02:00
|
|
|
|
2024-02-23 14:33:24 +01:00
|
|
|
config PAGING
|
|
|
|
bool "On-demand paging"
|
|
|
|
default n
|
|
|
|
depends on BUILD_KERNEL && ARCH_USE_MMU && !ARCH_ROMPGTABLE && !LEGACY_PAGING
|
|
|
|
---help---
|
|
|
|
If set =y in your configation file, this setting will enable on-demand
|
|
|
|
paging, which relies on a MMU to enable larger virtual memory spaces
|
|
|
|
and map it to physical memory on-demand (usually during a page-fault
|
|
|
|
exception).
|
|
|
|
|
2024-02-29 20:21:23 +01:00
|
|
|
menuconfig LEGACY_PAGING
|
|
|
|
bool "Legacy On-demand paging"
|
2014-03-05 21:25:49 +01:00
|
|
|
default n
|
2024-02-29 20:21:23 +01:00
|
|
|
depends on EXPERIMENTAL && ARCH_USE_MMU && !ARCH_ROMPGTABLE
|
2014-03-05 21:25:49 +01:00
|
|
|
---help---
|
2024-02-29 20:21:23 +01:00
|
|
|
If set =y in your configation file, this setting will enable lazy loading
|
|
|
|
backed up by the experimental on-demand paging feature as described in
|
2020-08-30 22:12:57 +02:00
|
|
|
https://nuttx.apache.org/docs/latest/components/paging.html.
|
2014-03-05 21:25:49 +01:00
|
|
|
|
2024-02-29 20:21:23 +01:00
|
|
|
if LEGACY_PAGING
|
2014-03-05 21:25:49 +01:00
|
|
|
|
|
|
|
config PAGING_PAGESIZE
|
|
|
|
int "Page size (bytes)"
|
|
|
|
default 4096
|
|
|
|
---help---
|
|
|
|
The size of one managed page. This must be a value supported by the
|
|
|
|
processor's memory management unit
|
|
|
|
|
|
|
|
config PAGING_NLOCKED
|
|
|
|
int "Number of locked pages"
|
|
|
|
default 48
|
|
|
|
---help---
|
|
|
|
This is the number of locked pages in the memory map.
|
|
|
|
|
|
|
|
config PAGING_CUSTOM_BASE
|
|
|
|
bool "Custom paging base address"
|
|
|
|
default n
|
|
|
|
---help---
|
|
|
|
By default, the page begins at RAM_START/VSTART. That base address
|
|
|
|
can be changed if this value is selected.
|
|
|
|
|
|
|
|
if PAGING_CUSTOM_BASE
|
|
|
|
|
|
|
|
config PAGING_LOCKED_PBASE
|
|
|
|
hex "Physical base address"
|
|
|
|
|
|
|
|
config PAGING_LOCKED_VBASE
|
|
|
|
hex "Virtual base address"
|
|
|
|
|
|
|
|
endif # PAGING_CUSTOM_BASE
|
|
|
|
|
|
|
|
config PAGING_NPPAGED
|
|
|
|
int "Number of physical pages"
|
|
|
|
default 256
|
|
|
|
---help---
|
|
|
|
This is the number of physical pages available to support the paged
|
|
|
|
text region.
|
|
|
|
|
|
|
|
config PAGING_NVPAGED
|
|
|
|
int "Number of virtual pages"
|
|
|
|
default 1024
|
|
|
|
---help---
|
|
|
|
This actual size of the virtual paged text region (in pages). This
|
|
|
|
is also the number of virtual pages required to span the entire
|
|
|
|
paged region. The on-demand paging feature is intended to support
|
|
|
|
only the case where the virtual paged text area is much larger the
|
|
|
|
available physical pages. Otherwise, why would you enable on-demand paging?
|
|
|
|
|
|
|
|
config PAGING_NDATA
|
|
|
|
int "Number of data pages"
|
|
|
|
default 256
|
|
|
|
---help---
|
|
|
|
This is the number of data pages in the memory map. The data region
|
|
|
|
will extend to the end of RAM unless overridden by a setting in the
|
|
|
|
configuration file.
|
|
|
|
|
|
|
|
NOTE: In some architectures, it may be necessary to take some memory
|
|
|
|
from the end of RAM for page tables or other system usage. The
|
|
|
|
configuration settings and linker directives must be cognizant of
|
|
|
|
that: PAGING_NDATA should be defined to prevent the data region from
|
|
|
|
extending all the way to the end of memory.
|
|
|
|
|
|
|
|
config PAGING_DEFPRIO
|
|
|
|
int "Page fill worker thread priority"
|
|
|
|
default 100
|
|
|
|
---help---
|
|
|
|
The default, minimum priority of the page fill worker thread. The
|
|
|
|
priority of the page fill work thread will be boosted boosted
|
|
|
|
dynamically so that it matches the priority of the task on behalf
|
|
|
|
of which it performs the fill. This defines the minimum priority
|
|
|
|
that will be used. Default: 100.
|
|
|
|
|
|
|
|
config PAGING_STACKSIZE
|
|
|
|
int "Page fill worker thread stack size"
|
|
|
|
default 1024
|
|
|
|
---help---
|
|
|
|
Defines the size of the allocated stack for the page fill worker
|
|
|
|
thread. Default: 1024.
|
|
|
|
|
|
|
|
config PAGING_BLOCKINGFILL
|
|
|
|
bool "Blocking fill"
|
|
|
|
default n
|
|
|
|
---help---
|
|
|
|
The architecture specific up_fillpage() function may be blocking
|
|
|
|
or non-blocking. If defined, this setting indicates that the
|
|
|
|
up_fillpage() implementation will block until the transfer is
|
|
|
|
completed. Default: Undefined (non-blocking).
|
|
|
|
|
|
|
|
config PAGING_WORKPERIOD
|
|
|
|
int "Work period (usec)"
|
|
|
|
default 500000
|
|
|
|
---help---
|
|
|
|
The page fill worker thread will wake periodically even if there
|
|
|
|
is no mapping to do. This selection controls that wake-up period
|
|
|
|
(in microseconds). This wake-up a failsafe that will handle any
|
|
|
|
cases where a single is lost (that would really be a bug and
|
|
|
|
shouldn't happen!) and also supports timeouts for case of non-
|
|
|
|
blocking, asynchronous fills (see CONFIG_PAGING_TIMEOUT_TICKS).
|
|
|
|
|
|
|
|
config PAGING_TIMEOUT
|
|
|
|
bool "Paging timeout"
|
|
|
|
default n
|
|
|
|
---help---
|
|
|
|
If defined, the implementation will monitor the (asynchronous) page
|
|
|
|
fill logic. If the fill takes longer than than a timeout value,
|
|
|
|
then a fatal error will be declared. Default: No timeouts monitored
|
|
|
|
|
|
|
|
config PAGING_TIMEOUT_TICKS
|
|
|
|
int "Paging timeout ticks"
|
|
|
|
default 10
|
|
|
|
depends on PAGING_TIMEOUT
|
|
|
|
---help---
|
|
|
|
If PAGING_TIMEOUT is defined, then implementation will monitor the
|
|
|
|
(asynchronous) page fill logic. If the fill takes longer than this
|
|
|
|
number if microseconds, then a fatal error will be declared.
|
|
|
|
Default: No timeouts monitored
|
|
|
|
|
2024-02-29 20:21:23 +01:00
|
|
|
endif # LEGACY_PAGING
|
2014-03-05 21:25:49 +01:00
|
|
|
|
2013-12-20 15:42:54 +01:00
|
|
|
config ARCH_IRQPRIO
|
|
|
|
bool "Prioritized interrupt support"
|
|
|
|
default n
|
|
|
|
depends on ARCH_HAVE_IRQPRIO
|
|
|
|
---help---
|
|
|
|
Enable support for prioritized interrupts.
|
|
|
|
|
|
|
|
NOTE: The use of interrupt priorities implies that you also have
|
|
|
|
support for nested interrupts. Most architectures do not support
|
2014-02-08 17:46:29 +01:00
|
|
|
nesting of interrupts or, if they do, they only supported nested
|
2013-12-20 15:42:54 +01:00
|
|
|
interrupts with certain configuration options. So this selection
|
|
|
|
should be used with caution.
|
|
|
|
|
2012-08-17 16:07:48 +02:00
|
|
|
config ARCH_STACKDUMP
|
|
|
|
bool "Dump stack on assertions"
|
|
|
|
default n
|
2016-06-21 13:26:08 +02:00
|
|
|
select DEBUG_ALERT
|
2012-08-17 16:07:48 +02:00
|
|
|
---help---
|
|
|
|
Enable to do stack dumps after assertions
|
|
|
|
|
2022-07-25 09:03:07 +02:00
|
|
|
config ARCH_STACKDUMP_MAX_LENGTH
|
|
|
|
int "The maximum length for dump stack on assertions"
|
|
|
|
depends on ARCH_STACKDUMP
|
|
|
|
default 0
|
|
|
|
|
2022-04-13 13:40:30 +02:00
|
|
|
config DUMP_ON_EXIT
|
|
|
|
bool "Dump all tasks state on exit"
|
|
|
|
default n
|
|
|
|
---help---
|
|
|
|
Dump all tasks state on exit()
|
|
|
|
|
2014-03-20 17:56:30 +01:00
|
|
|
config ARCH_USBDUMP
|
|
|
|
bool "Dump USB trace data"
|
|
|
|
default n
|
|
|
|
depends on USBDEV_TRACE
|
|
|
|
---help---
|
|
|
|
Enable to do USB trace after assertions
|
|
|
|
|
2023-06-19 04:40:09 +02:00
|
|
|
config ARCH_DEADLOCKDUMP
|
|
|
|
bool "Dump dead lock thread"
|
|
|
|
default "n"
|
|
|
|
---help---
|
|
|
|
This option will dump the dead lock thread when assert happen..
|
|
|
|
|
2012-11-28 18:50:28 +01:00
|
|
|
config ENDIAN_BIG
|
|
|
|
bool "Big Endian Architecture"
|
|
|
|
default n
|
2016-10-16 17:47:07 +02:00
|
|
|
depends on !ARCH_RISCV
|
2012-11-28 18:50:28 +01:00
|
|
|
---help---
|
|
|
|
Select if architecture operates using big-endian byte ordering.
|
|
|
|
|
2014-03-04 15:58:01 +01:00
|
|
|
config ARCH_IDLE_CUSTOM
|
|
|
|
bool "Custom IDLE loop"
|
|
|
|
default n
|
|
|
|
---help---
|
|
|
|
Each architecture provides a "default" IDLE loop that exits when the
|
|
|
|
MCU has nothing else to do. This default IDLE loop can be replaced
|
|
|
|
by a custom, board-specific IDLE loop by setting this option. Such
|
|
|
|
a custom IDLE loop may do things like a continuous built-in test or
|
|
|
|
perhaps or IDLE low power operations.
|
|
|
|
|
2018-05-07 18:13:20 +02:00
|
|
|
NOTE: As of this writing, this capability is only supported by ARM
|
2018-05-07 19:17:19 +02:00
|
|
|
and MIPS architectures. However, the implementation is trivial: If
|
2018-05-07 18:13:20 +02:00
|
|
|
CONFIG_ARCH_IDLE_CUSTOM is defined, then the default IDLE loop file
|
|
|
|
is not included in the MCU-specific Make.defs file.
|
2014-03-04 15:58:01 +01:00
|
|
|
|
|
|
|
config ARCH_CUSTOM_PMINIT
|
|
|
|
bool "Custom PM initialization"
|
|
|
|
default n
|
|
|
|
depends on PM
|
|
|
|
---help---
|
|
|
|
Each architecture provides default power management (PM)
|
|
|
|
initialization that is called automatically when the system is
|
|
|
|
started. This default PM initialization can be replaced by custom,
|
|
|
|
board-specific PM initialization by setting this option. Such a
|
|
|
|
custom initialization may do additional PM-related initialization
|
|
|
|
that is unique to the board power management requirements.
|
|
|
|
|
|
|
|
NOTE: As of this writing, this capability is only supported by the
|
|
|
|
STM32. However, the implementation is trivial: If CONFIG_ARCH_CUSTOM_PMINIT,
|
|
|
|
then the default PM initialization is not included in the MCU-specific
|
|
|
|
Make.defs file.
|
|
|
|
|
2013-01-14 23:06:19 +01:00
|
|
|
config ARCH_HAVE_RAMFUNCS
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
|
|
|
config ARCH_RAMFUNCS
|
|
|
|
bool "Copy functions to RAM on startup"
|
2014-04-05 00:26:24 +02:00
|
|
|
default y
|
2013-01-14 23:06:19 +01:00
|
|
|
depends on ARCH_HAVE_RAMFUNCS
|
|
|
|
---help---
|
|
|
|
Copy some functions to RAM at boot time. This is done in some
|
|
|
|
architectures to improve performance. In other cases, it is done
|
|
|
|
so that FLASH can be reconfigured while the MCU executes out of
|
|
|
|
SRAM.
|
|
|
|
|
2013-03-18 22:10:08 +01:00
|
|
|
config ARCH_HAVE_RAMVECTORS
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
|
|
|
config ARCH_RAMVECTORS
|
|
|
|
bool "Support RAM interrupt vectors"
|
|
|
|
default n
|
|
|
|
depends on ARCH_HAVE_RAMVECTORS
|
|
|
|
---help---
|
|
|
|
If ARCH_RAMVECTORS is defined, then the architecture will support
|
|
|
|
modifiable vectors in a RAM-based vector table.
|
|
|
|
|
2017-03-03 15:55:16 +01:00
|
|
|
config ARCH_MINIMAL_VECTORTABLE
|
|
|
|
bool "Minimal RAM usage for vector table"
|
|
|
|
default n
|
|
|
|
---help---
|
|
|
|
Use a minimum amount of RAM for the vector table.
|
|
|
|
|
|
|
|
Instead of allowing irq_attach() to work for all interrupt vectors,
|
|
|
|
restrict to only working for a select few (defined in your board
|
|
|
|
configuration). This can dramatically reduce the amount of RAM used
|
|
|
|
be your vector table.
|
|
|
|
|
|
|
|
To use this setting, you must have a file in your board config that
|
|
|
|
provides:
|
|
|
|
|
|
|
|
#include <nuttx/arch.h>
|
2017-03-03 17:20:40 +01:00
|
|
|
const irq_mapped_t g_irqmap[NR_IRQS] =
|
2017-03-03 15:55:16 +01:00
|
|
|
{
|
|
|
|
... IRQ to index mapping values ...
|
|
|
|
};
|
|
|
|
|
|
|
|
This table is index by the hardware IRQ number and provides a value
|
2017-03-03 17:20:40 +01:00
|
|
|
in the range of 0 to CONFIG_ARCH_NUSER_INTERRUPTS that is the new,
|
2017-03-03 15:55:16 +01:00
|
|
|
mapped index into the vector table. Unused, unmapped interrupts
|
2017-03-03 18:48:20 +01:00
|
|
|
should be set to IRQMAPPED_MAX. So, for example, if g_irqmap[37]
|
2017-03-03 17:20:40 +01:00
|
|
|
== 24, then the hardware interrupt vector 37 will be mapped to the
|
|
|
|
interrupt vector table at index 24. if g_irqmap[42] ==
|
2017-03-03 18:48:20 +01:00
|
|
|
IRQMAPPED_MAX, then hardware interrupt vector 42 is not used and
|
2017-03-03 17:20:40 +01:00
|
|
|
if it occurs will result in an unexpected interrupt crash.
|
2017-03-03 15:55:16 +01:00
|
|
|
|
|
|
|
config ARCH_NUSER_INTERRUPTS
|
|
|
|
int "Number of interrupts"
|
|
|
|
default 0
|
|
|
|
depends on ARCH_MINIMAL_VECTORTABLE
|
|
|
|
---help---
|
|
|
|
If CONFIG_ARCH_MINIMAL_VECTORTABLE is defined, then this setting
|
|
|
|
defines the actual number of valid, mapped interrupts in g_irqmap.
|
|
|
|
This number will be the new size of the OS vector table
|
|
|
|
|
2018-08-19 22:55:49 +02:00
|
|
|
# Bring-up debug configuration options. These are only intended for low level
|
|
|
|
# bring-up and not part of normal platform configuration. They should never be
|
2018-08-19 23:38:06 +02:00
|
|
|
# selected in a "normal" configuration and, hence, depend on both EXPERIMENTAL
|
|
|
|
# and DEBUG_FEATURES.
|
2018-08-19 22:55:49 +02:00
|
|
|
|
|
|
|
menu "Bring-Up Options"
|
2022-09-16 07:08:21 +02:00
|
|
|
depends on DEBUG_FEATURES
|
2018-08-19 23:38:06 +02:00
|
|
|
|
|
|
|
config SUPPRESS_CLOCK_CONFIG
|
|
|
|
bool "Suppress clock configuration"
|
|
|
|
default n
|
|
|
|
---help---
|
|
|
|
Do not configure clocking. Instead relies on the reset clock
|
|
|
|
configuration (or clock configuration provided by a bootloader).
|
2018-08-19 22:55:49 +02:00
|
|
|
|
|
|
|
config SUPPRESS_INTERRUPTS
|
|
|
|
bool "Suppress all interrupts"
|
|
|
|
default n
|
|
|
|
---help---
|
|
|
|
Do not enable interrupts
|
|
|
|
|
|
|
|
config SUPPRESS_TIMER_INTS
|
|
|
|
bool "No timer"
|
|
|
|
default n
|
|
|
|
---help---
|
|
|
|
Do not initialize or enable the system timer
|
|
|
|
|
|
|
|
config SUPPRESS_SERIAL_INTS
|
|
|
|
bool "Suppress serial interrupts"
|
|
|
|
default n
|
|
|
|
---help---
|
|
|
|
Console will poll
|
|
|
|
|
|
|
|
config SUPPRESS_UART_CONFIG
|
|
|
|
bool "Do no re-configure UART"
|
|
|
|
default n
|
|
|
|
---help---
|
|
|
|
Do not re-configure the serial console UART from its start-up state.
|
|
|
|
This is useful when a boot loader has already initialized the serial
|
|
|
|
port.
|
|
|
|
|
|
|
|
endmenu # Bring-Up Options
|
|
|
|
|
2012-08-17 16:07:48 +02:00
|
|
|
comment "Board Settings"
|
|
|
|
|
|
|
|
config BOARD_LOOPSPERMSEC
|
2013-02-26 22:53:12 +01:00
|
|
|
int "Delay loops per millisecond"
|
|
|
|
default 5000
|
|
|
|
---help---
|
|
|
|
Simple delay loops are used by some logic, especially during boot-up,
|
|
|
|
driver initialization. These delay loops must be calibrated for each
|
|
|
|
board in order to assure accurate timing by the delay loops.
|
|
|
|
|
2013-12-21 18:03:38 +01:00
|
|
|
comment "Interrupt options"
|
|
|
|
|
2012-09-09 17:43:18 +02:00
|
|
|
config ARCH_HAVE_INTERRUPTSTACK
|
|
|
|
bool
|
2013-12-21 18:03:38 +01:00
|
|
|
default n
|
2012-09-09 17:43:18 +02:00
|
|
|
|
|
|
|
config ARCH_INTERRUPTSTACK
|
2012-09-17 20:35:37 +02:00
|
|
|
int "Interrupt Stack Size"
|
2012-09-09 17:43:18 +02:00
|
|
|
depends on ARCH_HAVE_INTERRUPTSTACK
|
2012-09-17 20:35:37 +02:00
|
|
|
default 0
|
2012-09-09 17:43:18 +02:00
|
|
|
---help---
|
|
|
|
This architecture supports an interrupt stack. If defined, this symbol
|
2012-09-17 20:35:37 +02:00
|
|
|
will be the size of the interrupt stack in bytes. If not defined (or
|
|
|
|
defined to be zero), the user task stacks will be used during interrupt
|
|
|
|
handling.
|
2012-09-09 17:43:18 +02:00
|
|
|
|
2013-12-21 18:03:38 +01:00
|
|
|
config ARCH_HAVE_HIPRI_INTERRUPT
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
|
|
|
config ARCH_HIPRI_INTERRUPT
|
|
|
|
bool "High priority interrupts"
|
|
|
|
default n
|
|
|
|
depends on ARCH_HAVE_HIPRI_INTERRUPT && ARCH_HAVE_IRQPRIO
|
|
|
|
select ARCH_IRQPRIO
|
|
|
|
---help---
|
|
|
|
NOTE: This description is currently unique to the Cortex-M family
|
|
|
|
which is the only family that currently supports this feature. The
|
2019-08-09 22:34:32 +02:00
|
|
|
general feature is not conceptually unique to the Cortex-M but if it
|
2013-12-21 18:03:38 +01:00
|
|
|
is extended to any other family, then this discussion will have to
|
|
|
|
be generalized.
|
|
|
|
|
|
|
|
If ARMV7M_USEBASEPRI is selected, then interrupts will be disabled
|
|
|
|
by setting the BASEPRI register to NVIC_SYSH_DISABLE_PRIORITY so
|
|
|
|
that most interrupts will not have execution priority. SVCall must
|
|
|
|
have execution priority in all cases.
|
|
|
|
|
|
|
|
In the normal cases, interrupts are not nest-able and all interrupts
|
|
|
|
run at an execution priority between NVIC_SYSH_PRIORITY_MIN and
|
|
|
|
NVIC_SYSH_PRIORITY_MAX (with NVIC_SYSH_PRIORITY_MAX reserved for
|
|
|
|
SVCall).
|
|
|
|
|
|
|
|
If, in addition, ARCH_HIPRI_INTERRUPT is defined, then special high
|
|
|
|
priority interrupts are supported. These are not "nested" in the
|
|
|
|
normal sense of the word. These high priority interrupts can
|
|
|
|
interrupt normal processing but execute outside of OS (although they
|
|
|
|
can "get back into the game" via a PendSV interrupt).
|
|
|
|
|
|
|
|
How do you specify a high priority interrupt? You need to do two
|
|
|
|
things:
|
|
|
|
|
|
|
|
1) You need to change the address in the vector table so that
|
|
|
|
the high priority interrupt vectors to your special C
|
|
|
|
interrupt handler. There are two ways to do this:
|
|
|
|
|
|
|
|
a) If you select CONFIG_ARCH_RAMVECTORS, then vectors will
|
|
|
|
be kept in RAM and the system will support the interface:
|
|
|
|
|
|
|
|
int up_ramvec_attach(int irq, up_vector_t vector)
|
|
|
|
|
|
|
|
that can be used to attach your C interrupt handler to the
|
|
|
|
vector at run time.
|
|
|
|
|
|
|
|
b) Alternatively, you could keep your vectors in FLASH but in
|
|
|
|
order to this, you would have to develop your own custom
|
|
|
|
vector table.
|
|
|
|
|
|
|
|
2) Then set the priority of your interrupt to NVIC to
|
|
|
|
NVIC_SYSH_HIGH_PRIORITY using the standard interface:
|
|
|
|
|
|
|
|
int up_prioritize_irq(int irq, int priority)
|
|
|
|
|
2014-08-29 22:47:22 +02:00
|
|
|
NOTE: ARCH_INTERRUPTSTACK must be set in kernel mode (BUILD_KERNEL).
|
2013-12-21 22:05:48 +01:00
|
|
|
In kernel mode without an interrupt stack, the interrupt handler
|
|
|
|
will set the MSP to the stack pointer of the interrupted thread. If
|
|
|
|
the interrupted thread was a privileged thread, that will be the MSP
|
|
|
|
otherwise it will be the PSP. If the PSP is used, then the value of
|
|
|
|
the MSP will be invalid when the interrupt handler returns because
|
|
|
|
it will be a pointer to an old position in the unprivileged stack.
|
|
|
|
Then when the high priority interrupt occurs and uses this stale MSP,
|
|
|
|
there will most likely be a system failure.
|
|
|
|
|
|
|
|
If the interrupt stack is selected, on the other hand, then the
|
2017-05-11 21:35:56 +02:00
|
|
|
interrupt handler will always set the MSP to the interrupt
|
2013-12-21 22:05:48 +01:00
|
|
|
stack. So when the high priority interrupt occurs, it will either
|
|
|
|
use the MSP of the last privileged thread to run or, in the case of
|
|
|
|
the nested interrupt, the interrupt stack if no privileged task has
|
|
|
|
run
|
|
|
|
|
2012-09-06 22:08:25 +02:00
|
|
|
comment "Boot options"
|
|
|
|
|
|
|
|
choice
|
2012-09-08 20:57:57 +02:00
|
|
|
prompt "Boot Mode"
|
2012-09-06 22:08:25 +02:00
|
|
|
default BOOT_RUNFROMFLASH
|
|
|
|
|
|
|
|
config BOOT_RUNFROMEXTSRAM
|
|
|
|
bool "Run from external SRAM"
|
|
|
|
---help---
|
|
|
|
Some configuration support booting and running from external SRAM.
|
|
|
|
|
|
|
|
config BOOT_RUNFROMFLASH
|
|
|
|
bool "Boot and run from flash"
|
|
|
|
---help---
|
|
|
|
Most configurations support XIP operation from FLASH but must copy
|
|
|
|
initialized .data sections to RAM. (This is the default).
|
|
|
|
|
|
|
|
config BOOT_RUNFROMISRAM
|
|
|
|
bool "Boot and run from internal SRAM"
|
|
|
|
---help---
|
|
|
|
Some configuration support booting and running from internal SRAM.
|
|
|
|
|
|
|
|
config BOOT_RUNFROMSDRAM
|
|
|
|
bool "Boot and run from external SDRAM"
|
|
|
|
---help---
|
|
|
|
Some configuration support booting and running from external SDRAM.
|
|
|
|
|
|
|
|
config BOOT_COPYTORAM
|
|
|
|
bool "Boot from FLASH but copy to ram"
|
|
|
|
---help---
|
|
|
|
Some configurations boot in FLASH but copy themselves entirely into
|
|
|
|
RAM for better performance.
|
|
|
|
|
|
|
|
endchoice
|
2013-07-28 23:07:35 +02:00
|
|
|
|
|
|
|
menu "Boot Memory Configuration"
|
|
|
|
|
|
|
|
config RAM_START
|
|
|
|
hex "Primary RAM start address (physical)"
|
|
|
|
default 0x0
|
2019-10-06 05:39:12 +02:00
|
|
|
---help---
|
2013-07-28 23:07:35 +02:00
|
|
|
The physical start address of primary installed RAM. "Primary" RAM
|
|
|
|
refers to the RAM that you link program code into. If program code
|
2014-02-08 17:46:29 +01:00
|
|
|
does not execute out of RAM but from FLASH, then you may designate
|
2013-07-28 23:07:35 +02:00
|
|
|
any block of RAM as "primary."
|
|
|
|
|
|
|
|
config RAM_VSTART
|
|
|
|
hex "Primary RAM start address (virtual)"
|
|
|
|
default 0x0
|
2014-08-29 22:47:22 +02:00
|
|
|
depends on ARCH_USE_MMU
|
2019-10-06 05:39:12 +02:00
|
|
|
---help---
|
2013-07-28 23:07:35 +02:00
|
|
|
The virtual start address of installed primary RAM. "Primary" RAM
|
|
|
|
refers to the RAM that you link program code into. If program code
|
2014-02-08 17:46:29 +01:00
|
|
|
does not execute out of RAM but from FLASH, then you may designate
|
2013-07-28 23:07:35 +02:00
|
|
|
any block of RAM as "primary."
|
|
|
|
|
|
|
|
config RAM_SIZE
|
|
|
|
int "Primary RAM size"
|
|
|
|
default 0
|
2019-10-06 05:39:12 +02:00
|
|
|
---help---
|
2013-07-28 23:07:35 +02:00
|
|
|
The size in bytes of the installed primary RAM. "Primary" RAM
|
|
|
|
refers to the RAM that you link program code into. If program code
|
2014-02-08 17:46:29 +01:00
|
|
|
does not execute out of RAM but from FLASH, then you may designate
|
2013-07-28 23:07:35 +02:00
|
|
|
any block of RAM as "primary."
|
|
|
|
|
2014-08-29 22:47:22 +02:00
|
|
|
if BOOT_RUNFROMFLASH && ARCH_USE_MMU
|
2013-07-28 23:07:35 +02:00
|
|
|
|
|
|
|
config FLASH_START
|
|
|
|
hex "Boot FLASH start address (physical)"
|
|
|
|
default 0x0
|
2019-10-06 05:39:12 +02:00
|
|
|
---help---
|
2013-07-28 23:07:35 +02:00
|
|
|
The physical start address of installed boot FLASH. "Boot" FLASH
|
|
|
|
refers to the FLASH that you link program code into.
|
|
|
|
|
|
|
|
config FLASH_VSTART
|
|
|
|
hex "Boot FLASH start address (virtual)"
|
|
|
|
default 0x0
|
2019-10-06 05:39:12 +02:00
|
|
|
---help---
|
2013-07-28 23:07:35 +02:00
|
|
|
The virtual start address of installed boot FLASH. "Boot" FLASH
|
|
|
|
refers to the FLASH that you link program code into.
|
|
|
|
|
|
|
|
config FLASH_SIZE
|
|
|
|
int "Boot FLASH size"
|
|
|
|
default 0
|
2019-10-06 05:39:12 +02:00
|
|
|
---help---
|
2013-07-28 23:07:35 +02:00
|
|
|
The size in bytes of the installed boot FLASH. "Boot" FLASH
|
|
|
|
refers to the FLASH that you link program code into.
|
|
|
|
|
2014-08-29 22:47:22 +02:00
|
|
|
endif # BOOT_RUNFROMFLASH && ARCH_USE_MMU
|
2014-01-28 17:42:49 +01:00
|
|
|
|
|
|
|
config ARCH_HAVE_SDRAM
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
|
|
|
config BOOT_SDRAM_DATA
|
|
|
|
bool "Data in SDRAM"
|
|
|
|
default n
|
2014-01-29 16:08:58 +01:00
|
|
|
depends on ARCH_HAVE_SDRAM && !BOOT_RUNFROMSDRAM
|
2014-01-28 17:42:49 +01:00
|
|
|
---help---
|
2014-01-29 16:08:58 +01:00
|
|
|
This selection should be set if data lies in SDRAM (vs. SRAM) and if
|
|
|
|
SDRAM was not previously initialized by a loader. Obviously, this
|
|
|
|
does not apply if we booting from SDRAM because SDRAM must have been
|
|
|
|
initialized priority to loading NuttX into SDRAM.
|
|
|
|
|
|
|
|
In the case where SDRAM must be initialized by NuttX, the
|
|
|
|
initialization sequence is a little different: Normally, .data and
|
|
|
|
.bss must be initialized before starting the system. But in this
|
|
|
|
case SDRAM must be configured by board-specific logic before the
|
|
|
|
.data and .bss sections can be initialized.
|
2014-01-28 17:42:49 +01:00
|
|
|
|
2013-10-29 23:57:06 +01:00
|
|
|
endmenu # Boot Memory Configuration
|