yann@628: # ARM specific configuration file
yann@628: 
yann@1596: config ARCH_ARM_MODE
yann@1596:     string
yann@1596:     default "arm"   if ARCH_ARM_MODE_ARM
yann@1596:     default "thumb" if ARCH_ARM_MODE_THUMB
yann@1596: 
yann@1596: choice
yann@1596:     bool
yann@1596:     prompt "Default instruction set mode"
yann@1596:     default ARCH_ARM_MODE_ARM
yann@1596: 
yann@1596: config ARCH_ARM_MODE_ARM
yann@1596:     bool
yann@1596:     prompt "arm"
yann@1596:     help
yann@1596:       Defaults to emitting instructions in the ARM mode.
yann@1596: 
yann@1596: config ARCH_ARM_MODE_THUMB
yann@1596:     bool
yann@3150:     prompt "thumb"
yann@1596:     help
yann@1596:       Defaults to emitting instructions in the THUMB mode.
yann@1596: 
yann@1596: endchoice
yann@1596: 
yann@1597: config ARCH_ARM_INTERWORKING
yann@1597:     bool
yann@1597:     prompt "Use Thumb-interworking (READ HELP)"
yann@1597:     help
yann@1597:       Excerpt from the gcc manual:
yann@1597:       
yann@1597:       > Generate code which supports calling between the ARM and Thumb
yann@1597:       > instruction sets. Without this option the two instruction sets
yann@1597:       > cannot be reliably used inside one program. The default is
yann@1597:       > [not to use interwork], since slightly larger code is generated
yann@1597:       > when [interwork] is specified.
yann@3150:       
yann@3150:       NOTE: Interworking in crosstool-NG is not sell-tested. Use at your
yann@3150:             own risks, and report success and/or failure.
yann@1597: 
yann@3159: # Until we only support EABI:
yann@3159: config ARCH_ARM_ABI_OK
yann@3159:     def_bool y
yann@3159:     depends on ! ARCH_ARM_EABI
yann@3159:     select ARCH_SUPPORTS_WITH_ABI
yann@3159: 
yann@3159: # Little trick to force EABI *and* always show the prompt
yann@3159: config ARCH_ARM_EABI_FORCE
yann@3159:     bool
yann@3159:     default y if ! OBSOLETE
yann@3159:     select ARCH_ARM_EABI
yann@3159: 
yann@385: config ARCH_ARM_EABI
yann@385:     bool
yann@823:     prompt "Use EABI"
yann@1582:     default y
yann@385:     help
yann@385:       Set up the toolchain so that it generates EABI-compliant binaries.
yann@3159:       
yann@3159:       If you say 'n' here, then the toolchain will generate OABI binaries.
yann@3159:       OABI has long been deprecated, and is now considered legacy.
yann@503: 
yann@3158: config ARCH_ARM_TUPLE_USE_EABIHF
yann@3158:     bool
yann@3158:     prompt "append 'hf' to the tuple (EXPERIMENTAL)"
yann@3158:     depends on ARCH_FLOAT_HW
yann@3158:     depends on ARCH_ARM_EABI    # Until we only support that...
yann@3158:     depends on EXPERIMENTAL
yann@3158:     help
yann@3158:       Is you say 'y' here, then the tuple for the toolchain will end
yann@3158:       up with *eabihf, instead of the usual *eabi.
yann@3158: 
yann@3158:       *eabihf is used to denote that the toolchain *is* using the
yann@3158:       hard-float ABI, while *eabi is just an indication of using the
yann@3158:       soft-float ABI.
yann@3158: 
yann@3158:       Ie. all one can say is:  *eabihf ⊢ hard-float ABI
yann@3158: 
yann@3158:       Saying 'n' here does *not* impact the ability of the toolchain to
yann@3158:       generate hard-float instructions with the hard-float ABI. It is a
yann@3158:       purely cosmetic thing, used by distros to differentiate their
yann@3158:       hard-float-ABI-using ports from their soft-float-ABI-using ports.
yann@3158:       (eg. Debian Wheezy and above).
yann@3158: 
yann@3158:       This is an option, as not all versions of gcc/binutils do support
yann@3158:       such tuple, and fail to build with *eabihf. Stock gcc version up
yann@3158:       to, and including 4.7.2 have an issue or another with *eabihf.
yann@3158: 
yann@3158:       This option is here for the future.
yann@3158: 
yann@3158:       Say 'n', unless you are trying to fix gcc to properly recognise
yann@3158:       the *eabihf tuples.