# # For a description of the syntax of this configuration file, # see misc/tools/kconfig-language.txt. # choice prompt "CPU Architecture" default ARCH_ARM config ARCH_8051 bool "8051" select CUSTOM_STACK ---help--- Intel 8051 architectures and derivaties config ARCH_ARM bool "ARM" select ARCH_HAVE_INTERRUPTSTACK select ARCH_HAVE_VFORK select ARCH_HAVE_STACKCHECK select ARCH_HAVE_CUSTOMOPT ---help--- The ARM architectures config ARCH_AVR bool "AVR" select ARCH_NOINTC select ARCH_HAVE_INTERRUPTSTACK select ARCH_HAVE_CUSTOMOPT ---help--- Atmel 8-bit bit AVR and 32-bit AVR32 architectures config ARCH_HC bool "Freescale HC" select ARCH_NOINTC select ARCH_HAVE_INTERRUPTSTACK ---help--- Freescale HC architectures (M9S12) config ARCH_MIPS bool "MIPS" select ARCH_HAVE_INTERRUPTSTACK select ARCH_HAVE_CUSTOMOPT ---help--- MIPS architectures (PIC32) config ARCH_RGMP bool "RGMP" ---help--- RTOS and GPOS on Multi-Processor (RGMP) architecture. See http://rgmp.sourceforge.net/wiki/index.php/Main_Page. config ARCH_SH bool "Renesas" select ARCH_NOINTC select ARCH_HAVE_INTERRUPTSTACK ---help--- Renesas architectures (SH and M16C). config ARCH_SIM bool "Simulation" ---help--- Linux/Cywgin user-mode simulation. config ARCH_X86 bool "x86" ---help--- Intel x86 architectures. config ARCH_Z16 bool "ZNEO" select ARCH_HAVE_HEAP2 ---help--- ZiLOG ZNEO 16-bit architectures (z16f). config ARCH_Z80 bool "z80" select ARCH_HAVE_HEAP2 ---help--- ZiLOG 8-bit architectures (z80, ez80, z8). endchoice config ARCH string default "8051" if ARCH_8051 default "arm" if ARCH_ARM default "avr" if ARCH_AVR default "hc" if ARCH_HC default "mips" if ARCH_MIPS default "rgmp" if ARCH_RGMP default "sh" if ARCH_SH default "sim" if ARCH_SIM default "x86" if ARCH_X86 default "z16" if ARCH_Z16 default "z80" if ARCH_Z80 source arch/8051/Kconfig source arch/arm/Kconfig source arch/avr/Kconfig source arch/hc/Kconfig source arch/mips/Kconfig source arch/rgmp/Kconfig source arch/sh/Kconfig source arch/sim/Kconfig source arch/x86/Kconfig source arch/z16/Kconfig source arch/z80/Kconfig comment "Architecture Options" config ARCH_NOINTC bool default n config ARCH_VECNOTIRQ bool default n config ARCH_DMA bool default n config ARCH_HAVE_IRQPRIO bool default n config CUSTOM_STACK bool default n config ADDRENV bool default n config ARCH_HAVE_VFORK bool default n config ARCH_HAVE_MMU bool default n config ARCH_NAND_HWECC bool default n 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 nesting of interrupts or, if they do, they only supported nested interrupts with certain configuration options. So this selection should be used with caution. config ARCH_STACKDUMP bool "Dump stack on assertions" default n ---help--- Enable to do stack dumps after assertions config ENDIAN_BIG bool "Big Endian Architecture" default n ---help--- Select if architecture operates using big-endian byte ordering. config ARCH_HAVE_RAMFUNCS bool default n config ARCH_RAMFUNCS bool "Copy functions to RAM on startup" default n 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. 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. comment "Board Settings" config BOARD_LOOPSPERMSEC 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. config ARCH_CALIBRATION bool "Calibrate delay loop" default n ---help--- Enables some built in instrumentation that causes a 100 second delay during boot-up. This 100 second delay serves no purpose other than it allows you to calibrate BOARD_LOOPSPERMSEC. You simply use a stop watch to measure the actual delay then adjust BOARD_LOOPSPERMSEC until the actual delay is 100 seconds. comment "Interrupt options" config ARCH_HAVE_INTERRUPTSTACK bool default n config ARCH_INTERRUPTSTACK int "Interrupt Stack Size" depends on ARCH_HAVE_INTERRUPTSTACK default 0 ---help--- This architecture supports an interrupt stack. If defined, this symbol 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. 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 ARMV7M_USEBASEPRI 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 general feature is not conceptually unique to the Cortex-M but it 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) NOTE: ARCH_INTERRUPTSTACK must be set in kernel mode (NUTTX_KERNEL). 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 interrupt handler will always set the the MSP to the interrupt 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 config ARCH_INT_DISABLEALL bool "Disable high priority interrupts" default y depends on ARCH_HIPRI_INTERRUPT && EXPERIMENTAL ---help--- If 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). In the normal course of things, interrupts must occasionally be disabled using the irqsave() inline function to prevent contention in use of resources that may be shared between interrupt level and non-interrupt level logic. Now the question arises, if ARCH_HIPRI_INTERRUPT, do we disable all interrupts (except SVCall), or do we only disable the "normal" interrupts. Since the high priority interrupts cannot interact with the OS, you may want to permit the high priority interrupts even if interrupts are disabled. The setting ARCH_INT_DISABLEALL can be used to select either behavior: ----------------------------+--------------+---------------------------- CONFIG_ARCH_HIPRI_INTERRUPT | NO | YES ----------------------------+--------------+--------------+------------- CONFIG_ARCH_INT_DISABLEALL | N/A | YES | NO ----------------------------+--------------+--------------+------------- | | | SVCall | SVCall | SVCall | HIGH Disable here and below --------> MAXNORMAL ---> HIGH --------> MAXNORMAL | | MAXNORMAL | ----------------------------+--------------+--------------+------------- NOTE: This does not work now because interrupts get disabled in the standard interrupt handling, prohibiting nesting. Fix is simple: Need to used more priority levels so that we can make a cleaner distinction with the standard interrupt handler. comment "Boot options" choice prompt "Boot Mode" 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 menu "Boot Memory Configuration" config RAM_START hex "Primary RAM start address (physical)" default 0x0 help The physical start address of primary installed RAM. "Primary" RAM refers to the RAM that you link program code into. If program code does not execute out of RAM but from FLASH, then you may designate any block of RAM as "primary." config RAM_VSTART hex "Primary RAM start address (virtual)" default 0x0 depends on ARCH_HAVE_MMU help The virtual start address of installed primary RAM. "Primary" RAM refers to the RAM that you link program code into. If program code does not execute out of RAM but from FLASH, then you may designate any block of RAM as "primary." config RAM_SIZE int "Primary RAM size" default 0 help The size in bytes of the installed primary RAM. "Primary" RAM refers to the RAM that you link program code into. If program code does not execute out of RAM but from FLASH, then you may designate any block of RAM as "primary." if BOOT_RUNFROMFLASH && ARCH_HAVE_MMU config FLASH_START hex "Boot FLASH start address (physical)" default 0x0 help 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 help 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 help The size in bytes of the installed boot FLASH. "Boot" FLASH refers to the FLASH that you link program code into. endif # BOOT_RUNFROMFLASH && ARCH_HAVE_MMU config ARCH_HAVE_SDRAM bool default n config BOOT_SDRAM_DATA bool "Data in SDRAM" default n depends on ARCH_HAVE_SDRAM && !BOOT_RUNFROMSDRAM ---help--- 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. endmenu # Boot Memory Configuration