# Target definition: architecture, optimisations, etc...

menu "Target options"

config ARCH

    string

# Pre-declare target optimisation variables

config ARCH_SUPPORTS_BOTH_MMU

config ARCH_SUPPORTS_BOTH_ENDIAN

config ARCH_SUPPORTS_32

config ARCH_SUPPORTS_64

config ARCH_SUPPORTS_WITH_ARCH

config ARCH_SUPPORTS_WITH_ABI

config ARCH_SUPPORTS_WITH_CPU

config ARCH_SUPPORTS_WITH_TUNE

config ARCH_SUPPORTS_WITH_FLOAT

config ARCH_SUPPORTS_WITH_FPU

config ARCH_SUPPORTS_SOFTFP

config ARCH_DEFAULT_HAS_MMU

config ARCH_DEFAULT_BE

config ARCH_DEFAULT_LE

config ARCH_DEFAULT_32

config ARCH_DEFAULT_64

config ARCH_ARCH

config ARCH_ABI

config ARCH_CPU

config ARCH_TUNE

config ARCH_FPU

config ARCH_BE

config ARCH_LE

config ARCH_32

config ARCH_64

config ARCH_BITNESS

config ARCH_FLOAT_HW

config ARCH_FLOAT_SW

config TARGET_CFLAGS

config TARGET_LDFLAGS

source "config.gen/arch.in"

config ARCH_SUFFIX

    string

    prompt "Suffix to the arch-part"

    help

      Some architectures have multiple variants and being able to specify

      the variant instead of the arch is quite convenient. This is commonly

      seen for instance when "armv5tel-" is used as a prefix instead of the

      more generic "arm-", or with "alphaev6-" instead of "alpha-".

      Whatever you enter here will be appended to the architecture-part of the

      tuple, just before the first '-'. It will override any architecture-

      specific suffix that crosstool-NG may compute.

      If you are not sure about what this is, leave it blank.

#--------------------------------------

comment "Generic target options"

#--------------------------------------

config MULTILIB

    bool

    prompt "Build a multilib toolchain (READ HELP!!!)"

    help

      If you say 'y' here, then the toolchain will also contain the C library

      optimised for some variants of the selected architecture, besides the

      default settings.

      This means the build time of the C library will be in O(nb_variants).

      The list of variants is dependent on the architecture, and is hard-coded

      in gcc, so it is not possible to say what variants to support, only

      whether hard-coded variants should be supported or not.

      NOTE: The multilib feature in crosstool-NG is not well-tested.

            Use at your own risk, and report success and/or failure.

#--------------------------------------

config ARCH_SUPPORTS_BOTH_MMU

    bool

config ARCH_DEFAULT_HAS_MMU

    bool

config ARCH_USE_MMU

    bool

    prompt "Use the MMU" if ARCH_SUPPORTS_BOTH_MMU

    default y if ARCH_DEFAULT_HAS_MMU

    help

      If your architecture has an MMU and you want to use it,

      say 'Y' here.

      OTOH, if you don't want to use the MMU, or your arch

      lacks an MMU, say 'N' here.

      Note that some architectures (eg. ARM) has variants that

      lacks an MMU (eg. ARM Cortex-M3), while other variants

      have one (eg. ARM Cortex-A8).

#--------------------------------------

config ARCH_SUPPORTS_BOTH_ENDIAN

    bool

config ARCH_DEFAULT_BE

    bool

config ARCH_DEFAULT_LE

    bool

choice

    bool

    prompt "Endianness:"

    depends on ARCH_SUPPORTS_BOTH_ENDIAN

    default ARCH_BE if ARCH_DEFAULT_BE

    default ARCH_LE if ARCH_DEFAULT_LE

config ARCH_BE

    bool

    prompt "Big endian"

config ARCH_LE

    bool

    prompt "Little endian"

endchoice

config ARCH_ENDIAN

    string

    depends on ARCH_SUPPORTS_BOTH_ENDIAN

    default "big"       if ARCH_BE

    default "little"    if ARCH_LE

#--------------------------------------

config ARCH_SUPPORTS_32

    bool

config ARCH_SUPPORTS_64

    bool

config ARCH_DEFAULT_32

    bool

config ARCH_DEFAULT_64

    bool

config ARCH_BITNESS

    int

    default "32"    if ARCH_32

    default "64"    if ARCH_64

choice

    bool

    prompt "Bitness:"

    default ARCH_32 if ARCH_DEFAULT_32

    default ARCH_64 if ARCH_DEFAULT_64

config ARCH_32

    bool

    prompt "32-bit"

    depends on ARCH_SUPPORTS_32

config ARCH_64

    bool

    prompt "64-bit"

    depends on ARCH_SUPPORTS_64

endchoice

#--------------------------------------

comment "Target optimisations"

config ARCH_SUPPORTS_WITH_ARCH

    bool

config ARCH_SUPPORTS_WITH_ABI

    bool

config ARCH_SUPPORTS_WITH_CPU

    bool

config ARCH_SUPPORTS_WITH_TUNE

    bool

config ARCH_SUPPORTS_WITH_FLOAT

    bool

config ARCH_SUPPORTS_WITH_FPU

    bool

config ARCH_SUPPORTS_SOFTFP

    bool

config ARCH_ARCH

    string

    prompt "Architecture level"

    depends on ARCH_SUPPORTS_WITH_ARCH

    default ""

    help

      GCC uses this name to determine what kind of instructions it can emit

      when generating assembly code. This option can be used in conjunction

      with or instead of the ARCH_CPU option (above), or a (command-line)

      -mcpu= option.

      This is the configuration flag --with-arch=XXXX, and the runtime flag

      -march=XXX.

      Pick a value from the gcc manual for your choosen gcc version and your

      target CPU.

      Leave blank if you don't know, or if your target architecture does not

      offer this option.

config ARCH_ABI

    string

    prompt "Generate code for the specific ABI"

    depends on ARCH_SUPPORTS_WITH_ABI

    default ""

    help

      Generate code for the given ABI.

      This is the configuration flag --with-abi=XXXX, and the runtime flag

      -mabi=XXX.

      Pick a value from the gcc manual for your choosen gcc version and your

      target CPU.

      Leave blank if you don't know, or if your target architecture does not

      offer this option.

config ARCH_CPU

    string

    prompt "Emit assembly for CPU"

    depends on ARCH_SUPPORTS_WITH_CPU

    default ""

    help

      This specifies the name of the target processor. GCC uses this name

      to determine what kind of instructions it can emit when generating

      assembly code.

      This is the configuration flag --with-cpu=XXXX, and the runtime flag

      -mcpu=XXX.

      Pick a value from the gcc manual for your choosen gcc version and your

      target CPU.

      Leave blank if you don't know, or if your target architecture does not

      offer this option.

config ARCH_TUNE

    string

    prompt "Tune for CPU"

    depends on ARCH_SUPPORTS_WITH_TUNE

    default ""

    help

      This option is very similar to the ARCH_CPU option (above), except

      that instead of specifying the actual target processor type, and hence

      restricting which instructions can be used, it specifies that GCC should

      tune the performance of the code as if the target were of the type

      specified in this option, but still choosing the instructions that it

      will generate based on the cpu specified by the ARCH_CPU option

      (above), or a (command-line) -mcpu= option.

      This is the configuration flag --with-tune=XXXX, and the runtime flag

      -mtune=XXX.

      Pick a value from the gcc manual for your choosen gcc version and your

      target CPU.

      Leave blank if you don't know, or if your target architecture does not

      offer this option.

config ARCH_FPU

    string

    prompt "Use specific FPU"

    depends on ARCH_SUPPORTS_WITH_FPU

    default ""

    help

      On some targets (eg. ARM), you can specify the kind of FPU to emit

      code for.

      This is the configuration flag --with-fpu=XXX, and the runtime flag

      -mfpu=XXX.

      See below wether to actually emit FP opcodes, or to emulate them.

      Pick a value from the gcc manual for your choosen gcc version and your

      target CPU.

      Leave blank if you don't know, or if your target architecture does not

      offer this option.

choice

    bool

    prompt "Floating point:"

    depends on ARCH_SUPPORTS_WITH_FLOAT

config ARCH_FLOAT_HW

    bool

    prompt "hardware (FPU)"

    help

      Emit hardware floating point opcodes.

      If you've got a processor with a FPU, then you want that.

      If your hardware has no FPU, you still can use HW floating point, but

      need to compile support for FPU emulation in your kernel. Needless to

      say that emulating the FPU is /slooowwwww/...

      One situation you'd want HW floating point without a FPU is if you get

      binary blobs from different vendors that are compiling this way and

      can't (don't wan't to) change.

config ARCH_FLOAT_SOFTFP

    bool

    prompt "softfp (FPU)"

    depends on ARCH_SUPPORTS_SOFTFP

    help

      Emit hardware floating point opcodes but use the software

      floating point calling convention.

      Architectures such as ARM use different registers for passing

      floating point values depending on if they're in software mode

      or hardware mode.  softfp emits FPU instructions but uses the

      software FP calling convention allowing softfp code to

      interoperate with legacy software only code.

      If in doubt, use 'software' or 'hardware' mode instead.

config ARCH_FLOAT_SW

    bool

    prompt "software (no FPU)"

    help

      Do not emit any hardware floating point opcode.

      If your processor has no FPU, then you most probably want this, as it

      is faster than emulating the FPU in the kernel.

endchoice

config TARGET_CFLAGS

    string

    prompt "Target CFLAGS"

    default ""

    help

      Used to add specific options when compiling libraries of the toolchain,

      that will run on the target (eg. libc.so).

      Note that the options above for ARCH, ABI, CPU, TUNE and FPU will be

      automatically used. You don't need to specify them here.

      Leave blank if you don't know better.

config TARGET_LDFLAGS

    string

    prompt "Target LDFLAGS"

    default ""

    help

      Used to add specific options when linking libraries of the toolchain,

      that will run on your target.

      Leave blank if you don't know better.

config ARCH_FLOAT

    string

    default ""       if ! ARCH_SUPPORTS_WITH_FLOAT

    default "hard"   if ARCH_FLOAT_HW

    default "soft"   if ARCH_FLOAT_SW

    default "softfp" if ARCH_FLOAT_SOFTFP

source "config.gen/arch.in.2"

endmenu