patrick/zephyr
1
0
Fork 0
Code Issues Pull requests Actions 8 Packages Projects Releases Wiki Activity
zephyr/CMakeLists.txt

1469 lines
50 KiB
CMake
Raw Normal View History

cmake: Move root CMakeLists.txt's comment-header to top Inform user early on that ./CMakeLists.txt is not the top-level file. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2018-12-19 16:27:55 +01:00
# *DOCUMENTATION*
#
# Note that this is *NOT* the top-level CMakeLists.txt. That's in the
# application. See the Application Development Primer documentation
# for details.
#
# To see a list of typical targets execute "make usage"
# More info can be located in ./README.rst
# Comments in this file are targeted only to the developer, do not
# expect to learn how to build the kernel reading this file.
cmake: Improve user error feedback when -H$ZEPHYR_BASE is specified Users are sometimes mistakenly invoking cmake with $ZEPHYR_BASE set as the source directory. This user-error can occur if the user believes that the toplevel CMakeLists.txt file is at the root of the repo, or if the user uses the wrong path when invoking cmake. The error given when this user-error occurs is cryptic and undefined, so we replace it with what should be an easy-to-understand error message. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-06-04 11:47:45 +02:00
if(NOT DEFINED ZEPHYR_BINARY_DIR)
message(FATAL_ERROR "A user error has occured.
cmake was invoked with '${CMAKE_CURRENT_LIST_DIR}' specified as the source directory,
but it must be invoked with an application source directory,
such as '${CMAKE_CURRENT_LIST_DIR}/samples/hello_world'.
Debug variables:
CMAKE_CACHEFILE_DIR: ${CMAKE_CACHEFILE_DIR}
")
endif()
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
project(Zephyr-Kernel VERSION ${PROJECT_VERSION})
enable_language(C CXX ASM)
# Verify that the toolchain can compile a dummy file, if it is not we
# won't be able to test for compatiblity with certain C flags.
check_c_compiler_flag("" toolchain_is_ok)
assert(toolchain_is_ok "The toolchain is unable to build a dummy C file. See CMakeError.log.")
set(CMAKE_EXECUTABLE_SUFFIX .elf)
cmake: Use a variable for 'zephyr_prebuilt' There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:31:02 +01:00
set(ZEPHYR_PREBUILT_EXECUTABLE zephyr_prebuilt)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
set(OFFSETS_H_TARGET offsets_h)
set(SYSCALL_MACROS_H_TARGET syscall_macros_h_target)
set(SYSCALL_LIST_H_TARGET syscall_list_h_target)
set(DRIVER_VALIDATION_H_TARGET driver_validation_h_target)
set(KOBJ_TYPES_H_TARGET kobj_types_h_target)
set(LINKER_SCRIPT_TARGET linker_script_target)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
if(NOT PROPERTY_LINKER_SCRIPT_DEFINES)
set_property(GLOBAL PROPERTY PROPERTY_LINKER_SCRIPT_DEFINES -D__GCC_LINKER_CMD__)
endif()
define_property(GLOBAL PROPERTY PROPERTY_OUTPUT_FORMAT BRIEF_DOCS " " FULL_DOCS " ")
cmake: Whitespace and commentary fixes Cosmetics, no functional change expected. Fixed leading space alignment. Replaced tabs with spaces. Emulation error message output is now aligned. To locate tabs in cmake, the following bash is useful: grep -PRil "\t" * | grep -i cmake | grep -v ^sanity Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2018-12-19 10:40:57 +01:00
set_property( GLOBAL PROPERTY PROPERTY_OUTPUT_FORMAT elf32-little${ARCH}) # BFD format
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
cmake: Whitespace and commentary fixes Cosmetics, no functional change expected. Fixed leading space alignment. Replaced tabs with spaces. Emulation error message output is now aligned. To locate tabs in cmake, the following bash is useful: grep -PRil "\t" * | grep -i cmake | grep -v ^sanity Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2018-12-19 10:40:57 +01:00
# "zephyr_interface" is a source-less library that encapsulates all the global
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
# compiler options needed by all source files. All zephyr libraries,
# including the library named "zephyr" link with this library to
# obtain these flags.
cmake: Whitespace and commentary fixes Cosmetics, no functional change expected. Fixed leading space alignment. Replaced tabs with spaces. Emulation error message output is now aligned. To locate tabs in cmake, the following bash is useful: grep -PRil "\t" * | grep -i cmake | grep -v ^sanity Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2018-12-19 10:40:57 +01:00
# https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#interface-libraries
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
add_library(zephyr_interface INTERFACE)
cmake: Whitespace and commentary fixes Cosmetics, no functional change expected. Fixed leading space alignment. Replaced tabs with spaces. Emulation error message output is now aligned. To locate tabs in cmake, the following bash is useful: grep -PRil "\t" * | grep -i cmake | grep -v ^sanity Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2018-12-19 10:40:57 +01:00
# "zephyr" is a catch-all CMake library for source files that can be
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
# built purely with the include paths, defines, and other compiler
# flags that come with zephyr_interface.
zephyr_library_named(zephyr)
zephyr_include_directories(
kernel/include
arch/${ARCH}/include
build: support out of tree SoC definition Add the glue to make this work with SoC code outside of the tree. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2018-09-04 21:34:06 +02:00
${SOC_DIR}/${ARCH}/${SOC_PATH}
${SOC_DIR}/${ARCH}/${SOC_PATH}/include
${SOC_DIR}/${ARCH}/${SOC_FAMILY}/include
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
include
include/drivers
${PROJECT_BINARY_DIR}/include/generated
${USERINCLUDE}
${STDINCLUDE}
)
zephyr_compile_definitions(
KERNEL
__ZEPHYR__=1
coverage: build with -O0 to get more information per the gcov man page: You should compile your code without optimization if you plan to use gcov because the optimization, by combining some lines of code into one function, may not give you as much information . Fixes #5548 Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2018-01-03 18:26:19 +01:00
)
cmake: Use _FORTIFY_SOURCE only with optimizations enabled When compiling for native, some glibc versions has a check on the use of _FORTIFY_SOURCE without optimizations enabled and gives a preprocessor warning. Signed-off-by: Thomas Ebert Hansen <thoh@oticon.com>
2018-07-12 12:01:55 +02:00
if(NOT CONFIG_NO_OPTIMIZATIONS)
coverage: build with -O0 to get more information per the gcov man page: You should compile your code without optimization if you plan to use gcov because the optimization, by combining some lines of code into one function, may not give you as much information . Fixes #5548 Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2018-01-03 18:26:19 +01:00
zephyr_compile_definitions(
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
_FORTIFY_SOURCE=2
)
coverage: build with -O0 to get more information per the gcov man page: You should compile your code without optimization if you plan to use gcov because the optimization, by combining some lines of code into one function, may not give you as much information . Fixes #5548 Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2018-01-03 18:26:19 +01:00
endif()
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
build: use git version and hash for boot banner This uses the version and hash (git describe) and replaces the timestamp currently used in the boot banner. This works much better than using timestamps. It lets us point to the exact commit being used to run a certain application or test. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2018-04-10 04:53:26 +02:00
if(BUILD_VERSION)
zephyr_compile_definitions(
BUILD_VERSION=${BUILD_VERSION}
)
endif()
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
# We need to set an optimization level.
# Default to -Os
build: Added CONFIG_NO_OPTIMIZATIONS Added a new config option which lowers the compiler optimizations to -O0 independently of other flags. CONFIG_COVERAGE uses it now instead of having its own choice in CMakeLists.txt Fixes #5720 Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
2018-01-22 15:35:54 +01:00
# unless CONFIG_NO_OPTIMIZATIONS is set, then it is -O0
# or unless CONFIG_DEBUG is set, then it is -Og
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
#
# also, some toolchain's break with -Os, and some toolchain's break
# with -Og so allow them to override what flag to use
#
# Finally, the user can use Kconfig to add compiler options that will
# come after these options and override them
build: Added CONFIG_NO_OPTIMIZATIONS Added a new config option which lowers the compiler optimizations to -O0 independently of other flags. CONFIG_COVERAGE uses it now instead of having its own choice in CMakeLists.txt Fixes #5720 Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
2018-01-22 15:35:54 +01:00
set_ifndef(OPTIMIZE_FOR_NO_OPTIMIZATIONS_FLAG "-O0")
kconfig: Change how optimization level is set This patch does several things, most notably it changes the semantics of CONFIG_DEBUG. CONFIG_DEBUG continues to behave as a vaguely defined "debug mode" that enables printf's, -Og, etc. but now the user may choose to be in "debug mode" while using a different optimization level than -Og. Tp support this a new config is defined to enable -Og; CONFIG_DEBUG_OPTIMIZATIONS. Additionally CONFIG_SIZE_OPTIMIZATIONS is introduced to allow the user to explicitly request optimizing for size instead of relying on defaulting to it. The three config's {NO,SIZE,DEBUG}_OPTIMIZATIONS are now organized in a Kconfig choice to ensure that at most one can be enabled at a time. Finally, selected users of CONFIG_DEBUG have been ported to use one of the optimizations configs when it was clear from usage that the intention was to behave differently when using a different optimization level and not when in "debug mode". Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-01-24 10:40:32 +01:00
set_ifndef(OPTIMIZE_FOR_DEBUG_FLAG "-Og")
set_ifndef(OPTIMIZE_FOR_SIZE_FLAG "-Os")
kconfig: add a compiler speed optimization Zephyr currently allows users to choose a compiler optimization between -O0, -Og and -Os, the default being the latter as it offers a good compromise between speed and flash usage. In cases the speed matters and/or the flash usage doesn't, optimizing for speed with -O2 is another alternative. For example in case of a simple application doing cryptographic signature validation with mbedtls, the flash size increase by about 15% compared to -Os, while it provides a 15% speed boost for a RSA signature and 30% speed boost for a ECC signature. This patches therefore adds a new option CONFIG_SPEED_OPTIMIZATIONS corresponding to the -O2 flag, but keep the default set to CONFIG_SIZE_OPTIMIZATIONS. Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2018-06-16 23:40:04 +02:00
set_ifndef(OPTIMIZE_FOR_SPEED_FLAG "-O2")
kconfig: Change how optimization level is set This patch does several things, most notably it changes the semantics of CONFIG_DEBUG. CONFIG_DEBUG continues to behave as a vaguely defined "debug mode" that enables printf's, -Og, etc. but now the user may choose to be in "debug mode" while using a different optimization level than -Og. Tp support this a new config is defined to enable -Og; CONFIG_DEBUG_OPTIMIZATIONS. Additionally CONFIG_SIZE_OPTIMIZATIONS is introduced to allow the user to explicitly request optimizing for size instead of relying on defaulting to it. The three config's {NO,SIZE,DEBUG}_OPTIMIZATIONS are now organized in a Kconfig choice to ensure that at most one can be enabled at a time. Finally, selected users of CONFIG_DEBUG have been ported to use one of the optimizations configs when it was clear from usage that the intention was to behave differently when using a different optimization level and not when in "debug mode". Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-01-24 10:40:32 +01:00
build: Added CONFIG_NO_OPTIMIZATIONS Added a new config option which lowers the compiler optimizations to -O0 independently of other flags. CONFIG_COVERAGE uses it now instead of having its own choice in CMakeLists.txt Fixes #5720 Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
2018-01-22 15:35:54 +01:00
if(CONFIG_NO_OPTIMIZATIONS)
kconfig: Change how optimization level is set This patch does several things, most notably it changes the semantics of CONFIG_DEBUG. CONFIG_DEBUG continues to behave as a vaguely defined "debug mode" that enables printf's, -Og, etc. but now the user may choose to be in "debug mode" while using a different optimization level than -Og. Tp support this a new config is defined to enable -Og; CONFIG_DEBUG_OPTIMIZATIONS. Additionally CONFIG_SIZE_OPTIMIZATIONS is introduced to allow the user to explicitly request optimizing for size instead of relying on defaulting to it. The three config's {NO,SIZE,DEBUG}_OPTIMIZATIONS are now organized in a Kconfig choice to ensure that at most one can be enabled at a time. Finally, selected users of CONFIG_DEBUG have been ported to use one of the optimizations configs when it was clear from usage that the intention was to behave differently when using a different optimization level and not when in "debug mode". Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-01-24 10:40:32 +01:00
set(OPTIMIZATION_FLAG ${OPTIMIZE_FOR_NO_OPTIMIZATIONS_FLAG})
elseif(CONFIG_DEBUG_OPTIMIZATIONS)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
set(OPTIMIZATION_FLAG ${OPTIMIZE_FOR_DEBUG_FLAG})
kconfig: add a compiler speed optimization Zephyr currently allows users to choose a compiler optimization between -O0, -Og and -Os, the default being the latter as it offers a good compromise between speed and flash usage. In cases the speed matters and/or the flash usage doesn't, optimizing for speed with -O2 is another alternative. For example in case of a simple application doing cryptographic signature validation with mbedtls, the flash size increase by about 15% compared to -Os, while it provides a 15% speed boost for a RSA signature and 30% speed boost for a ECC signature. This patches therefore adds a new option CONFIG_SPEED_OPTIMIZATIONS corresponding to the -O2 flag, but keep the default set to CONFIG_SIZE_OPTIMIZATIONS. Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2018-06-16 23:40:04 +02:00
elseif(CONFIG_SPEED_OPTIMIZATIONS)
set(OPTIMIZATION_FLAG ${OPTIMIZE_FOR_SPEED_FLAG})
kconfig: Change how optimization level is set This patch does several things, most notably it changes the semantics of CONFIG_DEBUG. CONFIG_DEBUG continues to behave as a vaguely defined "debug mode" that enables printf's, -Og, etc. but now the user may choose to be in "debug mode" while using a different optimization level than -Og. Tp support this a new config is defined to enable -Og; CONFIG_DEBUG_OPTIMIZATIONS. Additionally CONFIG_SIZE_OPTIMIZATIONS is introduced to allow the user to explicitly request optimizing for size instead of relying on defaulting to it. The three config's {NO,SIZE,DEBUG}_OPTIMIZATIONS are now organized in a Kconfig choice to ensure that at most one can be enabled at a time. Finally, selected users of CONFIG_DEBUG have been ported to use one of the optimizations configs when it was clear from usage that the intention was to behave differently when using a different optimization level and not when in "debug mode". Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-01-24 10:40:32 +01:00
elseif(CONFIG_SIZE_OPTIMIZATIONS)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
set(OPTIMIZATION_FLAG ${OPTIMIZE_FOR_SIZE_FLAG}) # Default
kconfig: Change how optimization level is set This patch does several things, most notably it changes the semantics of CONFIG_DEBUG. CONFIG_DEBUG continues to behave as a vaguely defined "debug mode" that enables printf's, -Og, etc. but now the user may choose to be in "debug mode" while using a different optimization level than -Og. Tp support this a new config is defined to enable -Og; CONFIG_DEBUG_OPTIMIZATIONS. Additionally CONFIG_SIZE_OPTIMIZATIONS is introduced to allow the user to explicitly request optimizing for size instead of relying on defaulting to it. The three config's {NO,SIZE,DEBUG}_OPTIMIZATIONS are now organized in a Kconfig choice to ensure that at most one can be enabled at a time. Finally, selected users of CONFIG_DEBUG have been ported to use one of the optimizations configs when it was clear from usage that the intention was to behave differently when using a different optimization level and not when in "debug mode". Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-01-24 10:40:32 +01:00
else()
assert(0 "Unreachable code. Expected optimization level to have been chosen. See misc/Kconfig.")
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
endif()
Build: Improve C++ support Can choose the C++ standard (C++98/11/14/17/2a) Can link with standard C++ library (libstdc++) Add support of C++ exceptions Add support of C++ RTTI Add C++ options to subsys/cpp/Kconfig Implements new and delete using k_malloc and k_free if CONFIG_HEAP_MEM_POOL_SIZE is defined Signed-off-by: Benoit Leforestier <benoit.leforestier@gmail.com>
2018-10-23 18:20:51 +02:00
# Dialects of C++, corresponding to the multiple published ISO standards.
# Which standard it implements can be selected using the -std= command-line option.
set_ifndef(DIALECT_STD_CPP98 "c++98")
set_ifndef(DIALECT_STD_CPP11 "c++11")
set_ifndef(DIALECT_STD_CPP14 "c++14")
set_ifndef(DIALECT_STD_CPP17 "c++17")
set_ifndef(DIALECT_STD_CPP2A "c++2a")
if(CONFIG_STD_CPP98)
set(STD_CPP_DIALECT ${DIALECT_STD_CPP98})
elseif(CONFIG_STD_CPP11)
set(STD_CPP_DIALECT ${DIALECT_STD_CPP11}) # Default
elseif(CONFIG_STD_CPP14)
set(STD_CPP_DIALECT ${DIALECT_STD_CPP14})
elseif(CONFIG_STD_CPP17)
set(STD_CPP_DIALECT ${DIALECT_STD_CPP17})
elseif(CONFIG_STD_CPP2A)
set(STD_CPP_DIALECT ${DIALECT_STD_CPP2A})
else()
assert(0 "Unreachable code. Expected C++ standard to have been chosen. See misc/Kconfig.")
endif()
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
zephyr_compile_options(
${OPTIMIZATION_FLAG} # Usually -Os
-g # TODO: build configuration enough?
-Wall
-Wformat
-Wformat-security
-Wno-format-zero-length
arch: native: Run Zephyr natively in a POSIX OS A new arch (posix) which relies on pthreads to emulate the context switching A new soc for it (inf_clock) which emulates a CPU running at an infinely high clock (so when the CPU is awaken it runs till completion in 0 time) A new board, which provides a trivial system tick timer and irq generation. Origin: Original Fixes #1891 Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com> Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-10-03 16:31:55 +02:00
-imacros ${AUTOCONF_H}
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
-ffreestanding
arch: native: Run Zephyr natively in a POSIX OS A new arch (posix) which relies on pthreads to emulate the context switching A new soc for it (inf_clock) which emulates a CPU running at an infinely high clock (so when the CPU is awaken it runs till completion in 0 time) A new board, which provides a trivial system tick timer and irq generation. Origin: Original Fixes #1891 Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com> Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-10-03 16:31:55 +02:00
-Wno-main
CMakeLists.txt: Enable -fno-common globally. This is needed to force the .common type to .bss type. This will force the .common variables to go into bss section in the compiled object file. As of now the movement to the .bss section was happening only during the final linking stage. The -fno-common option specifies that the compiler should place uninitialized global variables in the data section of the object file, rather than generating them as common blocks. This has the effect that if the same variable is declared (without "extern") in two different compilations, you will get a multiple-definition error when you link them. e.g: // file a.c // file-scope int b; // file b.c // file-scope int b; If there exist two non-extern declarations of the same variable then no-common will cause a linker error. This sequence would have compiled before, but will now cause a linker error. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-11-27 10:43:33 +01:00
-fno-common
arch: native: Run Zephyr natively in a POSIX OS A new arch (posix) which relies on pthreads to emulate the context switching A new soc for it (inf_clock) which emulates a CPU running at an infinely high clock (so when the CPU is awaken it runs till completion in 0 time) A new board, which provides a trivial system tick timer and irq generation. Origin: Original Fixes #1891 Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com> Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-10-03 16:31:55 +02:00
${NOSTDINC_F}
xtensa: provide XCC compiler support for Xtensa This patchset provides Xtensa's xcc compiler support for Xtensa projects in Cmake. This requires the below environment variables to be defined aptly. The appropriate xcc license information also need to be supplied. ZEPHYR_GCC_VARIANT=xcc TOOLCHAIN_VER=RF-2015.3-linux XTENSA_CORE=cavs21_LX6HiFi3_RF3_WB16 XTENSA_SYSTEM=/opt/xtensa/XtDevTools/install/tools/ RF-2015.3-linux/XtensaTools/config/ XTENSA_BUILD_PATHS=/opt/xtensa/XtDevTools/install/builds/ Change-Id: Ib3c10e8095439b0e32276ff37c00eca8420773ec Signed-off-by: Rajavardhan Gundi <rajavardhan.gundi@intel.com> Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-12-12 18:59:37 +01:00
${TOOLCHAIN_C_FLAGS}
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
)
zephyr_compile_options(
Build: Improve C++ support Can choose the C++ standard (C++98/11/14/17/2a) Can link with standard C++ library (libstdc++) Add support of C++ exceptions Add support of C++ RTTI Add C++ options to subsys/cpp/Kconfig Implements new and delete using k_malloc and k_free if CONFIG_HEAP_MEM_POOL_SIZE is defined Signed-off-by: Benoit Leforestier <benoit.leforestier@gmail.com>
2018-10-23 18:20:51 +02:00
$<$<COMPILE_LANGUAGE:CXX>:-std=${STD_CPP_DIALECT}>
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
$<$<COMPILE_LANGUAGE:CXX>:-fcheck-new>
$<$<COMPILE_LANGUAGE:CXX>:-ffunction-sections>
$<$<COMPILE_LANGUAGE:CXX>:-fdata-sections>
$<$<COMPILE_LANGUAGE:ASM>:-xassembler-with-cpp>
$<$<COMPILE_LANGUAGE:ASM>:-D_ASMLANGUAGE>
)
Build: Improve C++ support Can choose the C++ standard (C++98/11/14/17/2a) Can link with standard C++ library (libstdc++) Add support of C++ exceptions Add support of C++ RTTI Add C++ options to subsys/cpp/Kconfig Implements new and delete using k_malloc and k_free if CONFIG_HEAP_MEM_POOL_SIZE is defined Signed-off-by: Benoit Leforestier <benoit.leforestier@gmail.com>
2018-10-23 18:20:51 +02:00
if(NOT CONFIG_RTTI)
zephyr_compile_options(
$<$<COMPILE_LANGUAGE:CXX>:-fno-rtti>
)
endif()
if(NOT CONFIG_EXCEPTIONS)
zephyr_compile_options(
$<$<COMPILE_LANGUAGE:CXX>:-fno-exceptions>
)
endif()
arch: ARM: set -mthumb, -mcpu, -mfpu and -mfloat-abi in linker flags Some toolchains are built with multilib enabled in order to provide multiple versions of the same library, optimized for different ABI or architecture. They require the the ABI/architecture/CPU selection options to be passed at linked time. This is important for example when linking with newlib. Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2018-11-26 13:48:34 +01:00
zephyr_ld_options(
${TOOLCHAIN_LD_FLAGS}
)
arch: native: Run Zephyr natively in a POSIX OS A new arch (posix) which relies on pthreads to emulate the context switching A new soc for it (inf_clock) which emulates a CPU running at an infinely high clock (so when the CPU is awaken it runs till completion in 0 time) A new board, which provides a trivial system tick timer and irq generation. Origin: Original Fixes #1891 Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com> Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-10-03 16:31:55 +02:00
if(NOT CONFIG_NATIVE_APPLICATION)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
zephyr_ld_options(
-nostdlib
-static
-no-pie
arch: native: Run Zephyr natively in a POSIX OS A new arch (posix) which relies on pthreads to emulate the context switching A new soc for it (inf_clock) which emulates a CPU running at an infinely high clock (so when the CPU is awaken it runs till completion in 0 time) A new board, which provides a trivial system tick timer and irq generation. Origin: Original Fixes #1891 Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com> Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-10-03 16:31:55 +02:00
)
endif()
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
Build: Improve C++ support Can choose the C++ standard (C++98/11/14/17/2a) Can link with standard C++ library (libstdc++) Add support of C++ exceptions Add support of C++ RTTI Add C++ options to subsys/cpp/Kconfig Implements new and delete using k_malloc and k_free if CONFIG_HEAP_MEM_POOL_SIZE is defined Signed-off-by: Benoit Leforestier <benoit.leforestier@gmail.com>
2018-10-23 18:20:51 +02:00
if(CONFIG_LIB_CPLUSPLUS)
zephyr_ld_options(
-lstdc++
)
endif()
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
# ==========================================================================
#
# cmake -DW=... settings
#
# W=1 - warnings that may be relevant and does not occur too often
# W=2 - warnings that occur quite often but may still be relevant
# W=3 - the more obscure warnings, can most likely be ignored
# ==========================================================================
if(W MATCHES "1")
zephyr_compile_options(
-Wextra
-Wunused
-Wno-unused-parameter
-Wmissing-declarations
-Wmissing-format-attribute
-Wold-style-definition
)
zephyr_cc_option(
-Wmissing-prototypes
-Wmissing-include-dirs
-Wunused-but-set-variable
-Wno-missing-field-initializers
)
endif()
if(W MATCHES "2")
zephyr_compile_options(
-Waggregate-return
-Wcast-align
-Wdisabled-optimization
-Wnested-externs
-Wshadow
)
zephyr_cc_option(
-Wlogical-op
-Wmissing-field-initializers
)
endif()
if(W MATCHES "3")
zephyr_compile_options(
-Wbad-function-cast
-Wcast-qual
-Wconversion
-Wpacked
-Wpadded
-Wpointer-arith
-Wredundant-decls
-Wswitch-default
)
zephyr_cc_option(
-Wpacked-bitfield-compat
-Wvla
)
endif()
# Allow the user to inject options when calling cmake, e.g.
# 'cmake -DEXTRA_CFLAGS="-Werror -Wno-deprecated-declarations" ..'
cmake: Refactored EXTRA_FLAGS code into a dedicated script Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-11-10 12:22:23 +01:00
include(cmake/extra_flags.cmake)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
if(CONFIG_READABLE_ASM)
zephyr_cc_option(-fno-reorder-blocks)
zephyr_cc_option(-fno-ipa-cp-clone)
zephyr_cc_option(-fno-partial-inlining)
endif()
zephyr_cc_option(-fno-asynchronous-unwind-tables)
zephyr_cc_option(-fno-pie)
zephyr_cc_option(-fno-pic)
zephyr_cc_option(-fno-strict-overflow)
zephyr_cc_option(-Wno-pointer-sign)
kernel: fix x86 stack protector with later GCC Newer versions of GCC default to using thread-local storage ABI for the canary value instead of a global. We don't implement TLS in Zephyr like this (at least for now) so specify that we want to use the global instead. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2018-12-07 19:19:34 +01:00
if(CONFIG_STACK_CANARIES)
zephyr_cc_option(-fstack-protector-all)
# Only a valid option with GCC 7.x and above
check_c_compiler_flag(-mstack-protector-guard=global MSTACK_PROTECTOR_GUARD)
if(MSTACK_PROTECTOR_GUARD)
zephyr_cc_option(-mstack-protector-guard=global)
endif()
endif()
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
if(CONFIG_OVERRIDE_FRAME_POINTER_DEFAULT)
if(CONFIG_OMIT_FRAME_POINTER)
zephyr_cc_option(-fomit-frame-pointer)
else()
zephyr_cc_option(-fno-omit-frame-pointer)
endif()
endif()
cmake: allow multiple compiler options It is currently not possible to define multiple compiler options using the CONFIG_COMPILER_OPT Kconfig option. The string is interpreted as a single quoted option, for example "-opt1 -opt2". This patch fixes that by splitting the CONFIG_COMPILER_OPT string into multiple options using the separate_arguments cmake function. Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2018-06-16 23:40:04 +02:00
separate_arguments(CONFIG_COMPILER_OPT_AS_LIST UNIX_COMMAND ${CONFIG_COMPILER_OPT})
zephyr_compile_options(${CONFIG_COMPILER_OPT_AS_LIST})
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
# TODO: Include arch compiler options at this point.
if(CMAKE_C_COMPILER_ID STREQUAL "Clang")
zephyr_cc_option(
clang/llvm: add initial configuration file for clang Add an LLVM backend and a clang toolchain variant to support building with llvm coming with popular Linux distributions. This has been tested with X86 boards: - quark_d2000_crb - quark_se_c1000_devboard/Arduino 101 Use: export ZEPHYR_TOOLCHAIN_VARIANT=clang Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2018-05-02 07:09:31 +02:00
#FIXME: need to fix all of those
-Wno-sometimes-uninitialized
-Wno-shift-overflow
-Wno-missing-braces
-Wno-self-assign
-Wno-address-of-packed-member
-Wno-unused-function
-Wno-initializer-overrides
-Wno-section
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
-Wno-unknown-warning-option
-Wno-unused-variable
-Wno-format-invalid-specifier
-Wno-gnu
# comparison of unsigned expression < 0 is always false
-Wno-tautological-compare
)
else() # GCC assumed
zephyr_cc_option(
-Wno-unused-but-set-variable
-fno-reorder-functions
)
xtensa: provide XCC compiler support for Xtensa This patchset provides Xtensa's xcc compiler support for Xtensa projects in Cmake. This requires the below environment variables to be defined aptly. The appropriate xcc license information also need to be supplied. ZEPHYR_GCC_VARIANT=xcc TOOLCHAIN_VER=RF-2015.3-linux XTENSA_CORE=cavs21_LX6HiFi3_RF3_WB16 XTENSA_SYSTEM=/opt/xtensa/XtDevTools/install/tools/ RF-2015.3-linux/XtensaTools/config/ XTENSA_BUILD_PATHS=/opt/xtensa/XtDevTools/install/builds/ Change-Id: Ib3c10e8095439b0e32276ff37c00eca8420773ec Signed-off-by: Rajavardhan Gundi <rajavardhan.gundi@intel.com> Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-12-12 18:59:37 +01:00
build: deprecate ZEPHYR_GCC_VARIANT We want to support other toolchain not based on GCC, so the variable is confusing, use ZEPHYR_TOOLCHAIN_VARIANT instead. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2018-02-11 21:36:21 +01:00
if(NOT ${ZEPHYR_TOOLCHAIN_VARIANT} STREQUAL "xcc")
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
zephyr_cc_option(-fno-defer-pop)
endif()
endif()
zephyr_cc_option_ifdef(CONFIG_STACK_USAGE -fstack-usage)
zephyr_system_include_directories(${NOSTDINC})
# Force an error when things like SYS_INIT(foo, ...) occur with a missing header.
zephyr_cc_option(-Werror=implicit-int)
portability: Warn at void* arithmetics which is a GNU C extension Ensure future commits do not re-introduce use of this GNU C extension. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2018-09-14 14:24:53 +02:00
# Prohibit void pointer arithmetic. Illegal in C99
zephyr_cc_option(-Wpointer-arith)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
# Prohibit date/time macros, which would make the build non-deterministic
# cc-option(-Werror=date-time)
# TODO: Archiver arguments
# ar_option(D)
cmake: Move MPU userspace declaration up. This is done to make future modifications simpler, as more variables and functions are available. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-11-29 10:08:08 +01:00
# Declare MPU userspace dependencies before the linker scripts to make
# sure the order of dependencies are met
if(CONFIG_CPU_HAS_MPU AND CONFIG_USERSPACE)
if(CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT AND CONFIG_APP_SHARED_MEM )
set(APP_SMEM_DEP app_smem_linker)
endif()
if(CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT AND CONFIG_ARC AND CONFIG_APPLICATION_MEMORY)
set(ALIGN_SIZING_DEP app_sizing_prebuilt linker_app_sizing_script)
endif()
if(CONFIG_ARM)
set(PRIV_STACK_DEP priv_stacks_prebuilt)
endif()
endif()
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
set_ifndef(LINKERFLAGPREFIX -Wl)
arch: native: Run Zephyr natively in a POSIX OS A new arch (posix) which relies on pthreads to emulate the context switching A new soc for it (inf_clock) which emulates a CPU running at an infinely high clock (so when the CPU is awaken it runs till completion in 0 time) A new board, which provides a trivial system tick timer and irq generation. Origin: Original Fixes #1891 Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com> Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-10-03 16:31:55 +02:00
if(NOT CONFIG_NATIVE_APPLICATION)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
zephyr_ld_options(
${LINKERFLAGPREFIX},-X
${LINKERFLAGPREFIX},-N
arch: native: Run Zephyr natively in a POSIX OS A new arch (posix) which relies on pthreads to emulate the context switching A new soc for it (inf_clock) which emulates a CPU running at an infinely high clock (so when the CPU is awaken it runs till completion in 0 time) A new board, which provides a trivial system tick timer and irq generation. Origin: Original Fixes #1891 Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com> Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-10-03 16:31:55 +02:00
)
endif()
zephyr_ld_options(
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
${LINKERFLAGPREFIX},--gc-sections
${LINKERFLAGPREFIX},--build-id=none
)
cmake: Move check for '-nostdinc' up. This is done to make future modifications simpler, as more variables and functions are available. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-11-29 10:12:38 +01:00
if(NOT CONFIG_NATIVE_APPLICATION)
set(NOSTDINC_F -nostdinc)
endif()
cmake: Move check for TOTP property up. This is done to make future modifications simpler, as more variables and functions are available. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-11-29 10:14:27 +01:00
get_property(TOPT GLOBAL PROPERTY TOPT)
set_ifndef( TOPT -T)
linker: warn about orphan sections (Previous patch set was reverted due to issue with priv_stack. Resubmitting after fixing the faults caused by priv_stack.noinit not at the end of RAM.) This adds a linker flag and necessary changes to linker scripts so that linker will warn about orphan sections. Relates to #5534. Fixes #10473, #10474, #10515. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2018-10-19 19:15:19 +02:00
if(NOT CONFIG_NATIVE_APPLICATION)
# Funny thing is if this is set to =error, some architectures will
# skip this flag even though the compiler flag check passes
# (e.g. ARC and Xtensa). So warning should be the default for now.
#
# Skip this for native application as Zephyr only provides
# additions to the host toolchain linker script. The relocation
# sections (.rel*) requires us to override those provided
# by host toolchain. As we can't account for all possible
# combination of compiler and linker on all machines used
# for development, it is better to turn this off.
#
# CONFIG_LINKER_ORPHAN_SECTION_PLACE is to place the orphan sections
# without any warnings or errors, which is the default behavior.
# So there is no need to explicity set a linker flag.
if(CONFIG_LINKER_ORPHAN_SECTION_WARN)
zephyr_ld_options(
${LINKERFLAGPREFIX},--orphan-handling=warn
)
elseif(CONFIG_LINKER_ORPHAN_SECTION_ERROR)
zephyr_ld_options(
${LINKERFLAGPREFIX},--orphan-handling=error
)
endif()
endif()
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
if(CONFIG_HAVE_CUSTOM_LINKER_SCRIPT)
set(LINKER_SCRIPT ${APPLICATION_SOURCE_DIR}/${CONFIG_CUSTOM_LINKER_SCRIPT})
cmake: Fix CONFIG_CUSTOM_LINKER_SCRIPT Specifying a custom linker script is supposed to be supported through Kconfig, but evidently this has been unused and 100% broken at least since the CMake migration. This commit fixes https://github.com/zephyrproject-rtos/zephyr/issues/6983 Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-04-12 14:48:05 +02:00
if(NOT EXISTS ${LINKER_SCRIPT})
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
set(LINKER_SCRIPT ${CONFIG_CUSTOM_LINKER_SCRIPT})
cmake: Fix CONFIG_CUSTOM_LINKER_SCRIPT Specifying a custom linker script is supposed to be supported through Kconfig, but evidently this has been unused and 100% broken at least since the CMake migration. This commit fixes https://github.com/zephyrproject-rtos/zephyr/issues/6983 Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-04-12 14:48:05 +02:00
assert_exists(CONFIG_CUSTOM_LINKER_SCRIPT)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
endif()
else()
# Try a board specific linker file
set(LINKER_SCRIPT ${BOARD_DIR}/linker.ld)
if(NOT EXISTS ${LINKER_SCRIPT})
# If not available, try an SoC specific linker file
build: support out of tree SoC definition Add the glue to make this work with SoC code outside of the tree. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2018-09-04 21:34:06 +02:00
set(LINKER_SCRIPT ${SOC_DIR}/${ARCH}/${SOC_PATH}/linker.ld)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
endif()
endif()
if(NOT EXISTS ${LINKER_SCRIPT})
message(FATAL_ERROR "Could not find linker script: '${LINKER_SCRIPT}'. Corrupted configuration?")
endif()
cmake: ld: add application source dir to linker script cpp command To enable using application-defined sections in linker scripts, the application source directory must be included in the search path when running the preprocessor to generate linker scripts. This prevents build failures when using any of the configuration options CONFIG_CUSTOM_RODATA_LD, CONFIG_CUSTOM_RWDATA_LD and CONFIG_CUSTOM_SECTIONS_LD. Signed-off-by: Kristian Klomsten Skordal <kristian.skordal@nordicsemi.no>
2018-01-30 11:26:42 +01:00
# Custom section support in linker scripts requires that the application source
# directory is in the preprocessor search path, in order to find the custom
# linker script fragments.
if(CONFIG_CUSTOM_RODATA_LD OR CONFIG_CUSTOM_RWDATA_LD OR CONFIG_CUSTOM_SECTIONS_LD)
zephyr_include_directories(${APPLICATION_SOURCE_DIR})
endif()
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
configure_file(version.h.in ${PROJECT_BINARY_DIR}/include/generated/version.h)
cmake: Move helper function up, inline variable. This is done to make future modifications simpler, as more variables and functions are available. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-11-29 10:15:33 +01:00
function(construct_add_custom_command_for_linker_pass linker_output_name output_variable)
set(linker_cmd_file_name ${linker_output_name}.cmd)
if (${linker_output_name} MATCHES "^linker_pass_final$")
set(linker_pass_define -DLINKER_PASS2)
else()
set(linker_pass_define "")
endif()
# Different generators deal with depfiles differently.
if(CMAKE_GENERATOR STREQUAL "Unix Makefiles")
# Note that the IMPLICIT_DEPENDS option is currently supported only
# for Makefile generators and will be ignored by other generators.
set(linker_script_dep IMPLICIT_DEPENDS C ${LINKER_SCRIPT})
elseif(CMAKE_GENERATOR STREQUAL "Ninja")
# Using DEPFILE with other generators than Ninja is an error.
set(linker_script_dep DEPFILE ${PROJECT_BINARY_DIR}/${linker_cmd_file_name}.dep)
else()
# TODO: How would the linker script dependencies work for non-linker
# script generators.
message(STATUS "Warning; this generator is not well supported. The
Linker script may not be regenerated when it should.")
set(linker_script_dep "")
endif()
zephyr_get_include_directories_for_lang(C current_includes)
get_filename_component(base_name ${CMAKE_CURRENT_BINARY_DIR} NAME)
get_property(current_defines GLOBAL PROPERTY PROPERTY_LINKER_SCRIPT_DEFINES)
set(${output_variable}
OUTPUT ${linker_cmd_file_name}
DEPENDS ${LINKER_SCRIPT}
${linker_script_dep}
COMMAND ${CMAKE_C_COMPILER}
-x assembler-with-cpp
${NOSTDINC_F}
${NOSYSDEF_CFLAG}
-MD -MF ${linker_cmd_file_name}.dep -MT ${base_name}/${linker_cmd_file_name}
${current_includes}
${current_defines}
${linker_pass_define}
-E ${LINKER_SCRIPT}
-P # Prevent generation of debug `#line' directives.
-o ${linker_cmd_file_name}
VERBATIM
WORKING_DIRECTORY ${PROJECT_BINARY_DIR}
PARENT_SCOPE
)
endfunction()
cmake: Execute arch/CMakeLists.txt before subsys/CMakeList.txt Re-order the execution of the arch/ and subsys/ CMakeLists.txt code to work around a manifestation of issue #6505. When OpenThread created an External project in subsys, it did not have access to important toolchain flags added in arch/. Intuitively, subsystems might depends on how the ARCH is configured, but the ARCH shouldn't depend on any subsystem. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-01-09 10:52:57 +01:00
# Unfortunately, the order in which CMakeLists.txt code is processed
# matters so we need to be careful about how we order the processing
# of subdirectories. One example is "Compiler flags added late in the
# build are not exported to external build systems #5605"; when we
# integrate with an external build system we read out all compiler
# flags when the external project is created. So an external project
# defined in subsys or ext will not get global flags added by drivers/
# or tests/ as the subdirectories are ordered now.
#
# Another example of when the order matters is the reading and writing
# of global properties such as ZEPHYR_LIBS or
# GENERATED_KERNEL_OBJECT_FILES.
#
# Arch is placed early because it defines important compiler flags
# that must be exported to external build systems defined in
# e.g. subsys/.
add_subdirectory(arch)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
add_subdirectory(lib)
add_subdirectory(misc)
# We use include instead of add_subdirectory to avoid creating a new directory scope.
# This is because source file properties are directory scoped, including the GENERATED
# property which is set implicitly for custom command outputs
include(misc/generated/CMakeLists.txt)
soc: adapt Kconfig/CMake for soc in top / Change build system to point to soc/ in the top directory rather than under arch/ Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2018-09-03 22:20:14 +02:00
cmake: Add zephyr base address when looking file into soc/ When checking availability of soc/${ARCH}/CMakeLists.txt, we should use ${ZEPHYR_BASE} as path base. Fixes #9956 Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
2018-09-13 16:25:53 +02:00
if(EXISTS ${SOC_DIR}/${ARCH}/CMakeLists.txt)
build: support out of tree SoC definition Add the glue to make this work with SoC code outside of the tree. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2018-09-04 21:34:06 +02:00
add_subdirectory(${SOC_DIR}/${ARCH} soc/${ARCH})
soc: adapt Kconfig/CMake for soc in top / Change build system to point to soc/ in the top directory rather than under arch/ Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2018-09-03 22:20:14 +02:00
else()
build: support out of tree SoC definition Add the glue to make this work with SoC code outside of the tree. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2018-09-04 21:34:06 +02:00
add_subdirectory(${SOC_DIR}/${ARCH}/${SOC_PATH} soc/${ARCH}/${SOC_PATH})
soc: adapt Kconfig/CMake for soc in top / Change build system to point to soc/ in the top directory rather than under arch/ Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2018-09-03 22:20:14 +02:00
endif()
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
add_subdirectory(boards)
add_subdirectory(ext)
add_subdirectory(subsys)
add_subdirectory(drivers)
add_subdirectory(tests)
cmake: Move syscall_macros.h generation into the build stage This fixes https://github.com/zephyrproject-rtos/zephyr/issues/5186 The script that generates syscall_macros.h is moved from Configuration time to build time. This allows us to express to the build system that syscall_macros.h depends on the script that generates it. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-11-29 17:46:37 +01:00
set(syscall_macros_h ${ZEPHYR_BINARY_DIR}/include/generated/syscall_macros.h)
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
add_custom_target(${SYSCALL_MACROS_H_TARGET} DEPENDS ${syscall_macros_h})
cmake: Move syscall_macros.h generation into the build stage This fixes https://github.com/zephyrproject-rtos/zephyr/issues/5186 The script that generates syscall_macros.h is moved from Configuration time to build time. This allows us to express to the build system that syscall_macros.h depends on the script that generates it. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-11-29 17:46:37 +01:00
add_custom_command( OUTPUT ${syscall_macros_h}
COMMAND
${PYTHON_EXECUTABLE}
cmake: replace PROJECT_SOURCE_DIR with ZEPHYR_BASE Both variables were used (with the same value) interchangeably throughout CMake files and per the discussion in GH issue, ZEPHYR_BASE is preferred. Also add a comment with explanation of one vs. the other. Tested by building hello_world for several boards ensuring no errors. Fixes #7173. Signed-off-by: Alex Tereschenko <alext.mkrs@gmail.com>
2018-06-14 20:21:18 +02:00
${ZEPHYR_BASE}/scripts/gen_syscall_header.py
cmake: Move syscall_macros.h generation into the build stage This fixes https://github.com/zephyrproject-rtos/zephyr/issues/5186 The script that generates syscall_macros.h is moved from Configuration time to build time. This allows us to express to the build system that syscall_macros.h depends on the script that generates it. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-11-29 17:46:37 +01:00
> ${syscall_macros_h}
cmake: replace PROJECT_SOURCE_DIR with ZEPHYR_BASE Both variables were used (with the same value) interchangeably throughout CMake files and per the discussion in GH issue, ZEPHYR_BASE is preferred. Also add a comment with explanation of one vs. the other. Tested by building hello_world for several boards ensuring no errors. Fixes #7173. Signed-off-by: Alex Tereschenko <alext.mkrs@gmail.com>
2018-06-14 20:21:18 +02:00
DEPENDS ${ZEPHYR_BASE}/scripts/gen_syscall_header.py
cmake: Move syscall_macros.h generation into the build stage This fixes https://github.com/zephyrproject-rtos/zephyr/issues/5186 The script that generates syscall_macros.h is moved from Configuration time to build time. This allows us to express to the build system that syscall_macros.h depends on the script that generates it. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-11-29 17:46:37 +01:00
)
cmake: Re-organize syscall generation wrt. the build system This commit fixes https://github.com/zephyrproject-rtos/zephyr/issues/5008. It does so by splitting up gen_syscalls.py into two scripts with a json metadata file to communicate syscall metadata between them. The parsing script parses header files from include/ and writes syscall metadata to a file if the contents changed. The generation script reads from the json file and generates syscall code. The build system DAG now looks like this: always_rebuild -> json -> syscalls -> offset.o The script for generating json will do so only if the content changes, this ensures that the entire DAG does not always do a full rebuild. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-11-20 13:03:55 +01:00
set(syscall_list_h ${CMAKE_CURRENT_BINARY_DIR}/include/generated/syscall_list.h)
set(syscalls_json ${CMAKE_CURRENT_BINARY_DIR}/misc/generated/syscalls.json)
cmake: Update to dependency handling for syscalls.json Fixes: #8210 Following changes has been made to ensure correct behavior on different system: - Python script to detect changes to directories, including empty ones. When files are modified the list is updated If sub-directories are added / removed a trigger file is touched to notify cmake to re-run - Windows: To detect changes to header files in include for parse_syscalls.py all files must be individual monitored. Hence all headers are globbed added to dependencies. CMake configure depends on the folders so the added / removed files are picked up. - Other: Folders are monitored through the python list file so that added / remove / modified Added / removed sub-directories are detected through trigger file in order to re-run cmake. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-07 15:50:31 +02:00
# The syscalls subdirs txt file is constructed by python containing a list of folders to use for
# dependency handling, including empty folders.
# Windows: The list is used to specify DIRECTORY list with CMAKE_CONFIGURE_DEPENDS attribute.
# Other OS: The list will update whenever a file is added/removed/modified and ensure a re-build.
set(syscalls_subdirs_txt ${CMAKE_CURRENT_BINARY_DIR}/misc/generated/syscalls_subdirs.txt)
# As syscalls_subdirs_txt is updated whenever a file is modified, this file can not be used for
# monitoring of added / removed folders. A trigger file is thus used for correct dependency
# handling. The trigger file will update when a folder is added / removed.
set(syscalls_subdirs_trigger ${CMAKE_CURRENT_BINARY_DIR}/misc/generated/syscalls_subdirs.trigger)
cmake: Using symlinks on unix like os'es for dependencies Fixes: #8380 This commit fixes the side-effect of PR #8211 where a 'ninja clean' would try to remove dependency folders. Changes: - Symlinks are created during build and CMake targets now depends on the symlinks. Thus, same behavior is achived with regards to dependency handling, while at the same time, the output can be cleaned as the dependencies are now attached to the symlinks. - Dependencies have been changed so that generation of json files depends on the trigger file and CMake depends upon the subdir txt file. This prevents additional CMake runs after a clean. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-14 22:27:17 +02:00
if(NOT (${CMAKE_HOST_SYSTEM_NAME} STREQUAL Windows))
set(syscalls_links --create-links ${CMAKE_CURRENT_BINARY_DIR}/misc/generated/syscalls_links)
endif()
cmake: Update to dependency handling for syscalls.json Fixes: #8210 Following changes has been made to ensure correct behavior on different system: - Python script to detect changes to directories, including empty ones. When files are modified the list is updated If sub-directories are added / removed a trigger file is touched to notify cmake to re-run - Windows: To detect changes to header files in include for parse_syscalls.py all files must be individual monitored. Hence all headers are globbed added to dependencies. CMake configure depends on the folders so the added / removed files are picked up. - Other: Folders are monitored through the python list file so that added / remove / modified Added / removed sub-directories are detected through trigger file in order to re-run cmake. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-07 15:50:31 +02:00
# When running CMake it must be ensured that all dependencies are correctly acquired.
execute_process(
COMMAND
${PYTHON_EXECUTABLE}
cmake: replace PROJECT_SOURCE_DIR with ZEPHYR_BASE Both variables were used (with the same value) interchangeably throughout CMake files and per the discussion in GH issue, ZEPHYR_BASE is preferred. Also add a comment with explanation of one vs. the other. Tested by building hello_world for several boards ensuring no errors. Fixes #7173. Signed-off-by: Alex Tereschenko <alext.mkrs@gmail.com>
2018-06-14 20:21:18 +02:00
${ZEPHYR_BASE}/scripts/subfolder_list.py
cmake: Using symlinks on unix like os'es for dependencies Fixes: #8380 This commit fixes the side-effect of PR #8211 where a 'ninja clean' would try to remove dependency folders. Changes: - Symlinks are created during build and CMake targets now depends on the symlinks. Thus, same behavior is achived with regards to dependency handling, while at the same time, the output can be cleaned as the dependencies are now attached to the symlinks. - Dependencies have been changed so that generation of json files depends on the trigger file and CMake depends upon the subdir txt file. This prevents additional CMake runs after a clean. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-14 22:27:17 +02:00
--directory ${ZEPHYR_BASE}/include # Walk this directory
--out-file ${syscalls_subdirs_txt} # Write file with discovered folder
--trigger ${syscalls_subdirs_trigger} # Trigger file that is used for json generation
${syscalls_links} # If defined, create symlinks for dependencies
)
cmake: Update to dependency handling for syscalls.json Fixes: #8210 Following changes has been made to ensure correct behavior on different system: - Python script to detect changes to directories, including empty ones. When files are modified the list is updated If sub-directories are added / removed a trigger file is touched to notify cmake to re-run - Windows: To detect changes to header files in include for parse_syscalls.py all files must be individual monitored. Hence all headers are globbed added to dependencies. CMake configure depends on the folders so the added / removed files are picked up. - Other: Folders are monitored through the python list file so that added / remove / modified Added / removed sub-directories are detected through trigger file in order to re-run cmake. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-07 15:50:31 +02:00
file(STRINGS ${syscalls_subdirs_txt} PARSE_SYSCALLS_PATHS_DEPENDS)
if(${CMAKE_HOST_SYSTEM_NAME} STREQUAL Windows)
# On windows only adding/removing files or folders will be reflected in depends.
# Hence adding a file requires CMake to re-run to add this file to the file list.
set_property(DIRECTORY APPEND PROPERTY CMAKE_CONFIGURE_DEPENDS ${PARSE_SYSCALLS_PATHS_DEPENDS})
# Also On Windows each header file must be monitored as file modifications are not reflected
# on directory level.
cmake: replace PROJECT_SOURCE_DIR with ZEPHYR_BASE Both variables were used (with the same value) interchangeably throughout CMake files and per the discussion in GH issue, ZEPHYR_BASE is preferred. Also add a comment with explanation of one vs. the other. Tested by building hello_world for several boards ensuring no errors. Fixes #7173. Signed-off-by: Alex Tereschenko <alext.mkrs@gmail.com>
2018-06-14 20:21:18 +02:00
file(GLOB_RECURSE PARSE_SYSCALLS_HEADER_DEPENDS ${ZEPHYR_BASE}/include/*.h)
cmake: Update to dependency handling for syscalls.json Fixes: #8210 Following changes has been made to ensure correct behavior on different system: - Python script to detect changes to directories, including empty ones. When files are modified the list is updated If sub-directories are added / removed a trigger file is touched to notify cmake to re-run - Windows: To detect changes to header files in include for parse_syscalls.py all files must be individual monitored. Hence all headers are globbed added to dependencies. CMake configure depends on the folders so the added / removed files are picked up. - Other: Folders are monitored through the python list file so that added / remove / modified Added / removed sub-directories are detected through trigger file in order to re-run cmake. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-07 15:50:31 +02:00
else()
# The syscall parsing depends on the folders in order to detect add/removed/modified files.
# When a folder is removed, CMake will try to find a target that creates that dependency.
# This command sets up the target for CMake to find.
cmake: Using symlinks on unix like os'es for dependencies Fixes: #8380 This commit fixes the side-effect of PR #8211 where a 'ninja clean' would try to remove dependency folders. Changes: - Symlinks are created during build and CMake targets now depends on the symlinks. Thus, same behavior is achived with regards to dependency handling, while at the same time, the output can be cleaned as the dependencies are now attached to the symlinks. - Dependencies have been changed so that generation of json files depends on the trigger file and CMake depends upon the subdir txt file. This prevents additional CMake runs after a clean. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-14 22:27:17 +02:00
# Without this code, CMake will fail with the following error:
cmake: Update to dependency handling for syscalls.json Fixes: #8210 Following changes has been made to ensure correct behavior on different system: - Python script to detect changes to directories, including empty ones. When files are modified the list is updated If sub-directories are added / removed a trigger file is touched to notify cmake to re-run - Windows: To detect changes to header files in include for parse_syscalls.py all files must be individual monitored. Hence all headers are globbed added to dependencies. CMake configure depends on the folders so the added / removed files are picked up. - Other: Folders are monitored through the python list file so that added / remove / modified Added / removed sub-directories are detected through trigger file in order to re-run cmake. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-07 15:50:31 +02:00
# <folder> needed by '<target>', missing and no known rule to make it
# when a folder is removed.
add_custom_command(OUTPUT ${PARSE_SYSCALLS_PATHS_DEPENDS}
COMMAND ${CMAKE_COMMAND} -E echo ""
COMMENT "Preparing syscall dependency handling"
cmake: Using symlinks on unix like os'es for dependencies Fixes: #8380 This commit fixes the side-effect of PR #8211 where a 'ninja clean' would try to remove dependency folders. Changes: - Symlinks are created during build and CMake targets now depends on the symlinks. Thus, same behavior is achived with regards to dependency handling, while at the same time, the output can be cleaned as the dependencies are now attached to the symlinks. - Dependencies have been changed so that generation of json files depends on the trigger file and CMake depends upon the subdir txt file. This prevents additional CMake runs after a clean. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-14 22:27:17 +02:00
)
cmake: Update to dependency handling for syscalls.json Fixes: #8210 Following changes has been made to ensure correct behavior on different system: - Python script to detect changes to directories, including empty ones. When files are modified the list is updated If sub-directories are added / removed a trigger file is touched to notify cmake to re-run - Windows: To detect changes to header files in include for parse_syscalls.py all files must be individual monitored. Hence all headers are globbed added to dependencies. CMake configure depends on the folders so the added / removed files are picked up. - Other: Folders are monitored through the python list file so that added / remove / modified Added / removed sub-directories are detected through trigger file in order to re-run cmake. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-07 15:50:31 +02:00
add_custom_command(
OUTPUT
cmake: Using symlinks on unix like os'es for dependencies Fixes: #8380 This commit fixes the side-effect of PR #8211 where a 'ninja clean' would try to remove dependency folders. Changes: - Symlinks are created during build and CMake targets now depends on the symlinks. Thus, same behavior is achived with regards to dependency handling, while at the same time, the output can be cleaned as the dependencies are now attached to the symlinks. - Dependencies have been changed so that generation of json files depends on the trigger file and CMake depends upon the subdir txt file. This prevents additional CMake runs after a clean. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-14 22:27:17 +02:00
${syscalls_subdirs_trigger}
cmake: Update to dependency handling for syscalls.json Fixes: #8210 Following changes has been made to ensure correct behavior on different system: - Python script to detect changes to directories, including empty ones. When files are modified the list is updated If sub-directories are added / removed a trigger file is touched to notify cmake to re-run - Windows: To detect changes to header files in include for parse_syscalls.py all files must be individual monitored. Hence all headers are globbed added to dependencies. CMake configure depends on the folders so the added / removed files are picked up. - Other: Folders are monitored through the python list file so that added / remove / modified Added / removed sub-directories are detected through trigger file in order to re-run cmake. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-07 15:50:31 +02:00
COMMAND
${PYTHON_EXECUTABLE}
cmake: replace PROJECT_SOURCE_DIR with ZEPHYR_BASE Both variables were used (with the same value) interchangeably throughout CMake files and per the discussion in GH issue, ZEPHYR_BASE is preferred. Also add a comment with explanation of one vs. the other. Tested by building hello_world for several boards ensuring no errors. Fixes #7173. Signed-off-by: Alex Tereschenko <alext.mkrs@gmail.com>
2018-06-14 20:21:18 +02:00
${ZEPHYR_BASE}/scripts/subfolder_list.py
--directory ${ZEPHYR_BASE}/include # Walk this directory
cmake: Using symlinks on unix like os'es for dependencies Fixes: #8380 This commit fixes the side-effect of PR #8211 where a 'ninja clean' would try to remove dependency folders. Changes: - Symlinks are created during build and CMake targets now depends on the symlinks. Thus, same behavior is achived with regards to dependency handling, while at the same time, the output can be cleaned as the dependencies are now attached to the symlinks. - Dependencies have been changed so that generation of json files depends on the trigger file and CMake depends upon the subdir txt file. This prevents additional CMake runs after a clean. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-14 22:27:17 +02:00
--out-file ${syscalls_subdirs_txt} # Write file with discovered folder
--trigger ${syscalls_subdirs_trigger} # Trigger file that is used for json generation
${syscalls_links} # If defined, create symlinks for dependencies
cmake: Update to dependency handling for syscalls.json Fixes: #8210 Following changes has been made to ensure correct behavior on different system: - Python script to detect changes to directories, including empty ones. When files are modified the list is updated If sub-directories are added / removed a trigger file is touched to notify cmake to re-run - Windows: To detect changes to header files in include for parse_syscalls.py all files must be individual monitored. Hence all headers are globbed added to dependencies. CMake configure depends on the folders so the added / removed files are picked up. - Other: Folders are monitored through the python list file so that added / remove / modified Added / removed sub-directories are detected through trigger file in order to re-run cmake. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-07 15:50:31 +02:00
DEPENDS ${PARSE_SYSCALLS_PATHS_DEPENDS}
cmake: Using symlinks on unix like os'es for dependencies Fixes: #8380 This commit fixes the side-effect of PR #8211 where a 'ninja clean' would try to remove dependency folders. Changes: - Symlinks are created during build and CMake targets now depends on the symlinks. Thus, same behavior is achived with regards to dependency handling, while at the same time, the output can be cleaned as the dependencies are now attached to the symlinks. - Dependencies have been changed so that generation of json files depends on the trigger file and CMake depends upon the subdir txt file. This prevents additional CMake runs after a clean. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-14 22:27:17 +02:00
)
cmake: Update to dependency handling for syscalls.json Fixes: #8210 Following changes has been made to ensure correct behavior on different system: - Python script to detect changes to directories, including empty ones. When files are modified the list is updated If sub-directories are added / removed a trigger file is touched to notify cmake to re-run - Windows: To detect changes to header files in include for parse_syscalls.py all files must be individual monitored. Hence all headers are globbed added to dependencies. CMake configure depends on the folders so the added / removed files are picked up. - Other: Folders are monitored through the python list file so that added / remove / modified Added / removed sub-directories are detected through trigger file in order to re-run cmake. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-07 15:50:31 +02:00
cmake: Using symlinks on unix like os'es for dependencies Fixes: #8380 This commit fixes the side-effect of PR #8211 where a 'ninja clean' would try to remove dependency folders. Changes: - Symlinks are created during build and CMake targets now depends on the symlinks. Thus, same behavior is achived with regards to dependency handling, while at the same time, the output can be cleaned as the dependencies are now attached to the symlinks. - Dependencies have been changed so that generation of json files depends on the trigger file and CMake depends upon the subdir txt file. This prevents additional CMake runs after a clean. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-14 22:27:17 +02:00
# Ensure subdir file always exists when specifying CMake dependency.
if(NOT EXISTS ${syscalls_subdirs_txt})
file(WRITE ${syscalls_subdirs_txt} "")
cmake: Update to dependency handling for syscalls.json Fixes: #8210 Following changes has been made to ensure correct behavior on different system: - Python script to detect changes to directories, including empty ones. When files are modified the list is updated If sub-directories are added / removed a trigger file is touched to notify cmake to re-run - Windows: To detect changes to header files in include for parse_syscalls.py all files must be individual monitored. Hence all headers are globbed added to dependencies. CMake configure depends on the folders so the added / removed files are picked up. - Other: Folders are monitored through the python list file so that added / remove / modified Added / removed sub-directories are detected through trigger file in order to re-run cmake. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-07 15:50:31 +02:00
endif()
# On other OS'es, modifying a file is reflected on the folder timestamp and hence detected
# when using depend on directory level.
# Thus CMake only needs to re-run when sub-directories are added / removed, which is indicated
# using a trigger file.
cmake: Using symlinks on unix like os'es for dependencies Fixes: #8380 This commit fixes the side-effect of PR #8211 where a 'ninja clean' would try to remove dependency folders. Changes: - Symlinks are created during build and CMake targets now depends on the symlinks. Thus, same behavior is achived with regards to dependency handling, while at the same time, the output can be cleaned as the dependencies are now attached to the symlinks. - Dependencies have been changed so that generation of json files depends on the trigger file and CMake depends upon the subdir txt file. This prevents additional CMake runs after a clean. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-14 22:27:17 +02:00
set_property(DIRECTORY APPEND PROPERTY CMAKE_CONFIGURE_DEPENDS ${syscalls_subdirs_txt})
cmake: Update to dependency handling for syscalls.json Fixes: #8210 Following changes has been made to ensure correct behavior on different system: - Python script to detect changes to directories, including empty ones. When files are modified the list is updated If sub-directories are added / removed a trigger file is touched to notify cmake to re-run - Windows: To detect changes to header files in include for parse_syscalls.py all files must be individual monitored. Hence all headers are globbed added to dependencies. CMake configure depends on the folders so the added / removed files are picked up. - Other: Folders are monitored through the python list file so that added / remove / modified Added / removed sub-directories are detected through trigger file in order to re-run cmake. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-07 15:50:31 +02:00
endif()
syscalls: Scan multiple folders to build complete syscall list Previously the syscall list was generated only from the include folder. This is a limitation when the application tries to create system calls. This patch create a simple way to include these new syscalls without the application touching the kernel. This can be enabled by a Kconfig CONFIG_APPLICATION_DEFINED_SYSCALL. Once enabled the application source directory will be scanned to find all application defined syscalls. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-07-02 11:29:19 +02:00
# SYSCALL_INCLUDE_DIRECTORY will include the directories that needs to be
# searched for syscall declarations if CONFIG_APPLICATION_DEFINED_SYSCALL is set
if(CONFIG_APPLICATION_DEFINED_SYSCALL)
set(SYSCALL_INCLUDE_DIRECTORY --include ${APPLICATION_SOURCE_DIR})
endif()
cmake: Re-organize syscall generation wrt. the build system This commit fixes https://github.com/zephyrproject-rtos/zephyr/issues/5008. It does so by splitting up gen_syscalls.py into two scripts with a json metadata file to communicate syscall metadata between them. The parsing script parses header files from include/ and writes syscall metadata to a file if the contents changed. The generation script reads from the json file and generates syscall code. The build system DAG now looks like this: always_rebuild -> json -> syscalls -> offset.o The script for generating json will do so only if the content changes, this ensures that the entire DAG does not always do a full rebuild. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-11-20 13:03:55 +01:00
add_custom_command(
OUTPUT
${syscalls_json}
COMMAND
${PYTHON_EXECUTABLE}
cmake: replace PROJECT_SOURCE_DIR with ZEPHYR_BASE Both variables were used (with the same value) interchangeably throughout CMake files and per the discussion in GH issue, ZEPHYR_BASE is preferred. Also add a comment with explanation of one vs. the other. Tested by building hello_world for several boards ensuring no errors. Fixes #7173. Signed-off-by: Alex Tereschenko <alext.mkrs@gmail.com>
2018-06-14 20:21:18 +02:00
${ZEPHYR_BASE}/scripts/parse_syscalls.py
syscalls: Scan multiple folders to build complete syscall list Previously the syscall list was generated only from the include folder. This is a limitation when the application tries to create system calls. This patch create a simple way to include these new syscalls without the application touching the kernel. This can be enabled by a Kconfig CONFIG_APPLICATION_DEFINED_SYSCALL. Once enabled the application source directory will be scanned to find all application defined syscalls. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-07-02 11:29:19 +02:00
--include ${ZEPHYR_BASE}/include # Read files from this dir
${SYSCALL_INCLUDE_DIRECTORY}
cmake: Using symlinks on unix like os'es for dependencies Fixes: #8380 This commit fixes the side-effect of PR #8211 where a 'ninja clean' would try to remove dependency folders. Changes: - Symlinks are created during build and CMake targets now depends on the symlinks. Thus, same behavior is achived with regards to dependency handling, while at the same time, the output can be cleaned as the dependencies are now attached to the symlinks. - Dependencies have been changed so that generation of json files depends on the trigger file and CMake depends upon the subdir txt file. This prevents additional CMake runs after a clean. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-14 22:27:17 +02:00
--json-file ${syscalls_json} # Write this file
DEPENDS ${syscalls_subdirs_trigger} ${PARSE_SYSCALLS_HEADER_DEPENDS}
cmake: Re-organize syscall generation wrt. the build system This commit fixes https://github.com/zephyrproject-rtos/zephyr/issues/5008. It does so by splitting up gen_syscalls.py into two scripts with a json metadata file to communicate syscall metadata between them. The parsing script parses header files from include/ and writes syscall metadata to a file if the contents changed. The generation script reads from the json file and generates syscall code. The build system DAG now looks like this: always_rebuild -> json -> syscalls -> offset.o The script for generating json will do so only if the content changes, this ensures that the entire DAG does not always do a full rebuild. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-11-20 13:03:55 +01:00
)
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
add_custom_target(${SYSCALL_LIST_H_TARGET} DEPENDS ${syscall_list_h})
cmake: Re-organize syscall generation wrt. the build system This commit fixes https://github.com/zephyrproject-rtos/zephyr/issues/5008. It does so by splitting up gen_syscalls.py into two scripts with a json metadata file to communicate syscall metadata between them. The parsing script parses header files from include/ and writes syscall metadata to a file if the contents changed. The generation script reads from the json file and generates syscall code. The build system DAG now looks like this: always_rebuild -> json -> syscalls -> offset.o The script for generating json will do so only if the content changes, this ensures that the entire DAG does not always do a full rebuild. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-11-20 13:03:55 +01:00
add_custom_command(OUTPUT include/generated/syscall_dispatch.c ${syscall_list_h}
# Also, some files are written to include/generated/syscalls/
COMMAND
${PYTHON_EXECUTABLE}
cmake: replace PROJECT_SOURCE_DIR with ZEPHYR_BASE Both variables were used (with the same value) interchangeably throughout CMake files and per the discussion in GH issue, ZEPHYR_BASE is preferred. Also add a comment with explanation of one vs. the other. Tested by building hello_world for several boards ensuring no errors. Fixes #7173. Signed-off-by: Alex Tereschenko <alext.mkrs@gmail.com>
2018-06-14 20:21:18 +02:00
${ZEPHYR_BASE}/scripts/gen_syscalls.py
cmake: Re-organize syscall generation wrt. the build system This commit fixes https://github.com/zephyrproject-rtos/zephyr/issues/5008. It does so by splitting up gen_syscalls.py into two scripts with a json metadata file to communicate syscall metadata between them. The parsing script parses header files from include/ and writes syscall metadata to a file if the contents changed. The generation script reads from the json file and generates syscall code. The build system DAG now looks like this: always_rebuild -> json -> syscalls -> offset.o The script for generating json will do so only if the content changes, this ensures that the entire DAG does not always do a full rebuild. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-11-20 13:03:55 +01:00
--json-file ${syscalls_json} # Read this file
--base-output include/generated/syscalls # Write to this dir
--syscall-dispatch include/generated/syscall_dispatch.c # Write this file
gen_syscalls.py: do not output data to stdout There's no particularly good reason to have one kind of output from this script to be sent to stdout instead of a filename specified by parameter, and it makes it annoying to add debug print() statements. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2018-07-24 03:10:15 +02:00
--syscall-list ${syscall_list_h}
cmake: Re-organize syscall generation wrt. the build system This commit fixes https://github.com/zephyrproject-rtos/zephyr/issues/5008. It does so by splitting up gen_syscalls.py into two scripts with a json metadata file to communicate syscall metadata between them. The parsing script parses header files from include/ and writes syscall metadata to a file if the contents changed. The generation script reads from the json file and generates syscall code. The build system DAG now looks like this: always_rebuild -> json -> syscalls -> offset.o The script for generating json will do so only if the content changes, this ensures that the entire DAG does not always do a full rebuild. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-11-20 13:03:55 +01:00
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
DEPENDS ${syscalls_json}
)
drivers: Perform a runtime check if a driver is capable of an operation Driver APIs might not implement all operations, making it possible for a user thread to get the kernel to execute a function at 0x00000000. Perform runtime checks in all the driver handlers, checking if they're capable of performing the requested operation. Fixes #6907. Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
2018-04-04 22:50:32 +02:00
set(DRV_VALIDATION ${PROJECT_BINARY_DIR}/include/generated/driver-validation.h)
add_custom_command(
OUTPUT ${DRV_VALIDATION}
COMMAND
${PYTHON_EXECUTABLE}
${ZEPHYR_BASE}/scripts/gen_kobject_list.py
--validation-output ${DRV_VALIDATION}
$<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--verbose>
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
add_custom_target(${DRIVER_VALIDATION_H_TARGET} DEPENDS ${DRV_VALIDATION})
drivers: Perform a runtime check if a driver is capable of an operation Driver APIs might not implement all operations, making it possible for a user thread to get the kernel to execute a function at 0x00000000. Perform runtime checks in all the driver handlers, checking if they're capable of performing the requested operation. Fixes #6907. Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
2018-04-04 22:50:32 +02:00
scripts: gen_kobject_list: Generate enums and case statements Adding a new kernel object type or driver subsystem requires changes in various different places. This patch makes it easier to create those devices by generating as much as possible in compile time. No behavior change. Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
2018-04-05 22:59:33 +02:00
include($ENV{ZEPHYR_BASE}/cmake/kobj.cmake)
gen_kobj(KOBJ_INCLUDE_PATH)
drivers: Perform a runtime check if a driver is capable of an operation Driver APIs might not implement all operations, making it possible for a user thread to get the kernel to execute a function at 0x00000000. Perform runtime checks in all the driver handlers, checking if they're capable of performing the requested operation. Fixes #6907. Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
2018-04-04 22:50:32 +02:00
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
# Generate offsets.c.obj from offsets.c
# Generate offsets.h from offsets.c.obj
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
set(OFFSETS_LIB offsets)
Revert "Build: Offsets lib as OBJECT not STATIC" This reverts commit 18f9bb04f71d0428b46573e7b8cc5d52c224e1d6. This breaks with cmake 3.8.2, the minimal required version we have in all of our cmake files. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2018-11-18 03:15:14 +01:00
set(OFFSETS_C_PATH ${ZEPHYR_BASE}/arch/${ARCH}/core/offsets/offsets.c)
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
set(OFFSETS_O_PATH ${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/${OFFSETS_LIB}.dir/arch/${ARCH}/core/offsets/offsets.c.obj)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
set(OFFSETS_H_PATH ${PROJECT_BINARY_DIR}/include/generated/offsets.h)
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
add_library( ${OFFSETS_LIB} STATIC ${OFFSETS_C_PATH})
target_link_libraries(${OFFSETS_LIB} zephyr_interface)
add_dependencies( ${OFFSETS_LIB}
${SYSCALL_LIST_H_TARGET}
${SYSCALL_MACROS_H_TARGET}
${DRIVER_VALIDATION_H_TARGET}
${KOBJ_TYPES_H_TARGET}
cmake: Re-organize syscall generation wrt. the build system This commit fixes https://github.com/zephyrproject-rtos/zephyr/issues/5008. It does so by splitting up gen_syscalls.py into two scripts with a json metadata file to communicate syscall metadata between them. The parsing script parses header files from include/ and writes syscall metadata to a file if the contents changed. The generation script reads from the json file and generates syscall code. The build system DAG now looks like this: always_rebuild -> json -> syscalls -> offset.o The script for generating json will do so only if the content changes, this ensures that the entire DAG does not always do a full rebuild. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-11-20 13:03:55 +01:00
)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
add_custom_command(
OUTPUT ${OFFSETS_H_PATH}
cmake: Use path-corrected version of ZEPHYR_BASE Instead of accessing the environment variable ZEPHYR_BASE every time we require accessing the source code root, use an intermediate variable that has OS path separators correctly set to '/' to avoid issues on Windows. Note: This removes the ZEPHYR_SOURCE_DIR CMake variable. External applications using that will need to change to use the new ZEPHYR_BASE variable. Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2018-01-11 15:46:44 +01:00
COMMAND ${PYTHON_EXECUTABLE} ${ZEPHYR_BASE}/scripts/gen_offset_header.py
Revert "Build: Offsets lib as OBJECT not STATIC" This reverts commit 18f9bb04f71d0428b46573e7b8cc5d52c224e1d6. This breaks with cmake 3.8.2, the minimal required version we have in all of our cmake files. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2018-11-18 03:15:14 +01:00
-i ${OFFSETS_O_PATH}
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
-o ${OFFSETS_H_PATH}
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
DEPENDS ${OFFSETS_LIB}
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
)
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
add_custom_target(${OFFSETS_H_TARGET} DEPENDS ${OFFSETS_H_PATH})
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
zephyr_include_directories(${TOOLCHAIN_INCLUDES})
cmake: Change the zephyr_get_* API to be LANG-aware When exporting flags to an external build system we need to deal with the fact that we sometimes use generator expressions. Specifically, we use generator expressions that look like this: $<$<COMPILE_LANGUAGE:CXX>:-fno-exceptions> This patch replaces the old API with a new one where users can ask for compile options for specific languages, like this: zephyr_get_compile_options_for_lang_as_string(CXX x) The existing API would have either crashed or silently omitted flags when a COMPILE_LANG generator expression was present. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-01 15:25:06 +01:00
zephyr_get_include_directories_for_lang(C ZEPHYR_INCLUDES)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
add_subdirectory(kernel)
# Read list content
get_property(ZEPHYR_LIBS_PROPERTY GLOBAL PROPERTY ZEPHYR_LIBS)
foreach(zephyr_lib ${ZEPHYR_LIBS_PROPERTY})
# TODO: Could this become an INTERFACE property of zephyr_interface?
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
add_dependencies(${zephyr_lib} ${OFFSETS_H_TARGET})
cmake: Fail with an error message when empty libraries exist A very annoying usability issue is that the error message is very cryptic when you create a zephyr library that doesn't have any source files. Creating such a library is very easy to do, so we should have a good error message for it. It was also considered to allow empty libraries to exist, but this was decided against as they show up in the build output and can confuse the end user. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-05 13:22:19 +01:00
cmake: Don't assert that imported zephyr libraries have source files A Zephyr library not having source files is usually due to a misconfiguration and will lead to an obscure error message. But imported Zephyr libraries don't have source files so we need to skip the source file when a library is imported. An imported Zephyr library is normally used to reference externally built code, either prebuilt or recursively built through an external build system. This fixes #5497 Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-01-09 12:45:19 +01:00
# Verify that all (non-imported) libraries have source
# files. Libraries without source files are not supported because
# they are an indication that something has been misconfigured.
get_target_property(lib_imported ${zephyr_lib} IMPORTED)
get_target_property(lib_sources ${zephyr_lib} SOURCES)
cmake: Fail with an error message when empty libraries exist A very annoying usability issue is that the error message is very cryptic when you create a zephyr library that doesn't have any source files. Creating such a library is very easy to do, so we should have a good error message for it. It was also considered to allow empty libraries to exist, but this was decided against as they show up in the build output and can confuse the end user. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-05 13:22:19 +01:00
if(lib_sources STREQUAL lib_sources-NOTFOUND
AND (NOT (${zephyr_lib} STREQUAL app))
cmake: Don't assert that imported zephyr libraries have source files A Zephyr library not having source files is usually due to a misconfiguration and will lead to an obscure error message. But imported Zephyr libraries don't have source files so we need to skip the source file when a library is imported. An imported Zephyr library is normally used to reference externally built code, either prebuilt or recursively built through an external build system. This fixes #5497 Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-01-09 12:45:19 +01:00
AND (NOT lib_imported)
cmake: Fail with an error message when empty libraries exist A very annoying usability issue is that the error message is very cryptic when you create a zephyr library that doesn't have any source files. Creating such a library is very easy to do, so we should have a good error message for it. It was also considered to allow empty libraries to exist, but this was decided against as they show up in the build output and can confuse the end user. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-05 13:22:19 +01:00
)
# app is not checked because it's sources are added to it after
# this CMakeLists.txt file has been processed
message(FATAL_ERROR "\
The Zephyr library '${zephyr_lib}' was created without source files. \
cmake: Don't assert that imported zephyr libraries have source files A Zephyr library not having source files is usually due to a misconfiguration and will lead to an obscure error message. But imported Zephyr libraries don't have source files so we need to skip the source file when a library is imported. An imported Zephyr library is normally used to reference externally built code, either prebuilt or recursively built through an external build system. This fixes #5497 Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-01-09 12:45:19 +01:00
Empty (non-imported) libraries are not supported. \
cmake: Fail with an error message when empty libraries exist A very annoying usability issue is that the error message is very cryptic when you create a zephyr library that doesn't have any source files. Creating such a library is very easy to do, so we should have a good error message for it. It was also considered to allow empty libraries to exist, but this was decided against as they show up in the build output and can confuse the end user. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-05 13:22:19 +01:00
Either make sure that the library has the sources it should have, \
or make sure it is not created when it has no source files.")
endif()
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
endforeach()
get_property(OUTPUT_FORMAT GLOBAL PROPERTY PROPERTY_OUTPUT_FORMAT)
if(CONFIG_APPLICATION_MEMORY)
# Objects default to being in kernel space, and then we exclude
# certain items.
set(kernel_object_file_list
${ZEPHYR_LIBS_PROPERTY}
kernel
)
list(
REMOVE_ITEM
kernel_object_file_list
app
)
# The zephyr libraries in zephyr/lib/ and zephyr/test/ belong in
# userspace.
# NB: The business logic for determing what source files are in
# kernel space and what source files are in user space is
# fragile. Fix ASAP.
#
# The intended design is that certain directories are designated as
# containing userspace code and others for kernel space code. The
# implementation we have however is not working on directories of
# code, it is working on zephyr libraries. It is exploiting the fact
# that zephyr libraries follow a naming scheme as described in
# extensions.cmake:zephyr_library_get_current_dir_lib_name
#
# But code from test/ and lib/ that is placed in the "zephyr"
# library (with zephyr_sources()) will not be in a library that is
# prefixed with lib__ or test__ and will end up in the wrong address
# space.
set(application_space_dirs
lib
tests
)
foreach(f ${kernel_object_file_list})
foreach(app_dir ${application_space_dirs})
if(${f} MATCHES "^${app_dir}__") # Begins with ${app_dir}__, e.g. lib__libc
list(
REMOVE_ITEM
kernel_object_file_list
${f}
)
endif()
endforeach()
endforeach()
# Create a list ks, with relative paths to kernel space libs.
foreach(f ${kernel_object_file_list})
get_target_property(target_name ${f} NAME)
get_target_property(target_binary_dir ${f} BINARY_DIR)
string(REPLACE
${PROJECT_BINARY_DIR}
""
fixed_path
${target_binary_dir}
)
# Append / if not empty
if(fixed_path)
set(fixed_path "${fixed_path}/")
endif()
# Cut off leading / if present
if(fixed_path MATCHES "^/.+")
string(SUBSTRING ${fixed_path} 1 -1 fixed_path)
endif()
cmake: ninja: Change how CMake names the kernelspace archives The linker script places kernelspace and userspace archives in different sections. But the linker script itself does not determine what archives are in what space, that is done by CMake. CMake passes the list of kernelspace archives to the linker script through defines, like this: -DNUM_KERNEL_OBJECT_FILES=3 -DKERNEL_OBJECT_FILE_0=path/to/archive_a.a -DKERNEL_OBJECT_FILE_1=path/to/archive_b.a -DKERNEL_OBJECT_FILE_2=path/to/archive_c.a These paths are relative, and since Ninja and Make invoke the linker with different "working directories"[0], the relative paths need to be different. This patch rectifies the relative path when using Ninja. This fixes #5343 [0] https://gitlab.kitware.com/cmake/cmake/issues/17448 Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-01-02 15:54:16 +01:00
set(fixed_path "${fixed_path}lib${target_name}.a")
if(CMAKE_GENERATOR STREQUAL "Ninja")
# Ninja invokes the linker from the root of the build directory
# (APPLICATION_BINARY_DIR) instead of from the build/zephyr
# directory (PROJECT_BINARY_DIR). So for linker-defs.h to get
# the correct path we need to prefix with zephyr/.
set(fixed_path "zephyr/${fixed_path}")
endif()
list(APPEND ks ${fixed_path})
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
endforeach()
linker: Re-implement {APP,KERNEL}_INPUT_SECTION This rewrites the implementation of the APP_INPUT_SECTION and KERNEL_INPUT_SECTION macros such that an unbounded amount of kernelspace libraries can be used. This resolves #7703 The new implementation has a caveat/limitation; the linker script developer must invoke APP_INPUT_SECTION before KERNEL_INPUT_SECTION. All in-tree linker scripts happened to already be doing this so no in-tree porting was necessary. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-08-03 16:15:05 +02:00
# We are done constructing kernel_object_file_list, now we inject
# this list into the linker script through the define
# KERNELSPACE_OBJECT_FILES
set(def -DKERNELSPACE_OBJECT_FILES=)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
foreach(f ${ks})
linker: Re-implement {APP,KERNEL}_INPUT_SECTION This rewrites the implementation of the APP_INPUT_SECTION and KERNEL_INPUT_SECTION macros such that an unbounded amount of kernelspace libraries can be used. This resolves #7703 The new implementation has a caveat/limitation; the linker script developer must invoke APP_INPUT_SECTION before KERNEL_INPUT_SECTION. All in-tree linker scripts happened to already be doing this so no in-tree porting was necessary. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-08-03 16:15:05 +02:00
set(def "${def} ${f}")
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
endforeach()
cmake: Move helper function up, inline variable. This is done to make future modifications simpler, as more variables and functions are available. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-11-29 10:15:33 +01:00
set_property(GLOBAL APPEND PROPERTY
cmake: Whitespace and commentary fixes Cosmetics, no functional change expected. Fixed leading space alignment. Replaced tabs with spaces. Emulation error message output is now aligned. To locate tabs in cmake, the following bash is useful: grep -PRil "\t" * | grep -i cmake | grep -v ^sanity Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2018-12-19 10:40:57 +01:00
PROPERTY_LINKER_SCRIPT_DEFINES
${def}
)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
endif() # CONFIG_APPLICATION_MEMORY
cmake: Added rule and helper functions for code relocation. This patch creates a rule in the cmake to trigger the generation of linker_relocate.ld and code_relocation.c files. The linker_relocate.ld will create appropriate sections and will link the required functions or variables from all the selected files. The code_relocation.c will have code that is needed for initializing data sections and copy of text sections(if XIP). Also this will contain code that is needed for zeroing of bss. The procedure to invoke this feature is: 1. Enable CONFIG_CODE_RELOCATION in the prj.conf 2. Inside CMakeList.txt in the project we need to mention all the files that needs to get relocated. zephyr_kernel_code_relocate(src/*.c SRAM2) Where the first argument is the file/files and the second argument is the memory where it has be placed. NOTE: The file argument supports glob expressions. NOTE: Step 2 can be done as many times as required. And relative paths can be given here. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-11-13 11:04:02 +01:00
if (CONFIG_CODE_DATA_RELOCATION)
set(CODE_RELOCATION_DEP code_relocation_source_lib)
endif() # CONFIG_CODE_DATA_RELOCATION
cmake: ld: Refactor the linker script's cpp command construction Construct the custom command for preprocessing the linker script with a function to avoid copy-paste errors between linker passes. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-31 10:39:23 +01:00
makefile: Convert linker function to use names This patch changes the way the custom linker function works. It uses names instead of numbers to denote the name of the file and applies the correct LINKER_PASS variable for the final linker pass. Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-01-25 18:07:03 +01:00
construct_add_custom_command_for_linker_pass(linker custom_command)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
add_custom_command(
cmake: ld: Refactor the linker script's cpp command construction Construct the custom command for preprocessing the linker script with a function to avoid copy-paste errors between linker passes. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-31 10:39:23 +01:00
${custom_command}
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
)
arm: Add app data section alignment constraints This patch adds application data section alignment constraints to match the region definition requirements for ARM MPUs. Most MPUs require a minimum of 32 bytes of alignment for any regions, but some require power of two alignment to the size of a region. This requires that the linker align the application data section to the size of the section. This requires a linker pass to determine the size. Once this is accomplished the correct value is added to a linker include file that is utilized in subsequent linker operations. Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:12:32 +01:00
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
add_custom_target(
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
${LINKER_SCRIPT_TARGET}
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
DEPENDS
arm: Generate privileged stacks This patch adds the generation and incorporation of privileged stack regions that are used by ARM user mode threads. This patch adds the infrastructure for privileged stacks. Later patches will utilize the generated stacks and helper functions. Signed-off-by: Chunlin Han <chunlin.han@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:19:49 +01:00
${ALIGN_SIZING_DEP} ${PRIV_STACK_DEP}
userspace: app_shared_mem: Fixed incorrect implementation. This feature was failing on a default ARM core MPU. The linker script that was getting created was not able to align the required partitions at prebuilt time. The old implementation relied on the prebuilt to finish then extract the size information which was then used to align the regions. This fails because the size of the alignment and the fill in the linker needs to be available at prebuilt time else it cant manage the final elf file generation. We cant have 2 different sizes of prebuilt and final elf file. This implementation will get the alignment requirements met at prebuilt time. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-08-04 16:18:52 +02:00
${APP_SMEM_DEP}
cmake: Added rule and helper functions for code relocation. This patch creates a rule in the cmake to trigger the generation of linker_relocate.ld and code_relocation.c files. The linker_relocate.ld will create appropriate sections and will link the required functions or variables from all the selected files. The code_relocation.c will have code that is needed for initializing data sections and copy of text sections(if XIP). Also this will contain code that is needed for zeroing of bss. The procedure to invoke this feature is: 1. Enable CONFIG_CODE_RELOCATION in the prj.conf 2. Inside CMakeList.txt in the project we need to mention all the files that needs to get relocated. zephyr_kernel_code_relocate(src/*.c SRAM2) Where the first argument is the file/files and the second argument is the memory where it has be placed. NOTE: The file argument supports glob expressions. NOTE: Step 2 can be done as many times as required. And relative paths can be given here. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-11-13 11:04:02 +01:00
${CODE_RELOCATION_DEP}
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
linker.cmd
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
${OFFSETS_H_TARGET}
cmake: ld: Ensure that a linker script change triggers a rebuild This fixes https://github.com/zephyrproject-rtos/zephyr/issues/5010. CMake has a simple parser that can parse C-like files to find header dependencies. But the parser needs to know what the include directories are to be able to follow #include pragmas. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-14 13:03:23 +01:00
)
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
# Give the '${LINKER_SCRIPT_TARGET}' target all of the include directories so
cmake: ld: Ensure that a linker script change triggers a rebuild This fixes https://github.com/zephyrproject-rtos/zephyr/issues/5010. CMake has a simple parser that can parse C-like files to find header dependencies. But the parser needs to know what the include directories are to be able to follow #include pragmas. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-14 13:03:23 +01:00
# that cmake can successfully find the linker_script's header
# dependencies.
zephyr_get_include_directories_for_lang(C
ZEPHYR_INCLUDE_DIRS
STRIP_PREFIX # Don't use a -I prefix
)
set_property(TARGET
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
${LINKER_SCRIPT_TARGET}
cmake: ld: Ensure that a linker script change triggers a rebuild This fixes https://github.com/zephyrproject-rtos/zephyr/issues/5010. CMake has a simple parser that can parse C-like files to find header dependencies. But the parser needs to know what the include directories are to be able to follow #include pragmas. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-14 13:03:23 +01:00
PROPERTY INCLUDE_DIRECTORIES
${ZEPHYR_INCLUDE_DIRS}
)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
set(zephyr_lnk
${LINKERFLAGPREFIX},-Map=${PROJECT_BINARY_DIR}/${KERNEL_MAP_NAME}
-u_OffsetAbsSyms
-u_ConfigAbsSyms
${LINKERFLAGPREFIX},--whole-archive
${ZEPHYR_LIBS_PROPERTY}
${LINKERFLAGPREFIX},--no-whole-archive
kernel
Revert "Build: Offsets lib as OBJECT not STATIC" This reverts commit 18f9bb04f71d0428b46573e7b8cc5d52c224e1d6. This breaks with cmake 3.8.2, the minimal required version we have in all of our cmake files. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2018-11-18 03:15:14 +01:00
${OFFSETS_O_PATH}
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
${LIB_INCLUDE_DIR}
-L${PROJECT_BINARY_DIR}
${TOOLCHAIN_LIBS}
)
if(CONFIG_GEN_ISR_TABLES)
xtensa: provide XCC compiler support for Xtensa This patchset provides Xtensa's xcc compiler support for Xtensa projects in Cmake. This requires the below environment variables to be defined aptly. The appropriate xcc license information also need to be supplied. ZEPHYR_GCC_VARIANT=xcc TOOLCHAIN_VER=RF-2015.3-linux XTENSA_CORE=cavs21_LX6HiFi3_RF3_WB16 XTENSA_SYSTEM=/opt/xtensa/XtDevTools/install/tools/ RF-2015.3-linux/XtensaTools/config/ XTENSA_BUILD_PATHS=/opt/xtensa/XtDevTools/install/builds/ Change-Id: Ib3c10e8095439b0e32276ff37c00eca8420773ec Signed-off-by: Rajavardhan Gundi <rajavardhan.gundi@intel.com> Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-12-12 18:59:37 +01:00
if(CONFIG_GEN_SW_ISR_TABLE)
list(APPEND GEN_ISR_TABLE_EXTRA_ARG --sw-isr-table)
endif()
if(CONFIG_GEN_IRQ_VECTOR_TABLE)
list(APPEND GEN_ISR_TABLE_EXTRA_ARG --vector-table)
endif()
cmake: Use a variable for 'zephyr_prebuilt' There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:31:02 +01:00
# isr_tables.c is generated from ${ZEPHYR_PREBUILT_EXECUTABLE} by
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
# gen_isr_tables.py
add_custom_command(
OUTPUT isr_tables.c
COMMAND ${CMAKE_OBJCOPY}
-I ${OUTPUT_FORMAT}
-O binary
--only-section=.intList
cmake: Use a variable for 'zephyr_prebuilt' There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:31:02 +01:00
$<TARGET_FILE:${ZEPHYR_PREBUILT_EXECUTABLE}>
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
isrList.bin
COMMAND ${PYTHON_EXECUTABLE}
cmake: Use path-corrected version of ZEPHYR_BASE Instead of accessing the environment variable ZEPHYR_BASE every time we require accessing the source code root, use an intermediate variable that has OS path separators correctly set to '/' to avoid issues on Windows. Note: This removes the ZEPHYR_SOURCE_DIR CMake variable. External applications using that will need to change to use the new ZEPHYR_BASE variable. Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2018-01-11 15:46:44 +01:00
${ZEPHYR_BASE}/arch/common/gen_isr_tables.py
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
--output-source isr_tables.c
cmake: Use a variable for 'zephyr_prebuilt' There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:31:02 +01:00
--kernel $<TARGET_FILE:${ZEPHYR_PREBUILT_EXECUTABLE}>
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
--intlist isrList.bin
arch: add big endian support This patch adds Big Endian architecture support. Even if a compiler generating big endian object files is used, our linker script, or include/linker/linker-tool-gcc.h to be precise, has default output format as little endian. This patch adds a hidden config CONFIG_BIG_ENDIAN, which should be set by big endian architectures or a SoC's, and adds an condition to switch OUTPUT_FORMAT in our linker.cmd. Signed-off-by: Yasushi SHOJI <y-shoji@ispace-inc.com>
2018-10-09 11:59:16 +02:00
$<$<BOOL:${CONFIG_BIG_ENDIAN}>:--big-endian>
cmake: gen_isr_tables: Reduce verbosity of non-verbose builds. gen_isr_tables.py's --debug flag causes it to spit out a verbose log. Normal builds don't need to see this information. This patch will remove this from the build log: gen_isr_tables.py: (4041, 4477, 46, 0, 7) gen_isr_tables.py: spurious handler: 0xfc9 gen_isr_tables.py: Configured interrupt routing gen_isr_tables.py: handler irq flags param gen_isr_tables.py: -------------------------- gen_isr_tables.py: 0x14bd 0 0 0x0 gen_isr_tables.py: 0x16a1 6 0 0x20002bac gen_isr_tables.py: 0x1975 17 0 0x0 gen_isr_tables.py: 0x7e5b 13 0 0x0 gen_isr_tables.py: 0x7e55 24 0 0x0 gen_isr_tables.py: 0x7e21 11 0 0x0 gen_isr_tables.py: 0x7e5f 1 1 0x0 Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-01-04 14:08:39 +01:00
$<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--debug>
xtensa: provide XCC compiler support for Xtensa This patchset provides Xtensa's xcc compiler support for Xtensa projects in Cmake. This requires the below environment variables to be defined aptly. The appropriate xcc license information also need to be supplied. ZEPHYR_GCC_VARIANT=xcc TOOLCHAIN_VER=RF-2015.3-linux XTENSA_CORE=cavs21_LX6HiFi3_RF3_WB16 XTENSA_SYSTEM=/opt/xtensa/XtDevTools/install/tools/ RF-2015.3-linux/XtensaTools/config/ XTENSA_BUILD_PATHS=/opt/xtensa/XtDevTools/install/builds/ Change-Id: Ib3c10e8095439b0e32276ff37c00eca8420773ec Signed-off-by: Rajavardhan Gundi <rajavardhan.gundi@intel.com> Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-12-12 18:59:37 +01:00
${GEN_ISR_TABLE_EXTRA_ARG}
cmake: Use a variable for 'zephyr_prebuilt' There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:31:02 +01:00
DEPENDS ${ZEPHYR_PREBUILT_EXECUTABLE}
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
)
set_property(GLOBAL APPEND PROPERTY GENERATED_KERNEL_SOURCE_FILES isr_tables.c)
endif()
cmake: Added rule and helper functions for code relocation. This patch creates a rule in the cmake to trigger the generation of linker_relocate.ld and code_relocation.c files. The linker_relocate.ld will create appropriate sections and will link the required functions or variables from all the selected files. The code_relocation.c will have code that is needed for initializing data sections and copy of text sections(if XIP). Also this will contain code that is needed for zeroing of bss. The procedure to invoke this feature is: 1. Enable CONFIG_CODE_RELOCATION in the prj.conf 2. Inside CMakeList.txt in the project we need to mention all the files that needs to get relocated. zephyr_kernel_code_relocate(src/*.c SRAM2) Where the first argument is the file/files and the second argument is the memory where it has be placed. NOTE: The file argument supports glob expressions. NOTE: Step 2 can be done as many times as required. And relative paths can be given here. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-11-13 11:04:02 +01:00
if(CONFIG_CODE_DATA_RELOCATION)
set(MEM_RELOCATAION_LD "${PROJECT_BINARY_DIR}/include/generated/linker_relocate.ld")
set(MEM_RELOCATAION_CODE "${PROJECT_BINARY_DIR}/code_relocation.c")
add_custom_command(
OUTPUT ${MEM_RELOCATAION_CODE} ${MEM_RELOCATAION_LD}
COMMAND
${PYTHON_EXECUTABLE}
${ZEPHYR_BASE}/scripts/gen_relocate_app.py
$<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--verbose>
-d ${APPLICATION_BINARY_DIR}
-i '$<TARGET_PROPERTY:code_data_relocation_target,COMPILE_DEFINITIONS>'
-o ${MEM_RELOCATAION_LD}
-c ${MEM_RELOCATAION_CODE}
DEPENDS app kernel ${ZEPHYR_LIBS_PROPERTY}
)
add_library(code_relocation_source_lib STATIC ${MEM_RELOCATAION_CODE})
target_link_libraries(code_relocation_source_lib zephyr_interface)
endif()
cmake: Generated files are excluded from coverage. When coverage option is enabled, all C files will have coverage option enabled. When we enable it for generated files it adds extra .bss info and other related information. Since the bss has now increased the perfect hash that was calculated by gperf is now incorrect. Which is a problem for userspace enabled systems. This patch will make sure that the generated C files will be compiled without the coverage flags. The remaining functionality remains unchanged. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-11-21 10:01:56 +01:00
if(CONFIG_USERSPACE)
zephyr_get_compile_options_for_lang_as_string(C compiler_flags_priv)
string(REPLACE "-ftest-coverage" "" NO_COVERAGE_FLAGS "${compiler_flags_priv}")
string(REPLACE "-fprofile-arcs" "" NO_COVERAGE_FLAGS "${NO_COVERAGE_FLAGS}")
get_property(include_dir_in_interface TARGET zephyr_interface
PROPERTY INTERFACE_INCLUDE_DIRECTORIES)
get_property(sys_include_dir_in_interface TARGET zephyr_interface
PROPERTY INTERFACE_SYSTEM_INCLUDE_DIRECTORIES)
get_property(compile_definitions_interface TARGET zephyr_interface
PROPERTY INTERFACE_COMPILE_DEFINITIONS)
set(complete_include_dirs ${include_dir_in_interface} ${sys_include_dir_in_interface})
endif()
arm: Generate privileged stacks This patch adds the generation and incorporation of privileged stack regions that are used by ARM user mode threads. This patch adds the infrastructure for privileged stacks. Later patches will utilize the generated stacks and helper functions. Signed-off-by: Chunlin Han <chunlin.han@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:19:49 +01:00
if(CONFIG_ARM AND CONFIG_USERSPACE)
set(GEN_PRIV_STACKS $ENV{ZEPHYR_BASE}/scripts/gen_priv_stacks.py)
set(PROCESS_PRIV_STACKS_GPERF $ENV{ZEPHYR_BASE}/scripts/process_gperf.py)
set(PRIV_STACKS priv_stacks_hash.gperf)
set(PRIV_STACKS_OUTPUT_SRC_PRE priv_stacks_hash_preprocessed.c)
set(PRIV_STACKS_OUTPUT_SRC priv_stacks_hash.c)
set(PRIV_STACKS_OUTPUT_OBJ priv_stacks_hash.c.obj)
set(PRIV_STACKS_OUTPUT_OBJ_RENAMED priv_stacks_hash_renamed.o)
# Essentially what we are doing here is extracting some information
# out of the nearly finished elf file, generating the source code
# for a hash table based on that information, and then compiling and
# linking the hash table back into a now even more nearly finished
# elf file.
# Use the script GEN_PRIV_STACKS to scan the kernel binary's
cmake: Use a variable for 'zephyr_prebuilt' There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:31:02 +01:00
# (${ZEPHYR_PREBUILT_EXECUTABLE}) DWARF information to produce a table of kernel
arm: Generate privileged stacks This patch adds the generation and incorporation of privileged stack regions that are used by ARM user mode threads. This patch adds the infrastructure for privileged stacks. Later patches will utilize the generated stacks and helper functions. Signed-off-by: Chunlin Han <chunlin.han@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:19:49 +01:00
# objects (PRIV_STACKS) which we will then pass to gperf
add_custom_command(
OUTPUT ${PRIV_STACKS}
COMMAND
${PYTHON_EXECUTABLE}
${GEN_PRIV_STACKS}
--kernel $<TARGET_FILE:priv_stacks_prebuilt>
--output ${PRIV_STACKS}
$<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--verbose>
DEPENDS priv_stacks_prebuilt
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
add_custom_target(priv_stacks DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/${PRIV_STACKS})
# Use gperf to generate C code (PRIV_STACKS_OUTPUT_SRC_PRE) which implements a
# perfect hashtable based on PRIV_STACKS
add_custom_command(
OUTPUT ${PRIV_STACKS_OUTPUT_SRC_PRE}
COMMAND
${GPERF} -C
--output-file ${PRIV_STACKS_OUTPUT_SRC_PRE}
${PRIV_STACKS}
makefile: Fix dependencies for privileged stacks This patch fixes the dependency chain for priviliged stack generation. This fixes a problem when compiling after making significant changes that would shift the privileged stack area. Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-05-01 08:10:26 +02:00
DEPENDS priv_stacks ${PRIV_STACKS}
arm: Generate privileged stacks This patch adds the generation and incorporation of privileged stack regions that are used by ARM user mode threads. This patch adds the infrastructure for privileged stacks. Later patches will utilize the generated stacks and helper functions. Signed-off-by: Chunlin Han <chunlin.han@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:19:49 +01:00
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
add_custom_target(priv_stacks_output_src_pre DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/${PRIV_STACKS_OUTPUT_SRC_PRE})
# For our purposes the code/data generated by gperf is not optimal.
#
# The script PROCESS_GPERF creates a new c file OUTPUT_SRC based on
# OUTPUT_SRC_PRE to greatly reduce the amount of code/data generated
# since we know we are always working with pointer values
add_custom_command(
OUTPUT ${PRIV_STACKS_OUTPUT_SRC}
COMMAND
cmake: Invoke 'python' instead of py scripts directly Python scripts should be executed indirectly by the python interpreter, not directly in a CMake COMMAND. This is for portability reasons. Directly executing a python script depends on non-portable shebang logic and/or "default application" behaviour. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-06-21 14:34:42 +02:00
${PYTHON_EXECUTABLE}
arm: Generate privileged stacks This patch adds the generation and incorporation of privileged stack regions that are used by ARM user mode threads. This patch adds the infrastructure for privileged stacks. Later patches will utilize the generated stacks and helper functions. Signed-off-by: Chunlin Han <chunlin.han@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:19:49 +01:00
${PROCESS_PRIV_STACKS_GPERF}
-i ${PRIV_STACKS_OUTPUT_SRC_PRE}
-o ${PRIV_STACKS_OUTPUT_SRC}
-p "struct _k_priv_stack_map"
$<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--verbose>
makefile: Fix dependencies for privileged stacks This patch fixes the dependency chain for priviliged stack generation. This fixes a problem when compiling after making significant changes that would shift the privileged stack area. Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-05-01 08:10:26 +02:00
DEPENDS priv_stacks_output_src_pre ${PRIV_STACKS_OUTPUT_SRC_PRE}
arm: Generate privileged stacks This patch adds the generation and incorporation of privileged stack regions that are used by ARM user mode threads. This patch adds the infrastructure for privileged stacks. Later patches will utilize the generated stacks and helper functions. Signed-off-by: Chunlin Han <chunlin.han@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:19:49 +01:00
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
add_custom_target(priv_stacks_output_src DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/${PRIV_STACKS_OUTPUT_SRC})
cmake: Generated files are excluded from coverage. When coverage option is enabled, all C files will have coverage option enabled. When we enable it for generated files it adds extra .bss info and other related information. Since the bss has now increased the perfect hash that was calculated by gperf is now incorrect. Which is a problem for userspace enabled systems. This patch will make sure that the generated C files will be compiled without the coverage flags. The remaining functionality remains unchanged. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-11-21 10:01:56 +01:00
set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/${PRIV_STACKS_OUTPUT_SRC}
PROPERTIES COMPILE_DEFINITIONS "${compile_definitions_interface}")
set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/${PRIV_STACKS_OUTPUT_SRC}
PROPERTIES COMPILE_FLAGS
"${NO_COVERAGE_FLAGS} -fno-function-sections -fno-data-sections ")
arm: Generate privileged stacks This patch adds the generation and incorporation of privileged stack regions that are used by ARM user mode threads. This patch adds the infrastructure for privileged stacks. Later patches will utilize the generated stacks and helper functions. Signed-off-by: Chunlin Han <chunlin.han@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:19:49 +01:00
# We need precise control of where generated text/data ends up in the final
# kernel image. Disable function/data sections and use objcopy to move
# generated data into special section names
add_library(priv_stacks_output_lib STATIC
${CMAKE_CURRENT_BINARY_DIR}/${PRIV_STACKS_OUTPUT_SRC}
)
# Turn off -ffunction-sections, etc.
# NB: Using a library instead of target_compile_options(priv_stacks_output_lib
# [...]) because a library's options have precedence
add_library(priv_stacks_output_lib_interface INTERFACE)
cmake: Generated files are excluded from coverage. When coverage option is enabled, all C files will have coverage option enabled. When we enable it for generated files it adds extra .bss info and other related information. Since the bss has now increased the perfect hash that was calculated by gperf is now incorrect. Which is a problem for userspace enabled systems. This patch will make sure that the generated C files will be compiled without the coverage flags. The remaining functionality remains unchanged. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-11-21 10:01:56 +01:00
foreach(incl ${complete_include_dirs})
target_include_directories(priv_stacks_output_lib_interface INTERFACE ${incl})
endforeach()
arm: Generate privileged stacks This patch adds the generation and incorporation of privileged stack regions that are used by ARM user mode threads. This patch adds the infrastructure for privileged stacks. Later patches will utilize the generated stacks and helper functions. Signed-off-by: Chunlin Han <chunlin.han@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:19:49 +01:00
target_link_libraries(priv_stacks_output_lib priv_stacks_output_lib_interface)
set(PRIV_STACKS_OUTPUT_OBJ_PATH ${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/priv_stacks_output_lib.dir/${PRIV_STACKS_OUTPUT_OBJ})
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${PRIV_STACKS_OUTPUT_OBJ_RENAMED}
COMMAND
${CMAKE_OBJCOPY}
--rename-section .bss=.priv_stacks.noinit
--rename-section .data=.priv_stacks.data
--rename-section .text=.priv_stacks.text
--rename-section .rodata=.priv_stacks.rodata
${PRIV_STACKS_OUTPUT_OBJ_PATH}
${PRIV_STACKS_OUTPUT_OBJ_RENAMED}
DEPENDS priv_stacks_output_lib
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
add_custom_target(priv_stacks_output_obj_renamed DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/${PRIV_STACKS_OUTPUT_OBJ_RENAMED})
add_library(priv_stacks_output_obj_renamed_lib STATIC IMPORTED GLOBAL)
set_property(
TARGET priv_stacks_output_obj_renamed_lib
PROPERTY
IMPORTED_LOCATION ${CMAKE_CURRENT_BINARY_DIR}/${PRIV_STACKS_OUTPUT_OBJ_RENAMED}
)
add_dependencies(
priv_stacks_output_obj_renamed_lib
priv_stacks_output_obj_renamed
)
set_property(GLOBAL APPEND PROPERTY GENERATED_KERNEL_OBJECT_FILES priv_stacks_output_obj_renamed_lib)
endif()
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
if(CONFIG_USERSPACE)
cmake: Use path-corrected version of ZEPHYR_BASE Instead of accessing the environment variable ZEPHYR_BASE every time we require accessing the source code root, use an intermediate variable that has OS path separators correctly set to '/' to avoid issues on Windows. Note: This removes the ZEPHYR_SOURCE_DIR CMake variable. External applications using that will need to change to use the new ZEPHYR_BASE variable. Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2018-01-11 15:46:44 +01:00
set(GEN_KOBJ_LIST ${ZEPHYR_BASE}/scripts/gen_kobject_list.py)
set(PROCESS_GPERF ${ZEPHYR_BASE}/scripts/process_gperf.py)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
set(OBJ_LIST kobject_hash.gperf)
set(OUTPUT_SRC_PRE kobject_hash_preprocessed.c)
set(OUTPUT_SRC kobject_hash.c)
set(OUTPUT_OBJ kobject_hash.c.obj)
set(OUTPUT_OBJ_RENAMED kobject_hash_renamed.o)
# Essentially what we are doing here is extracting some information
# out of the nearly finished elf file, generating the source code
# for a hash table based on that information, and then compiling and
# linking the hash table back into a now even more nearly finished
# elf file.
# Use the script GEN_KOBJ_LIST to scan the kernel binary's
cmake: Use a variable for 'zephyr_prebuilt' There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:31:02 +01:00
# (${ZEPHYR_PREBUILT_EXECUTABLE}) DWARF information to produce a table of kernel
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
# objects (OBJ_LIST) which we will then pass to gperf
add_custom_command(
OUTPUT ${OBJ_LIST}
COMMAND
${PYTHON_EXECUTABLE}
${GEN_KOBJ_LIST}
cmake: Use a variable for 'zephyr_prebuilt' There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:31:02 +01:00
--kernel $<TARGET_FILE:${ZEPHYR_PREBUILT_EXECUTABLE}>
drivers: Perform a runtime check if a driver is capable of an operation Driver APIs might not implement all operations, making it possible for a user thread to get the kernel to execute a function at 0x00000000. Perform runtime checks in all the driver handlers, checking if they're capable of performing the requested operation. Fixes #6907. Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
2018-04-04 22:50:32 +02:00
--gperf-output ${OBJ_LIST}
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
$<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--verbose>
cmake: Use a variable for 'zephyr_prebuilt' There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:31:02 +01:00
DEPENDS ${ZEPHYR_PREBUILT_EXECUTABLE}
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
add_custom_target(obj_list DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/${OBJ_LIST})
# Use gperf to generate C code (OUTPUT_SRC_PRE) which implements a
# perfect hashtable based on OBJ_LIST
add_custom_command(
OUTPUT ${OUTPUT_SRC_PRE}
COMMAND
${GPERF}
--output-file ${OUTPUT_SRC_PRE}
${OBJ_LIST}
cmake: Fix dependencies between kobject_hash files CMake's custom_command support is not great. It is technically supported, but it is not easy to get it right. As explained in "5. File-level dependencies of custom targets are not propagated" from http://bit.ly/2GvwwEy. When a custom_command uses a custom_target as input, the custom_command must DEPEND on both the custom_target and the underlying file. Longterm we need to do something more sofisticated to prevent these issues from popping up. Like add some static analysis to detect badly written CMake code or introduce an abstraction for custom commands that is not affect by this issue. This fixes #5881 Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-01-31 10:42:46 +01:00
DEPENDS obj_list ${OBJ_LIST}
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
add_custom_target(output_src_pre DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/${OUTPUT_SRC_PRE})
# For our purposes the code/data generated by gperf is not optimal.
#
# The script PROCESS_GPERF creates a new c file OUTPUT_SRC based on
# OUTPUT_SRC_PRE to greatly reduce the amount of code/data generated
# since we know we are always working with pointer values
add_custom_command(
OUTPUT ${OUTPUT_SRC}
COMMAND
cmake: Invoke 'python' instead of py scripts directly Python scripts should be executed indirectly by the python interpreter, not directly in a CMake COMMAND. This is for portability reasons. Directly executing a python script depends on non-portable shebang logic and/or "default application" behaviour. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-06-21 14:34:42 +02:00
${PYTHON_EXECUTABLE}
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
${PROCESS_GPERF}
-i ${OUTPUT_SRC_PRE}
-o ${OUTPUT_SRC}
arm: Generate privileged stacks This patch adds the generation and incorporation of privileged stack regions that are used by ARM user mode threads. This patch adds the infrastructure for privileged stacks. Later patches will utilize the generated stacks and helper functions. Signed-off-by: Chunlin Han <chunlin.han@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:19:49 +01:00
-p "struct _k_object"
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
$<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--verbose>
cmake: Fix dependencies between kobject_hash files CMake's custom_command support is not great. It is technically supported, but it is not easy to get it right. As explained in "5. File-level dependencies of custom targets are not propagated" from http://bit.ly/2GvwwEy. When a custom_command uses a custom_target as input, the custom_command must DEPEND on both the custom_target and the underlying file. Longterm we need to do something more sofisticated to prevent these issues from popping up. Like add some static analysis to detect badly written CMake code or introduce an abstraction for custom commands that is not affect by this issue. This fixes #5881 Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-01-31 10:42:46 +01:00
DEPENDS output_src_pre ${OUTPUT_SRC_PRE}
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
add_custom_target(output_src DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/${OUTPUT_SRC})
# We need precise control of where generated text/data ends up in the final
# kernel image. Disable function/data sections and use objcopy to move
# generated data into special section names
add_library(output_lib STATIC
${CMAKE_CURRENT_BINARY_DIR}/${OUTPUT_SRC}
)
cmake: kobject: Fixed kobject text area overflow for optimization 0 We need to allocate extra memory region for the hash function that the gperf generates. The linker will need to maintain the same location counter between multiple linker stages. Reserving memory will help in maintaing correct location counters between multiple stages. The required memory varies with optimization level. In order to keep the size of the compiled object consistent, the kobject_hash.c is always compiled with -Os. fixes #5226 Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-01-29 11:28:51 +01:00
# always compile kobject_hash.c at optimization -Os
cmake: Generated files are excluded from coverage. When coverage option is enabled, all C files will have coverage option enabled. When we enable it for generated files it adds extra .bss info and other related information. Since the bss has now increased the perfect hash that was calculated by gperf is now incorrect. Which is a problem for userspace enabled systems. This patch will make sure that the generated C files will be compiled without the coverage flags. The remaining functionality remains unchanged. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-11-21 10:01:56 +01:00
set_source_files_properties(${OUTPUT_SRC} PROPERTIES COMPILE_FLAGS
"${NO_COVERAGE_FLAGS} -Os -fno-function-sections -fno-data-sections")
set_source_files_properties(${OUTPUT_SRC}
PROPERTIES COMPILE_DEFINITIONS "${compile_definitions_interface}")
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
# Turn off -ffunction-sections, etc.
# NB: Using a library instead of target_compile_options(output_lib
# [...]) because a library's options have precedence
add_library(output_lib_interface INTERFACE)
cmake: Generated files are excluded from coverage. When coverage option is enabled, all C files will have coverage option enabled. When we enable it for generated files it adds extra .bss info and other related information. Since the bss has now increased the perfect hash that was calculated by gperf is now incorrect. Which is a problem for userspace enabled systems. This patch will make sure that the generated C files will be compiled without the coverage flags. The remaining functionality remains unchanged. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-11-21 10:01:56 +01:00
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
target_link_libraries(output_lib output_lib_interface)
cmake: Generated files are excluded from coverage. When coverage option is enabled, all C files will have coverage option enabled. When we enable it for generated files it adds extra .bss info and other related information. Since the bss has now increased the perfect hash that was calculated by gperf is now incorrect. Which is a problem for userspace enabled systems. This patch will make sure that the generated C files will be compiled without the coverage flags. The remaining functionality remains unchanged. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-11-21 10:01:56 +01:00
foreach(incl ${complete_include_dirs})
target_include_directories(output_lib_interface INTERFACE ${incl})
endforeach()
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
set(OUTPUT_OBJ_PATH ${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/output_lib.dir/${OUTPUT_OBJ})
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${OUTPUT_OBJ_RENAMED}
COMMAND
${CMAKE_OBJCOPY}
--rename-section .data=.kobject_data.data
--rename-section .text=.kobject_data.text
--rename-section .rodata=.kobject_data.rodata
${OUTPUT_OBJ_PATH}
${OUTPUT_OBJ_RENAMED}
DEPENDS output_lib
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
add_custom_target(output_obj_renamed DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/${OUTPUT_OBJ_RENAMED})
add_library(output_obj_renamed_lib STATIC IMPORTED GLOBAL)
set_property(
TARGET output_obj_renamed_lib
PROPERTY
IMPORTED_LOCATION ${CMAKE_CURRENT_BINARY_DIR}/${OUTPUT_OBJ_RENAMED}
)
add_dependencies(
output_obj_renamed_lib
output_obj_renamed
)
set_property(GLOBAL APPEND PROPERTY GENERATED_KERNEL_OBJECT_FILES output_obj_renamed_lib)
endif()
# Read global variables into local variables
get_property(GKOF GLOBAL PROPERTY GENERATED_KERNEL_OBJECT_FILES)
get_property(GKSF GLOBAL PROPERTY GENERATED_KERNEL_SOURCE_FILES)
arch: native: Run Zephyr natively in a POSIX OS A new arch (posix) which relies on pthreads to emulate the context switching A new soc for it (inf_clock) which emulates a CPU running at an infinely high clock (so when the CPU is awaken it runs till completion in 0 time) A new board, which provides a trivial system tick timer and irq generation. Origin: Original Fixes #1891 Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com> Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-10-03 16:31:55 +02:00
cmake: Allow C standard version to be overriden Allow archs/boards/apps to override the C standard version. Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
2018-07-05 10:51:03 +02:00
get_property(CSTD GLOBAL PROPERTY CSTD)
set_ifndef(CSTD c99)
zephyr_compile_options(
$<$<COMPILE_LANGUAGE:C>:-std=${CSTD}>
)
arm: Add app data section alignment constraints This patch adds application data section alignment constraints to match the region definition requirements for ARM MPUs. Most MPUs require a minimum of 32 bytes of alignment for any regions, but some require power of two alignment to the size of a region. This requires that the linker align the application data section to the size of the section. This requires a linker pass to determine the size. Once this is accomplished the correct value is added to a linker include file that is utilized in subsequent linker operations. Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:12:32 +01:00
configure_file(
cmake: move app_data_alignment.ld under ARC sub-directory This commit moves the app_data_alignment.ld scripts under arch/arc sub-directory, as it is not not used at all in ARM builds. The script is still used for ARC, whose v2 MPU also has the reuquirement for power-of-two size alignment. Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
2018-11-29 14:26:01 +01:00
$ENV{ZEPHYR_BASE}/include/arch/arc/v2/app_data_alignment.ld
arm: Add app data section alignment constraints This patch adds application data section alignment constraints to match the region definition requirements for ARM MPUs. Most MPUs require a minimum of 32 bytes of alignment for any regions, but some require power of two alignment to the size of a region. This requires that the linker align the application data section to the size of the section. This requires a linker pass to determine the size. Once this is accomplished the correct value is added to a linker include file that is utilized in subsequent linker operations. Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:12:32 +01:00
${PROJECT_BINARY_DIR}/include/generated/app_data_alignment.ld)
userspace: compartmentalized app memory organization Summary: revised attempt at addressing issue 6290. The following provides an alternative to using CONFIG_APPLICATION_MEMORY by compartmentalizing data into Memory Domains. Dependent on MPU limitations, supports compartmentalized Memory Domains for 1...N logical applications. This is considered an initial attempt at designing flexible compartmentalized Memory Domains for multiple logical applications and, with the provided python script and edited CMakeLists.txt, provides support for power of 2 aligned MPU architectures. Overview: The current patch uses qualifiers to group data into subsections. The qualifier usage allows for dynamic subsection creation and affords the developer a large amount of flexibility in the grouping, naming, and size of the resulting partitions and domains that are built on these subsections. By additional macro calls, functions are created that help calculate the size, address, and permissions for the subsections and enable the developer to control application data in specified partitions and memory domains. Background: Initial attempts focused on creating a single section in the linker script that then contained internally grouped variables/data to allow MPU/MMU alignment and protection. This did not provide additional functionality beyond CONFIG_APPLICATION_MEMORY as we were unable to reliably group data or determine their grouping via exported linker symbols. Thus, the resulting decision was made to dynamically create subsections using the current qualifier method. An attempt to group the data by object file was tested, but found that this broke applications such as ztest where two object files are created: ztest and main. This also creates an issue of grouping the two object files together in the same memory domain while also allowing for compartmenting other data among threads. Because it is not possible to know a) the name of the partition and thus the symbol in the linker, b) the size of all the data in the subsection, nor c) the overall number of partitions created by the developer, it was not feasible to align the subsections at compile time without using dynamically generated linker script for MPU architectures requiring power of 2 alignment. In order to provide support for MPU architectures that require a power of 2 alignment, a python script is run at build prior to when linker_priv_stacks.cmd is generated. This script scans the built object files for all possible partitions and the names given to them. It then generates a linker file (app_smem.ld) that is included in the main linker.ld file. This app_smem.ld allows the compiler and linker to then create each subsection and align to the next power of 2. Usage: - Requires: app_memory/app_memdomain.h . - _app_dmem(id) marks a variable to be placed into a data section for memory partition id. - _app_bmem(id) marks a variable to be placed into a bss section for memory partition id. - These are seen in the linker.map as "data_smem_id" and "data_smem_idb". - To create a k_mem_partition, call the macro app_mem_partition(part0) where "part0" is the name then used to refer to that partition. This macro only creates a function and necessary data structures for the later "initialization". - To create a memory domain for the partition, the macro app_mem_domain(dom0) is called where "dom0" is the name then used for the memory domain. - To initialize the partition (effectively adding the partition to a linked list), init_part_part0() is called. This is followed by init_app_memory(), which walks all partitions in the linked list and calculates the sizes for each partition. - Once the partition is initialized, the domain can be initialized with init_domain_dom0(part0) which initializes the domain with partition part0. - After the domain has been initialized, the current thread can be added using add_thread_dom0(k_current_get()). - The code used in ztests ans kernel/init has been added under a conditional #ifdef to isolate the code from other tests. The userspace test CMakeLists.txt file has commands to insert the CONFIG_APP_SHARED_MEM definition into the required build targets. Example: /* create partition at top of file outside functions */ app_mem_partition(part0); /* create domain */ app_mem_domain(dom0); _app_dmem(dom0) int var1; _app_bmem(dom0) static volatile int var2; int main() { init_part_part0(); init_app_memory(); init_domain_dom0(part0); add_thread_dom0(k_current_get()); ... } - If multiple partitions are being created, a variadic preprocessor macro can be used as provided in app_macro_support.h: FOR_EACH(app_mem_partition, part0, part1, part2); or, for multiple domains, similarly: FOR_EACH(app_mem_domain, dom0, dom1); Similarly, the init_part_* can also be used in the macro: FOR_EACH(init_part, part0, part1, part2); Testing: - This has been successfully tested on qemu_x86 and the ARM frdm_k64f board. It compiles and builds power of 2 aligned subsections for the linker script on the 96b_carbon boards. These power of 2 alignments have been checked by hand and are viewable in the zephyr.map file that is produced during build. However, due to a shortage of available MPU regions on the 96b_carbon board, we are unable to test this. - When run on the 96b_carbon board, the test suite will enter execution, but each individaul test will fail due to an MPU FAULT. This is expected as the required number of MPU regions exceeds the number allowed due to the static allocation. As the MPU driver does not detect this issue, the fault occurs because the data being accessed has been placed outside the active MPU region. - This now compiles successfully for the ARC boards em_starterkit_em7d and em_starterkit_em7d_v22. However, as we lack ARC hardware to run this build on, we are unable to test this build. Current known issues: 1) While the script and edited CMakeLists.txt creates the ability to align to the next power of 2, this does not address the shortage of available MPU regions on certain devices (e.g. 96b_carbon). In testing the APB and PPB regions were commented out. 2) checkpatch.pl lists several issues regarding the following: a) Complex macros. The FOR_EACH macros as defined in app_macro_support.h are listed as complex macros needing parentheses. Adding parentheses breaks their functionality, and we have otherwise been unable to resolve the reported error. b) __aligned() preferred. The _app_dmem_pad() and _app_bmem_pad() macros give warnings that __aligned() is preferred. Prior iterations had this implementation, which resulted in errors due to "complex macros". c) Trailing semicolon. The macro init_part(name) has a trailing semicolon as the semicolon is needed for the inlined macro call that is generated when this macro expands. Update: updated to alternative CONFIG_APPLCATION_MEMORY. Added config option CONFIG_APP_SHARED_MEM to enable a new section app_smem to contain the shared memory component. This commit seperates the Kconfig definition from the definition used for the conditional code. The change is in response to changes in the way the build system treats definitions. The python script used to generate a linker script for app_smem was also midified to simplify the alignment directives. A default linker script app_smem.ld was added to remove the conditional includes dependency on CONFIG_APP_SHARED_MEM. By addining the default linker script the prebuild stages link properly prior to the python script running Signed-off-by: Joshua Domagalski <jedomag@tycho.nsa.gov> Signed-off-by: Shawn Mosley <smmosle@tycho.nsa.gov>
2018-04-26 16:14:02 +02:00
configure_file(
$ENV{ZEPHYR_BASE}/include/arch/arm/cortex_m/scripts/app_smem.ld
${PROJECT_BINARY_DIR}/include/generated/app_smem.ld)
arm: Add app data section alignment constraints This patch adds application data section alignment constraints to match the region definition requirements for ARM MPUs. Most MPUs require a minimum of 32 bytes of alignment for any regions, but some require power of two alignment to the size of a region. This requires that the linker align the application data section to the size of the section. This requires a linker pass to determine the size. Once this is accomplished the correct value is added to a linker include file that is utilized in subsequent linker operations. Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:12:32 +01:00
if(CONFIG_CPU_HAS_MPU AND CONFIG_USERSPACE)
userspace: compartmentalized app memory organization Summary: revised attempt at addressing issue 6290. The following provides an alternative to using CONFIG_APPLICATION_MEMORY by compartmentalizing data into Memory Domains. Dependent on MPU limitations, supports compartmentalized Memory Domains for 1...N logical applications. This is considered an initial attempt at designing flexible compartmentalized Memory Domains for multiple logical applications and, with the provided python script and edited CMakeLists.txt, provides support for power of 2 aligned MPU architectures. Overview: The current patch uses qualifiers to group data into subsections. The qualifier usage allows for dynamic subsection creation and affords the developer a large amount of flexibility in the grouping, naming, and size of the resulting partitions and domains that are built on these subsections. By additional macro calls, functions are created that help calculate the size, address, and permissions for the subsections and enable the developer to control application data in specified partitions and memory domains. Background: Initial attempts focused on creating a single section in the linker script that then contained internally grouped variables/data to allow MPU/MMU alignment and protection. This did not provide additional functionality beyond CONFIG_APPLICATION_MEMORY as we were unable to reliably group data or determine their grouping via exported linker symbols. Thus, the resulting decision was made to dynamically create subsections using the current qualifier method. An attempt to group the data by object file was tested, but found that this broke applications such as ztest where two object files are created: ztest and main. This also creates an issue of grouping the two object files together in the same memory domain while also allowing for compartmenting other data among threads. Because it is not possible to know a) the name of the partition and thus the symbol in the linker, b) the size of all the data in the subsection, nor c) the overall number of partitions created by the developer, it was not feasible to align the subsections at compile time without using dynamically generated linker script for MPU architectures requiring power of 2 alignment. In order to provide support for MPU architectures that require a power of 2 alignment, a python script is run at build prior to when linker_priv_stacks.cmd is generated. This script scans the built object files for all possible partitions and the names given to them. It then generates a linker file (app_smem.ld) that is included in the main linker.ld file. This app_smem.ld allows the compiler and linker to then create each subsection and align to the next power of 2. Usage: - Requires: app_memory/app_memdomain.h . - _app_dmem(id) marks a variable to be placed into a data section for memory partition id. - _app_bmem(id) marks a variable to be placed into a bss section for memory partition id. - These are seen in the linker.map as "data_smem_id" and "data_smem_idb". - To create a k_mem_partition, call the macro app_mem_partition(part0) where "part0" is the name then used to refer to that partition. This macro only creates a function and necessary data structures for the later "initialization". - To create a memory domain for the partition, the macro app_mem_domain(dom0) is called where "dom0" is the name then used for the memory domain. - To initialize the partition (effectively adding the partition to a linked list), init_part_part0() is called. This is followed by init_app_memory(), which walks all partitions in the linked list and calculates the sizes for each partition. - Once the partition is initialized, the domain can be initialized with init_domain_dom0(part0) which initializes the domain with partition part0. - After the domain has been initialized, the current thread can be added using add_thread_dom0(k_current_get()). - The code used in ztests ans kernel/init has been added under a conditional #ifdef to isolate the code from other tests. The userspace test CMakeLists.txt file has commands to insert the CONFIG_APP_SHARED_MEM definition into the required build targets. Example: /* create partition at top of file outside functions */ app_mem_partition(part0); /* create domain */ app_mem_domain(dom0); _app_dmem(dom0) int var1; _app_bmem(dom0) static volatile int var2; int main() { init_part_part0(); init_app_memory(); init_domain_dom0(part0); add_thread_dom0(k_current_get()); ... } - If multiple partitions are being created, a variadic preprocessor macro can be used as provided in app_macro_support.h: FOR_EACH(app_mem_partition, part0, part1, part2); or, for multiple domains, similarly: FOR_EACH(app_mem_domain, dom0, dom1); Similarly, the init_part_* can also be used in the macro: FOR_EACH(init_part, part0, part1, part2); Testing: - This has been successfully tested on qemu_x86 and the ARM frdm_k64f board. It compiles and builds power of 2 aligned subsections for the linker script on the 96b_carbon boards. These power of 2 alignments have been checked by hand and are viewable in the zephyr.map file that is produced during build. However, due to a shortage of available MPU regions on the 96b_carbon board, we are unable to test this. - When run on the 96b_carbon board, the test suite will enter execution, but each individaul test will fail due to an MPU FAULT. This is expected as the required number of MPU regions exceeds the number allowed due to the static allocation. As the MPU driver does not detect this issue, the fault occurs because the data being accessed has been placed outside the active MPU region. - This now compiles successfully for the ARC boards em_starterkit_em7d and em_starterkit_em7d_v22. However, as we lack ARC hardware to run this build on, we are unable to test this build. Current known issues: 1) While the script and edited CMakeLists.txt creates the ability to align to the next power of 2, this does not address the shortage of available MPU regions on certain devices (e.g. 96b_carbon). In testing the APB and PPB regions were commented out. 2) checkpatch.pl lists several issues regarding the following: a) Complex macros. The FOR_EACH macros as defined in app_macro_support.h are listed as complex macros needing parentheses. Adding parentheses breaks their functionality, and we have otherwise been unable to resolve the reported error. b) __aligned() preferred. The _app_dmem_pad() and _app_bmem_pad() macros give warnings that __aligned() is preferred. Prior iterations had this implementation, which resulted in errors due to "complex macros". c) Trailing semicolon. The macro init_part(name) has a trailing semicolon as the semicolon is needed for the inlined macro call that is generated when this macro expands. Update: updated to alternative CONFIG_APPLCATION_MEMORY. Added config option CONFIG_APP_SHARED_MEM to enable a new section app_smem to contain the shared memory component. This commit seperates the Kconfig definition from the definition used for the conditional code. The change is in response to changes in the way the build system treats definitions. The python script used to generate a linker script for app_smem was also midified to simplify the alignment directives. A default linker script app_smem.ld was added to remove the conditional includes dependency on CONFIG_APP_SHARED_MEM. By addining the default linker script the prebuild stages link properly prior to the python script running Signed-off-by: Joshua Domagalski <jedomag@tycho.nsa.gov> Signed-off-by: Shawn Mosley <smmosle@tycho.nsa.gov>
2018-04-26 16:14:02 +02:00
if(CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT AND CONFIG_APP_SHARED_MEM)
set(APP_SMEM_LD "${PROJECT_BINARY_DIR}/include/generated/app_smem.ld")
set(OBJ_FILE_DIR "${PROJECT_BINARY_DIR}/../")
add_custom_target(
${APP_SMEM_DEP} ALL
userspace: app_shared_mem: Fixed incorrect implementation. This feature was failing on a default ARM core MPU. The linker script that was getting created was not able to align the required partitions at prebuilt time. The old implementation relied on the prebuilt to finish then extract the size information which was then used to align the regions. This fails because the size of the alignment and the fill in the linker needs to be available at prebuilt time else it cant manage the final elf file generation. We cant have 2 different sizes of prebuilt and final elf file. This implementation will get the alignment requirements met at prebuilt time. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-08-04 16:18:52 +02:00
DEPENDS app
CMakeLists.txt: Updated the rule for shared memory alignment. Due to the new changes for the subsys/app_memory we need to have the script for smem run before any elf is created. This is needed because the compiled code will have references to certain linker variables that will be created by gen_app_partitions.py. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-09-19 07:58:27 +02:00
kernel
userspace: compartmentalized app memory organization Summary: revised attempt at addressing issue 6290. The following provides an alternative to using CONFIG_APPLICATION_MEMORY by compartmentalizing data into Memory Domains. Dependent on MPU limitations, supports compartmentalized Memory Domains for 1...N logical applications. This is considered an initial attempt at designing flexible compartmentalized Memory Domains for multiple logical applications and, with the provided python script and edited CMakeLists.txt, provides support for power of 2 aligned MPU architectures. Overview: The current patch uses qualifiers to group data into subsections. The qualifier usage allows for dynamic subsection creation and affords the developer a large amount of flexibility in the grouping, naming, and size of the resulting partitions and domains that are built on these subsections. By additional macro calls, functions are created that help calculate the size, address, and permissions for the subsections and enable the developer to control application data in specified partitions and memory domains. Background: Initial attempts focused on creating a single section in the linker script that then contained internally grouped variables/data to allow MPU/MMU alignment and protection. This did not provide additional functionality beyond CONFIG_APPLICATION_MEMORY as we were unable to reliably group data or determine their grouping via exported linker symbols. Thus, the resulting decision was made to dynamically create subsections using the current qualifier method. An attempt to group the data by object file was tested, but found that this broke applications such as ztest where two object files are created: ztest and main. This also creates an issue of grouping the two object files together in the same memory domain while also allowing for compartmenting other data among threads. Because it is not possible to know a) the name of the partition and thus the symbol in the linker, b) the size of all the data in the subsection, nor c) the overall number of partitions created by the developer, it was not feasible to align the subsections at compile time without using dynamically generated linker script for MPU architectures requiring power of 2 alignment. In order to provide support for MPU architectures that require a power of 2 alignment, a python script is run at build prior to when linker_priv_stacks.cmd is generated. This script scans the built object files for all possible partitions and the names given to them. It then generates a linker file (app_smem.ld) that is included in the main linker.ld file. This app_smem.ld allows the compiler and linker to then create each subsection and align to the next power of 2. Usage: - Requires: app_memory/app_memdomain.h . - _app_dmem(id) marks a variable to be placed into a data section for memory partition id. - _app_bmem(id) marks a variable to be placed into a bss section for memory partition id. - These are seen in the linker.map as "data_smem_id" and "data_smem_idb". - To create a k_mem_partition, call the macro app_mem_partition(part0) where "part0" is the name then used to refer to that partition. This macro only creates a function and necessary data structures for the later "initialization". - To create a memory domain for the partition, the macro app_mem_domain(dom0) is called where "dom0" is the name then used for the memory domain. - To initialize the partition (effectively adding the partition to a linked list), init_part_part0() is called. This is followed by init_app_memory(), which walks all partitions in the linked list and calculates the sizes for each partition. - Once the partition is initialized, the domain can be initialized with init_domain_dom0(part0) which initializes the domain with partition part0. - After the domain has been initialized, the current thread can be added using add_thread_dom0(k_current_get()). - The code used in ztests ans kernel/init has been added under a conditional #ifdef to isolate the code from other tests. The userspace test CMakeLists.txt file has commands to insert the CONFIG_APP_SHARED_MEM definition into the required build targets. Example: /* create partition at top of file outside functions */ app_mem_partition(part0); /* create domain */ app_mem_domain(dom0); _app_dmem(dom0) int var1; _app_bmem(dom0) static volatile int var2; int main() { init_part_part0(); init_app_memory(); init_domain_dom0(part0); add_thread_dom0(k_current_get()); ... } - If multiple partitions are being created, a variadic preprocessor macro can be used as provided in app_macro_support.h: FOR_EACH(app_mem_partition, part0, part1, part2); or, for multiple domains, similarly: FOR_EACH(app_mem_domain, dom0, dom1); Similarly, the init_part_* can also be used in the macro: FOR_EACH(init_part, part0, part1, part2); Testing: - This has been successfully tested on qemu_x86 and the ARM frdm_k64f board. It compiles and builds power of 2 aligned subsections for the linker script on the 96b_carbon boards. These power of 2 alignments have been checked by hand and are viewable in the zephyr.map file that is produced during build. However, due to a shortage of available MPU regions on the 96b_carbon board, we are unable to test this. - When run on the 96b_carbon board, the test suite will enter execution, but each individaul test will fail due to an MPU FAULT. This is expected as the required number of MPU regions exceeds the number allowed due to the static allocation. As the MPU driver does not detect this issue, the fault occurs because the data being accessed has been placed outside the active MPU region. - This now compiles successfully for the ARC boards em_starterkit_em7d and em_starterkit_em7d_v22. However, as we lack ARC hardware to run this build on, we are unable to test this build. Current known issues: 1) While the script and edited CMakeLists.txt creates the ability to align to the next power of 2, this does not address the shortage of available MPU regions on certain devices (e.g. 96b_carbon). In testing the APB and PPB regions were commented out. 2) checkpatch.pl lists several issues regarding the following: a) Complex macros. The FOR_EACH macros as defined in app_macro_support.h are listed as complex macros needing parentheses. Adding parentheses breaks their functionality, and we have otherwise been unable to resolve the reported error. b) __aligned() preferred. The _app_dmem_pad() and _app_bmem_pad() macros give warnings that __aligned() is preferred. Prior iterations had this implementation, which resulted in errors due to "complex macros". c) Trailing semicolon. The macro init_part(name) has a trailing semicolon as the semicolon is needed for the inlined macro call that is generated when this macro expands. Update: updated to alternative CONFIG_APPLCATION_MEMORY. Added config option CONFIG_APP_SHARED_MEM to enable a new section app_smem to contain the shared memory component. This commit seperates the Kconfig definition from the definition used for the conditional code. The change is in response to changes in the way the build system treats definitions. The python script used to generate a linker script for app_smem was also midified to simplify the alignment directives. A default linker script app_smem.ld was added to remove the conditional includes dependency on CONFIG_APP_SHARED_MEM. By addining the default linker script the prebuild stages link properly prior to the python script running Signed-off-by: Joshua Domagalski <jedomag@tycho.nsa.gov> Signed-off-by: Shawn Mosley <smmosle@tycho.nsa.gov>
2018-04-26 16:14:02 +02:00
)
add_custom_command(
TARGET ${APP_SMEM_DEP}
userspace: app_shared_mem: Fixed incorrect implementation. This feature was failing on a default ARM core MPU. The linker script that was getting created was not able to align the required partitions at prebuilt time. The old implementation relied on the prebuilt to finish then extract the size information which was then used to align the regions. This fails because the size of the alignment and the fill in the linker needs to be available at prebuilt time else it cant manage the final elf file generation. We cant have 2 different sizes of prebuilt and final elf file. This implementation will get the alignment requirements met at prebuilt time. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-08-04 16:18:52 +02:00
COMMAND ${PYTHON_EXECUTABLE}
${ZEPHYR_BASE}/scripts/gen_app_partitions.py
userspace: compartmentalized app memory organization Summary: revised attempt at addressing issue 6290. The following provides an alternative to using CONFIG_APPLICATION_MEMORY by compartmentalizing data into Memory Domains. Dependent on MPU limitations, supports compartmentalized Memory Domains for 1...N logical applications. This is considered an initial attempt at designing flexible compartmentalized Memory Domains for multiple logical applications and, with the provided python script and edited CMakeLists.txt, provides support for power of 2 aligned MPU architectures. Overview: The current patch uses qualifiers to group data into subsections. The qualifier usage allows for dynamic subsection creation and affords the developer a large amount of flexibility in the grouping, naming, and size of the resulting partitions and domains that are built on these subsections. By additional macro calls, functions are created that help calculate the size, address, and permissions for the subsections and enable the developer to control application data in specified partitions and memory domains. Background: Initial attempts focused on creating a single section in the linker script that then contained internally grouped variables/data to allow MPU/MMU alignment and protection. This did not provide additional functionality beyond CONFIG_APPLICATION_MEMORY as we were unable to reliably group data or determine their grouping via exported linker symbols. Thus, the resulting decision was made to dynamically create subsections using the current qualifier method. An attempt to group the data by object file was tested, but found that this broke applications such as ztest where two object files are created: ztest and main. This also creates an issue of grouping the two object files together in the same memory domain while also allowing for compartmenting other data among threads. Because it is not possible to know a) the name of the partition and thus the symbol in the linker, b) the size of all the data in the subsection, nor c) the overall number of partitions created by the developer, it was not feasible to align the subsections at compile time without using dynamically generated linker script for MPU architectures requiring power of 2 alignment. In order to provide support for MPU architectures that require a power of 2 alignment, a python script is run at build prior to when linker_priv_stacks.cmd is generated. This script scans the built object files for all possible partitions and the names given to them. It then generates a linker file (app_smem.ld) that is included in the main linker.ld file. This app_smem.ld allows the compiler and linker to then create each subsection and align to the next power of 2. Usage: - Requires: app_memory/app_memdomain.h . - _app_dmem(id) marks a variable to be placed into a data section for memory partition id. - _app_bmem(id) marks a variable to be placed into a bss section for memory partition id. - These are seen in the linker.map as "data_smem_id" and "data_smem_idb". - To create a k_mem_partition, call the macro app_mem_partition(part0) where "part0" is the name then used to refer to that partition. This macro only creates a function and necessary data structures for the later "initialization". - To create a memory domain for the partition, the macro app_mem_domain(dom0) is called where "dom0" is the name then used for the memory domain. - To initialize the partition (effectively adding the partition to a linked list), init_part_part0() is called. This is followed by init_app_memory(), which walks all partitions in the linked list and calculates the sizes for each partition. - Once the partition is initialized, the domain can be initialized with init_domain_dom0(part0) which initializes the domain with partition part0. - After the domain has been initialized, the current thread can be added using add_thread_dom0(k_current_get()). - The code used in ztests ans kernel/init has been added under a conditional #ifdef to isolate the code from other tests. The userspace test CMakeLists.txt file has commands to insert the CONFIG_APP_SHARED_MEM definition into the required build targets. Example: /* create partition at top of file outside functions */ app_mem_partition(part0); /* create domain */ app_mem_domain(dom0); _app_dmem(dom0) int var1; _app_bmem(dom0) static volatile int var2; int main() { init_part_part0(); init_app_memory(); init_domain_dom0(part0); add_thread_dom0(k_current_get()); ... } - If multiple partitions are being created, a variadic preprocessor macro can be used as provided in app_macro_support.h: FOR_EACH(app_mem_partition, part0, part1, part2); or, for multiple domains, similarly: FOR_EACH(app_mem_domain, dom0, dom1); Similarly, the init_part_* can also be used in the macro: FOR_EACH(init_part, part0, part1, part2); Testing: - This has been successfully tested on qemu_x86 and the ARM frdm_k64f board. It compiles and builds power of 2 aligned subsections for the linker script on the 96b_carbon boards. These power of 2 alignments have been checked by hand and are viewable in the zephyr.map file that is produced during build. However, due to a shortage of available MPU regions on the 96b_carbon board, we are unable to test this. - When run on the 96b_carbon board, the test suite will enter execution, but each individaul test will fail due to an MPU FAULT. This is expected as the required number of MPU regions exceeds the number allowed due to the static allocation. As the MPU driver does not detect this issue, the fault occurs because the data being accessed has been placed outside the active MPU region. - This now compiles successfully for the ARC boards em_starterkit_em7d and em_starterkit_em7d_v22. However, as we lack ARC hardware to run this build on, we are unable to test this build. Current known issues: 1) While the script and edited CMakeLists.txt creates the ability to align to the next power of 2, this does not address the shortage of available MPU regions on certain devices (e.g. 96b_carbon). In testing the APB and PPB regions were commented out. 2) checkpatch.pl lists several issues regarding the following: a) Complex macros. The FOR_EACH macros as defined in app_macro_support.h are listed as complex macros needing parentheses. Adding parentheses breaks their functionality, and we have otherwise been unable to resolve the reported error. b) __aligned() preferred. The _app_dmem_pad() and _app_bmem_pad() macros give warnings that __aligned() is preferred. Prior iterations had this implementation, which resulted in errors due to "complex macros". c) Trailing semicolon. The macro init_part(name) has a trailing semicolon as the semicolon is needed for the inlined macro call that is generated when this macro expands. Update: updated to alternative CONFIG_APPLCATION_MEMORY. Added config option CONFIG_APP_SHARED_MEM to enable a new section app_smem to contain the shared memory component. This commit seperates the Kconfig definition from the definition used for the conditional code. The change is in response to changes in the way the build system treats definitions. The python script used to generate a linker script for app_smem was also midified to simplify the alignment directives. A default linker script app_smem.ld was added to remove the conditional includes dependency on CONFIG_APP_SHARED_MEM. By addining the default linker script the prebuild stages link properly prior to the python script running Signed-off-by: Joshua Domagalski <jedomag@tycho.nsa.gov> Signed-off-by: Shawn Mosley <smmosle@tycho.nsa.gov>
2018-04-26 16:14:02 +02:00
-d ${OBJ_FILE_DIR}
-o ${APP_SMEM_LD}
userspace: app_shared_mem: Fixed incorrect implementation. This feature was failing on a default ARM core MPU. The linker script that was getting created was not able to align the required partitions at prebuilt time. The old implementation relied on the prebuilt to finish then extract the size information which was then used to align the regions. This fails because the size of the alignment and the fill in the linker needs to be available at prebuilt time else it cant manage the final elf file generation. We cant have 2 different sizes of prebuilt and final elf file. This implementation will get the alignment requirements met at prebuilt time. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-08-04 16:18:52 +02:00
$<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--verbose>
userspace: compartmentalized app memory organization Summary: revised attempt at addressing issue 6290. The following provides an alternative to using CONFIG_APPLICATION_MEMORY by compartmentalizing data into Memory Domains. Dependent on MPU limitations, supports compartmentalized Memory Domains for 1...N logical applications. This is considered an initial attempt at designing flexible compartmentalized Memory Domains for multiple logical applications and, with the provided python script and edited CMakeLists.txt, provides support for power of 2 aligned MPU architectures. Overview: The current patch uses qualifiers to group data into subsections. The qualifier usage allows for dynamic subsection creation and affords the developer a large amount of flexibility in the grouping, naming, and size of the resulting partitions and domains that are built on these subsections. By additional macro calls, functions are created that help calculate the size, address, and permissions for the subsections and enable the developer to control application data in specified partitions and memory domains. Background: Initial attempts focused on creating a single section in the linker script that then contained internally grouped variables/data to allow MPU/MMU alignment and protection. This did not provide additional functionality beyond CONFIG_APPLICATION_MEMORY as we were unable to reliably group data or determine their grouping via exported linker symbols. Thus, the resulting decision was made to dynamically create subsections using the current qualifier method. An attempt to group the data by object file was tested, but found that this broke applications such as ztest where two object files are created: ztest and main. This also creates an issue of grouping the two object files together in the same memory domain while also allowing for compartmenting other data among threads. Because it is not possible to know a) the name of the partition and thus the symbol in the linker, b) the size of all the data in the subsection, nor c) the overall number of partitions created by the developer, it was not feasible to align the subsections at compile time without using dynamically generated linker script for MPU architectures requiring power of 2 alignment. In order to provide support for MPU architectures that require a power of 2 alignment, a python script is run at build prior to when linker_priv_stacks.cmd is generated. This script scans the built object files for all possible partitions and the names given to them. It then generates a linker file (app_smem.ld) that is included in the main linker.ld file. This app_smem.ld allows the compiler and linker to then create each subsection and align to the next power of 2. Usage: - Requires: app_memory/app_memdomain.h . - _app_dmem(id) marks a variable to be placed into a data section for memory partition id. - _app_bmem(id) marks a variable to be placed into a bss section for memory partition id. - These are seen in the linker.map as "data_smem_id" and "data_smem_idb". - To create a k_mem_partition, call the macro app_mem_partition(part0) where "part0" is the name then used to refer to that partition. This macro only creates a function and necessary data structures for the later "initialization". - To create a memory domain for the partition, the macro app_mem_domain(dom0) is called where "dom0" is the name then used for the memory domain. - To initialize the partition (effectively adding the partition to a linked list), init_part_part0() is called. This is followed by init_app_memory(), which walks all partitions in the linked list and calculates the sizes for each partition. - Once the partition is initialized, the domain can be initialized with init_domain_dom0(part0) which initializes the domain with partition part0. - After the domain has been initialized, the current thread can be added using add_thread_dom0(k_current_get()). - The code used in ztests ans kernel/init has been added under a conditional #ifdef to isolate the code from other tests. The userspace test CMakeLists.txt file has commands to insert the CONFIG_APP_SHARED_MEM definition into the required build targets. Example: /* create partition at top of file outside functions */ app_mem_partition(part0); /* create domain */ app_mem_domain(dom0); _app_dmem(dom0) int var1; _app_bmem(dom0) static volatile int var2; int main() { init_part_part0(); init_app_memory(); init_domain_dom0(part0); add_thread_dom0(k_current_get()); ... } - If multiple partitions are being created, a variadic preprocessor macro can be used as provided in app_macro_support.h: FOR_EACH(app_mem_partition, part0, part1, part2); or, for multiple domains, similarly: FOR_EACH(app_mem_domain, dom0, dom1); Similarly, the init_part_* can also be used in the macro: FOR_EACH(init_part, part0, part1, part2); Testing: - This has been successfully tested on qemu_x86 and the ARM frdm_k64f board. It compiles and builds power of 2 aligned subsections for the linker script on the 96b_carbon boards. These power of 2 alignments have been checked by hand and are viewable in the zephyr.map file that is produced during build. However, due to a shortage of available MPU regions on the 96b_carbon board, we are unable to test this. - When run on the 96b_carbon board, the test suite will enter execution, but each individaul test will fail due to an MPU FAULT. This is expected as the required number of MPU regions exceeds the number allowed due to the static allocation. As the MPU driver does not detect this issue, the fault occurs because the data being accessed has been placed outside the active MPU region. - This now compiles successfully for the ARC boards em_starterkit_em7d and em_starterkit_em7d_v22. However, as we lack ARC hardware to run this build on, we are unable to test this build. Current known issues: 1) While the script and edited CMakeLists.txt creates the ability to align to the next power of 2, this does not address the shortage of available MPU regions on certain devices (e.g. 96b_carbon). In testing the APB and PPB regions were commented out. 2) checkpatch.pl lists several issues regarding the following: a) Complex macros. The FOR_EACH macros as defined in app_macro_support.h are listed as complex macros needing parentheses. Adding parentheses breaks their functionality, and we have otherwise been unable to resolve the reported error. b) __aligned() preferred. The _app_dmem_pad() and _app_bmem_pad() macros give warnings that __aligned() is preferred. Prior iterations had this implementation, which resulted in errors due to "complex macros". c) Trailing semicolon. The macro init_part(name) has a trailing semicolon as the semicolon is needed for the inlined macro call that is generated when this macro expands. Update: updated to alternative CONFIG_APPLCATION_MEMORY. Added config option CONFIG_APP_SHARED_MEM to enable a new section app_smem to contain the shared memory component. This commit seperates the Kconfig definition from the definition used for the conditional code. The change is in response to changes in the way the build system treats definitions. The python script used to generate a linker script for app_smem was also midified to simplify the alignment directives. A default linker script app_smem.ld was added to remove the conditional includes dependency on CONFIG_APP_SHARED_MEM. By addining the default linker script the prebuild stages link properly prior to the python script running Signed-off-by: Joshua Domagalski <jedomag@tycho.nsa.gov> Signed-off-by: Shawn Mosley <smmosle@tycho.nsa.gov>
2018-04-26 16:14:02 +02:00
WORKING_DIRECTORY ${PROJECT_BINARY_DIR}/
COMMENT "Generating power of 2 aligned app_smem linker section"
)
endif()
cmake: move app_data_alignment.ld under ARC sub-directory This commit moves the app_data_alignment.ld scripts under arch/arc sub-directory, as it is not not used at all in ARM builds. The script is still used for ARC, whose v2 MPU also has the reuquirement for power-of-two size alignment. Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
2018-11-29 14:26:01 +01:00
if(CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT AND CONFIG_ARC AND CONFIG_APPLICATION_MEMORY)
arm: Add app data section alignment constraints This patch adds application data section alignment constraints to match the region definition requirements for ARM MPUs. Most MPUs require a minimum of 32 bytes of alignment for any regions, but some require power of two alignment to the size of a region. This requires that the linker align the application data section to the size of the section. This requires a linker pass to determine the size. Once this is accomplished the correct value is added to a linker include file that is utilized in subsequent linker operations. Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:12:32 +01:00
construct_add_custom_command_for_linker_pass(linker_app_sizing custom_command)
add_custom_command(
${custom_command}
)
add_custom_target(
linker_app_sizing_script
DEPENDS
linker_app_sizing.cmd
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
${OFFSETS_H_TARGET}
CMakeLists.txt: Updated the rule for shared memory alignment. Due to the new changes for the subsys/app_memory we need to have the script for smem run before any elf is created. This is needed because the compiled code will have references to certain linker variables that will be created by gen_app_partitions.py. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-09-19 07:58:27 +02:00
${APP_SMEM_DEP}
cmake: Added rule and helper functions for code relocation. This patch creates a rule in the cmake to trigger the generation of linker_relocate.ld and code_relocation.c files. The linker_relocate.ld will create appropriate sections and will link the required functions or variables from all the selected files. The code_relocation.c will have code that is needed for initializing data sections and copy of text sections(if XIP). Also this will contain code that is needed for zeroing of bss. The procedure to invoke this feature is: 1. Enable CONFIG_CODE_RELOCATION in the prj.conf 2. Inside CMakeList.txt in the project we need to mention all the files that needs to get relocated. zephyr_kernel_code_relocate(src/*.c SRAM2) Where the first argument is the file/files and the second argument is the memory where it has be placed. NOTE: The file argument supports glob expressions. NOTE: Step 2 can be done as many times as required. And relative paths can be given here. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-11-13 11:04:02 +01:00
${CODE_RELOCATION_DEP}
arm: Add app data section alignment constraints This patch adds application data section alignment constraints to match the region definition requirements for ARM MPUs. Most MPUs require a minimum of 32 bytes of alignment for any regions, but some require power of two alignment to the size of a region. This requires that the linker align the application data section to the size of the section. This requires a linker pass to determine the size. Once this is accomplished the correct value is added to a linker include file that is utilized in subsequent linker operations. Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:12:32 +01:00
)
set_property(TARGET
linker_app_sizing_script
PROPERTY INCLUDE_DIRECTORIES
${ZEPHYR_INCLUDE_DIRS}
)
# For systems with MPUs, the size of the application data section must
# be determined so that MPU alignment requirements can be met.
# Create a app_sizing_prebuilt target so we can do this before the
# other ELF files are built
set(GEN_APP_ALIGN $ENV{ZEPHYR_BASE}/scripts/gen_alignment_script.py)
add_executable( app_sizing_prebuilt misc/empty_file.c)
cmake: Added rule and helper functions for code relocation. This patch creates a rule in the cmake to trigger the generation of linker_relocate.ld and code_relocation.c files. The linker_relocate.ld will create appropriate sections and will link the required functions or variables from all the selected files. The code_relocation.c will have code that is needed for initializing data sections and copy of text sections(if XIP). Also this will contain code that is needed for zeroing of bss. The procedure to invoke this feature is: 1. Enable CONFIG_CODE_RELOCATION in the prj.conf 2. Inside CMakeList.txt in the project we need to mention all the files that needs to get relocated. zephyr_kernel_code_relocate(src/*.c SRAM2) Where the first argument is the file/files and the second argument is the memory where it has be placed. NOTE: The file argument supports glob expressions. NOTE: Step 2 can be done as many times as required. And relative paths can be given here. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-11-13 11:04:02 +01:00
target_link_libraries(app_sizing_prebuilt ${TOPT} ${PROJECT_BINARY_DIR}/linker_app_sizing.cmd ${zephyr_lnk} ${CODE_RELOCATION_DEP})
arm: Add app data section alignment constraints This patch adds application data section alignment constraints to match the region definition requirements for ARM MPUs. Most MPUs require a minimum of 32 bytes of alignment for any regions, but some require power of two alignment to the size of a region. This requires that the linker align the application data section to the size of the section. This requires a linker pass to determine the size. Once this is accomplished the correct value is added to a linker include file that is utilized in subsequent linker operations. Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:12:32 +01:00
set_property(TARGET app_sizing_prebuilt PROPERTY LINK_DEPENDS ${PROJECT_BINARY_DIR}/linker_app_sizing.cmd)
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
add_dependencies( app_sizing_prebuilt linker_app_sizing_script ${OFFSETS_LIB} ${CODE_RELOCATION_DEP} )
arm: Add app data section alignment constraints This patch adds application data section alignment constraints to match the region definition requirements for ARM MPUs. Most MPUs require a minimum of 32 bytes of alignment for any regions, but some require power of two alignment to the size of a region. This requires that the linker align the application data section to the size of the section. This requires a linker pass to determine the size. Once this is accomplished the correct value is added to a linker include file that is utilized in subsequent linker operations. Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:12:32 +01:00
add_custom_command(
TARGET app_sizing_prebuilt
POST_BUILD
COMMAND ${PYTHON_EXECUTABLE} ${GEN_APP_ALIGN}
--output ./include/generated/app_data_alignment.ld
--kernel $<TARGET_FILE:app_sizing_prebuilt>
VERBATIM
WORKING_DIRECTORY ${PROJECT_BINARY_DIR}/
)
endif()
arm: Generate privileged stacks This patch adds the generation and incorporation of privileged stack regions that are used by ARM user mode threads. This patch adds the infrastructure for privileged stacks. Later patches will utilize the generated stacks and helper functions. Signed-off-by: Chunlin Han <chunlin.han@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:19:49 +01:00
cmake: disable privilege stack generation for arc Currently, ARC will not use privilege stack generation. Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
2018-02-12 12:17:04 +01:00
if(CONFIG_ARM)
arm: Generate privileged stacks This patch adds the generation and incorporation of privileged stack regions that are used by ARM user mode threads. This patch adds the infrastructure for privileged stacks. Later patches will utilize the generated stacks and helper functions. Signed-off-by: Chunlin Han <chunlin.han@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:19:49 +01:00
construct_add_custom_command_for_linker_pass(linker_priv_stacks custom_command)
add_custom_command(
${custom_command}
)
add_custom_target(
linker_priv_stacks_script
DEPENDS
CMakeLists.txt: Set application shared memory dependency The scripts for app_smem need to be ready before the script for privilaged stack is run. This is needed because there is a small possibility that the stacks get aligned (due to app_smem) after privilaged stack script is run. This causes the gperf to create an incorrect hash. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-09-18 08:22:52 +02:00
${ALIGN_SIZING_DEP} ${APP_SMEM_DEP}
cmake: Added rule and helper functions for code relocation. This patch creates a rule in the cmake to trigger the generation of linker_relocate.ld and code_relocation.c files. The linker_relocate.ld will create appropriate sections and will link the required functions or variables from all the selected files. The code_relocation.c will have code that is needed for initializing data sections and copy of text sections(if XIP). Also this will contain code that is needed for zeroing of bss. The procedure to invoke this feature is: 1. Enable CONFIG_CODE_RELOCATION in the prj.conf 2. Inside CMakeList.txt in the project we need to mention all the files that needs to get relocated. zephyr_kernel_code_relocate(src/*.c SRAM2) Where the first argument is the file/files and the second argument is the memory where it has be placed. NOTE: The file argument supports glob expressions. NOTE: Step 2 can be done as many times as required. And relative paths can be given here. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-11-13 11:04:02 +01:00
${CODE_RELOCATION_DEP}
arm: Generate privileged stacks This patch adds the generation and incorporation of privileged stack regions that are used by ARM user mode threads. This patch adds the infrastructure for privileged stacks. Later patches will utilize the generated stacks and helper functions. Signed-off-by: Chunlin Han <chunlin.han@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:19:49 +01:00
linker_priv_stacks.cmd
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
${OFFSETS_H_TARGET}
arm: Generate privileged stacks This patch adds the generation and incorporation of privileged stack regions that are used by ARM user mode threads. This patch adds the infrastructure for privileged stacks. Later patches will utilize the generated stacks and helper functions. Signed-off-by: Chunlin Han <chunlin.han@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:19:49 +01:00
)
set_property(TARGET
linker_priv_stacks_script
PROPERTY INCLUDE_DIRECTORIES
${ZEPHYR_INCLUDE_DIRS}
)
set(PRIV_STACK_LIB priv_stacks_output_obj_renamed_lib)
add_executable( priv_stacks_prebuilt misc/empty_file.c)
cmake: Added rule and helper functions for code relocation. This patch creates a rule in the cmake to trigger the generation of linker_relocate.ld and code_relocation.c files. The linker_relocate.ld will create appropriate sections and will link the required functions or variables from all the selected files. The code_relocation.c will have code that is needed for initializing data sections and copy of text sections(if XIP). Also this will contain code that is needed for zeroing of bss. The procedure to invoke this feature is: 1. Enable CONFIG_CODE_RELOCATION in the prj.conf 2. Inside CMakeList.txt in the project we need to mention all the files that needs to get relocated. zephyr_kernel_code_relocate(src/*.c SRAM2) Where the first argument is the file/files and the second argument is the memory where it has be placed. NOTE: The file argument supports glob expressions. NOTE: Step 2 can be done as many times as required. And relative paths can be given here. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-11-13 11:04:02 +01:00
target_link_libraries(priv_stacks_prebuilt ${TOPT} ${PROJECT_BINARY_DIR}/linker_priv_stacks.cmd ${zephyr_lnk} ${CODE_RELOCATION_DEP})
arm: Generate privileged stacks This patch adds the generation and incorporation of privileged stack regions that are used by ARM user mode threads. This patch adds the infrastructure for privileged stacks. Later patches will utilize the generated stacks and helper functions. Signed-off-by: Chunlin Han <chunlin.han@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:19:49 +01:00
set_property(TARGET priv_stacks_prebuilt PROPERTY LINK_DEPENDS ${PROJECT_BINARY_DIR}/linker_priv_stacks.cmd)
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
add_dependencies( priv_stacks_prebuilt ${ALIGN_SIZING_DEP} linker_priv_stacks_script ${OFFSETS_LIB})
cmake: disable privilege stack generation for arc Currently, ARC will not use privilege stack generation. Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
2018-02-12 12:17:04 +01:00
endif()
arm: Generate privileged stacks This patch adds the generation and incorporation of privileged stack regions that are used by ARM user mode threads. This patch adds the infrastructure for privileged stacks. Later patches will utilize the generated stacks and helper functions. Signed-off-by: Chunlin Han <chunlin.han@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:19:49 +01:00
arm: Add app data section alignment constraints This patch adds application data section alignment constraints to match the region definition requirements for ARM MPUs. Most MPUs require a minimum of 32 bytes of alignment for any regions, but some require power of two alignment to the size of a region. This requires that the linker align the application data section to the size of the section. This requires a linker pass to determine the size. Once this is accomplished the correct value is added to a linker include file that is utilized in subsequent linker operations. Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:12:32 +01:00
endif()
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
# FIXME: Is there any way to get rid of empty_file.c?
cmake: Use a variable for 'zephyr_prebuilt' There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:31:02 +01:00
add_executable( ${ZEPHYR_PREBUILT_EXECUTABLE} misc/empty_file.c)
target_link_libraries(${ZEPHYR_PREBUILT_EXECUTABLE} ${TOPT} ${PROJECT_BINARY_DIR}/linker.cmd ${PRIV_STACK_LIB} ${zephyr_lnk} ${CODE_RELOCATION_DEP})
set_property(TARGET ${ZEPHYR_PREBUILT_EXECUTABLE} PROPERTY LINK_DEPENDS ${PROJECT_BINARY_DIR}/linker.cmd)
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
add_dependencies( ${ZEPHYR_PREBUILT_EXECUTABLE} ${ALIGN_SIZING_DEP} ${PRIV_STACK_DEP} ${LINKER_SCRIPT_TARGET} ${OFFSETS_LIB})
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
arch: native: Run Zephyr natively in a POSIX OS A new arch (posix) which relies on pthreads to emulate the context switching A new soc for it (inf_clock) which emulates a CPU running at an infinely high clock (so when the CPU is awaken it runs till completion in 0 time) A new board, which provides a trivial system tick timer and irq generation. Origin: Original Fixes #1891 Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com> Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-10-03 16:31:55 +02:00
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
if(GKOF OR GKSF)
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
set(KERNEL_ELF kernel_elf)
set(logical_target_for_zephyr_elf ${KERNEL_ELF})
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
# The second linker pass uses the same source linker script of the
cmake: ld: Refactor the linker script's cpp command construction Construct the custom command for preprocessing the linker script with a function to avoid copy-paste errors between linker passes. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-31 10:39:23 +01:00
# first pass (LINKER_SCRIPT), but this time with a different output
# file and preprocessed with the define LINKER_PASS2.
makefile: Convert linker function to use names This patch changes the way the custom linker function works. It uses names instead of numbers to denote the name of the file and applies the correct LINKER_PASS variable for the final linker pass. Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-01-25 18:07:03 +01:00
construct_add_custom_command_for_linker_pass(linker_pass_final custom_command)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
add_custom_command(
cmake: ld: Refactor the linker script's cpp command construction Construct the custom command for preprocessing the linker script with a function to avoid copy-paste errors between linker passes. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-31 10:39:23 +01:00
${custom_command}
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
)
arm: Add app data section alignment constraints This patch adds application data section alignment constraints to match the region definition requirements for ARM MPUs. Most MPUs require a minimum of 32 bytes of alignment for any regions, but some require power of two alignment to the size of a region. This requires that the linker align the application data section to the size of the section. This requires a linker pass to determine the size. Once this is accomplished the correct value is added to a linker include file that is utilized in subsequent linker operations. Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:12:32 +01:00
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
set(LINKER_PASS_FINAL_SCRIPT_TARGET linker_pass_final_script_target)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
add_custom_target(
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
${LINKER_PASS_FINAL_SCRIPT_TARGET}
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
DEPENDS
arm: Generate privileged stacks This patch adds the generation and incorporation of privileged stack regions that are used by ARM user mode threads. This patch adds the infrastructure for privileged stacks. Later patches will utilize the generated stacks and helper functions. Signed-off-by: Chunlin Han <chunlin.han@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:19:49 +01:00
${ALIGN_SIZING_DEP} ${PRIV_STACK_DEP}
cmake: Added rule and helper functions for code relocation. This patch creates a rule in the cmake to trigger the generation of linker_relocate.ld and code_relocation.c files. The linker_relocate.ld will create appropriate sections and will link the required functions or variables from all the selected files. The code_relocation.c will have code that is needed for initializing data sections and copy of text sections(if XIP). Also this will contain code that is needed for zeroing of bss. The procedure to invoke this feature is: 1. Enable CONFIG_CODE_RELOCATION in the prj.conf 2. Inside CMakeList.txt in the project we need to mention all the files that needs to get relocated. zephyr_kernel_code_relocate(src/*.c SRAM2) Where the first argument is the file/files and the second argument is the memory where it has be placed. NOTE: The file argument supports glob expressions. NOTE: Step 2 can be done as many times as required. And relative paths can be given here. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-11-13 11:04:02 +01:00
${CODE_RELOCATION_DEP}
cmake: Use a variable for 'zephyr_prebuilt' There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:31:02 +01:00
${ZEPHYR_PREBUILT_EXECUTABLE}
makefile: Convert linker function to use names This patch changes the way the custom linker function works. It uses names instead of numbers to denote the name of the file and applies the correct LINKER_PASS variable for the final linker pass. Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-01-25 18:07:03 +01:00
linker_pass_final.cmd
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
${OFFSETS_H_TARGET}
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
)
cmake: ld: Ensure that a linker script change triggers a rebuild This fixes https://github.com/zephyrproject-rtos/zephyr/issues/5010. CMake has a simple parser that can parse C-like files to find header dependencies. But the parser needs to know what the include directories are to be able to follow #include pragmas. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-14 13:03:23 +01:00
set_property(TARGET
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
${LINKER_PASS_FINAL_SCRIPT_TARGET}
cmake: ld: Ensure that a linker script change triggers a rebuild This fixes https://github.com/zephyrproject-rtos/zephyr/issues/5010. CMake has a simple parser that can parse C-like files to find header dependencies. But the parser needs to know what the include directories are to be able to follow #include pragmas. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-14 13:03:23 +01:00
PROPERTY INCLUDE_DIRECTORIES
${ZEPHYR_INCLUDE_DIRS}
)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
add_executable( ${KERNEL_ELF} misc/empty_file.c ${GKSF})
target_link_libraries(${KERNEL_ELF} ${GKOF} ${TOPT} ${PROJECT_BINARY_DIR}/linker_pass_final.cmd ${zephyr_lnk} ${CODE_RELOCATION_DEP})
set_property(TARGET ${KERNEL_ELF} PROPERTY LINK_DEPENDS ${PROJECT_BINARY_DIR}/linker_pass_final.cmd)
add_dependencies( ${KERNEL_ELF} ${ALIGN_SIZING_DEP} ${PRIV_STACK_DEP} ${LINKER_PASS_FINAL_SCRIPT_TARGET})
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
else()
cmake: Use a variable for 'zephyr_prebuilt' There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:31:02 +01:00
set(logical_target_for_zephyr_elf ${ZEPHYR_PREBUILT_EXECUTABLE})
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
# Use the prebuilt elf as the final elf since we don't have a
# generation stage.
endif()
cmake: Export the target name of the final elf file to the app For the 'app' build scripts to be able to do post-processing on the elf file they need to know what the target name for the elf file is. In zephyr this name varies depending on whether one does a single or multiple link, so we export a variable with the name. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-10-16 13:25:04 +02:00
# Export the variable to the application's scope to allow the
# application to know what the name of the final elf target is.
set(logical_target_for_zephyr_elf ${logical_target_for_zephyr_elf} PARENT_SCOPE)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
# To avoid having the same logical target name for the zephyr lib and
# the zephyr elf, we set the kernel_elf file name to zephyr.elf.
set_target_properties(${logical_target_for_zephyr_elf} PROPERTIES OUTPUT_NAME ${KERNEL_NAME})
cmake: Generate POST_BUILD items based on KConfig Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-11-20 15:37:59 +01:00
set(post_build_commands "")
list_append_ifdef(CONFIG_CHECK_LINK_MAP
post_build_commands
cmake: Use path-corrected version of ZEPHYR_BASE Instead of accessing the environment variable ZEPHYR_BASE every time we require accessing the source code root, use an intermediate variable that has OS path separators correctly set to '/' to avoid issues on Windows. Note: This removes the ZEPHYR_SOURCE_DIR CMake variable. External applications using that will need to change to use the new ZEPHYR_BASE variable. Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2018-01-11 15:46:44 +01:00
COMMAND ${PYTHON_EXECUTABLE} ${ZEPHYR_BASE}/scripts/check_link_map.py ${KERNEL_MAP_NAME}
cmake: Generate POST_BUILD items based on KConfig Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-11-20 15:37:59 +01:00
)
kconfig: cmake: Support for images without gaps. Defines a Kconfig variable which allows the user to specify that any generated hex/bin/s19 file should not have filled gaps. This is done to support building in a multi image context, where several image files will be merged together. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-11-26 10:47:16 +01:00
if(NOT CONFIG_BUILD_NO_GAP_FILL)
# Use ';' as separator to get proper space in resulting command.
set(GAP_FILL "--gap-fill;0xff")
endif()
cmake: Generate POST_BUILD items based on KConfig Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-11-20 15:37:59 +01:00
list_append_ifdef(
CONFIG_BUILD_OUTPUT_HEX
post_build_commands
kconfig: cmake: Support for images without gaps. Defines a Kconfig variable which allows the user to specify that any generated hex/bin/s19 file should not have filled gaps. This is done to support building in a multi image context, where several image files will be merged together. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-11-26 10:47:16 +01:00
COMMAND ${CMAKE_OBJCOPY} -S -Oihex ${GAP_FILL} -R .comment -R COMMON -R .eh_frame ${KERNEL_ELF_NAME} ${KERNEL_HEX_NAME}
cmake: Generate POST_BUILD items based on KConfig Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-11-20 15:37:59 +01:00
)
list_append_ifdef(
CONFIG_BUILD_OUTPUT_BIN
post_build_commands
kconfig: cmake: Support for images without gaps. Defines a Kconfig variable which allows the user to specify that any generated hex/bin/s19 file should not have filled gaps. This is done to support building in a multi image context, where several image files will be merged together. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-11-26 10:47:16 +01:00
COMMAND ${CMAKE_OBJCOPY} -S -Obinary ${GAP_FILL} -R .comment -R COMMON -R .eh_frame ${KERNEL_ELF_NAME} ${KERNEL_BIN_NAME}
cmake: Generate POST_BUILD items based on KConfig Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-11-20 15:37:59 +01:00
)
native: build zephyr.exe for posix arch To indicate the generated binary is executable on the host, add .exe extension to the generated ELF file. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-11-23 13:54:26 +01:00
cmake: Generate POST_BUILD items based on KConfig Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-11-20 15:37:59 +01:00
list_append_ifdef(
CONFIG_BUILD_OUTPUT_S19
post_build_commands
kconfig: cmake: Support for images without gaps. Defines a Kconfig variable which allows the user to specify that any generated hex/bin/s19 file should not have filled gaps. This is done to support building in a multi image context, where several image files will be merged together. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-11-26 10:47:16 +01:00
COMMAND ${CMAKE_OBJCOPY} ${GAP_FILL} --srec-len 1 --output-target=srec ${KERNEL_ELF_NAME} ${KERNEL_S19_NAME}
cmake: Generate POST_BUILD items based on KConfig Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-11-20 15:37:59 +01:00
)
list_append_ifdef(
build: use kconfig to select generated artifacts Not all boards require the various binary formats zephyr generates. So be selective based on the arch, SoC or board and only geenrate the binaries actually needed. Fixes #5009 Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-11-22 19:03:53 +01:00
CONFIG_OUTPUT_DISASSEMBLY
cmake: Generate POST_BUILD items based on KConfig Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-11-20 15:37:59 +01:00
post_build_commands
COMMAND ${CMAKE_OBJDUMP} -S ${KERNEL_ELF_NAME} > ${KERNEL_LST_NAME}
)
list_append_ifdef(
build: use kconfig to select generated artifacts Not all boards require the various binary formats zephyr generates. So be selective based on the arch, SoC or board and only geenrate the binaries actually needed. Fixes #5009 Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-11-22 19:03:53 +01:00
CONFIG_OUTPUT_STAT
cmake: Generate POST_BUILD items based on KConfig Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-11-20 15:37:59 +01:00
post_build_commands
COMMAND ${CMAKE_READELF} -e ${KERNEL_ELF_NAME} > ${KERNEL_STAT_NAME}
)
list_append_ifdef(
CONFIG_BUILD_OUTPUT_STRIPPED
post_build_commands
COMMAND ${CMAKE_STRIP} --strip-all ${KERNEL_ELF_NAME} -o ${KERNEL_STRIP_NAME}
)
native: build zephyr.exe for posix arch To indicate the generated binary is executable on the host, add .exe extension to the generated ELF file. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-11-23 13:54:26 +01:00
list_append_ifdef(
CONFIG_BUILD_OUTPUT_EXE
post_build_commands
build: do not rename elf file, copy it We break dependency if we rename the zephyr.elf file, we should keep it as it is an essential dependency in the build system. Instead, copy the file. Fixes #10639 Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2018-10-16 16:54:53 +02:00
COMMAND ${CMAKE_COMMAND} -E copy ${KERNEL_ELF_NAME} ${KERNEL_EXE_NAME}
native: build zephyr.exe for posix arch To indicate the generated binary is executable on the host, add .exe extension to the generated ELF file. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-11-23 13:54:26 +01:00
)
cmake: Generate POST_BUILD items based on KConfig Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-11-20 15:37:59 +01:00
add_custom_command(
TARGET ${logical_target_for_zephyr_elf}
POST_BUILD
${post_build_commands}
COMMENT "Generating files from zephyr.elf for board: ${BOARD}"
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
# NB: COMMENT only works for some CMake-Generators
)
cmake: flash: scripts: Include externally built hex files Allow user to add externally built hex files to the cmake property HEX_FILES_TO_MERGE. The hex files in this list will be merged with the hex file generated when building the zephyr application. This allows users to leverage the application configuration available in Kconfig and CMake to help decide what hex file should be merged with the zephyr application. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-10-30 08:39:13 +01:00
# To populate with hex files to merge, do the following:
# set_property(GLOBAL APPEND PROPERTY HEX_FILES_TO_MERGE ${my_local_list})
# Note that the zephyr.hex file will not be included automatically.
get_property(HEX_FILES_TO_MERGE GLOBAL PROPERTY HEX_FILES_TO_MERGE)
if(HEX_FILES_TO_MERGE)
# Merge in out-of-tree hex files.
cmake: fix incorrect lower case variable This patch fixes a bug where a incorrect lower case variable 'MERGED_HEX_NAME' resulted in the 'flash' target not getting the correct path to the hex file to flash. This since cmake/flash/CMakeLists.txt uses the variable ${MERGED_HEX_NAME}. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-12-05 09:32:32 +01:00
set(MERGED_HEX_NAME merged.hex)
cmake: flash: scripts: Include externally built hex files Allow user to add externally built hex files to the cmake property HEX_FILES_TO_MERGE. The hex files in this list will be merged with the hex file generated when building the zephyr application. This allows users to leverage the application configuration available in Kconfig and CMake to help decide what hex file should be merged with the zephyr application. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-10-30 08:39:13 +01:00
add_custom_command(
cmake: fix incorrect lower case variable This patch fixes a bug where a incorrect lower case variable 'MERGED_HEX_NAME' resulted in the 'flash' target not getting the correct path to the hex file to flash. This since cmake/flash/CMakeLists.txt uses the variable ${MERGED_HEX_NAME}. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-12-05 09:32:32 +01:00
OUTPUT ${MERGED_HEX_NAME}
cmake: flash: scripts: Include externally built hex files Allow user to add externally built hex files to the cmake property HEX_FILES_TO_MERGE. The hex files in this list will be merged with the hex file generated when building the zephyr application. This allows users to leverage the application configuration available in Kconfig and CMake to help decide what hex file should be merged with the zephyr application. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-10-30 08:39:13 +01:00
COMMAND
${PYTHON_EXECUTABLE}
${ZEPHYR_BASE}/scripts/mergehex.py
cmake: fix incorrect lower case variable This patch fixes a bug where a incorrect lower case variable 'MERGED_HEX_NAME' resulted in the 'flash' target not getting the correct path to the hex file to flash. This since cmake/flash/CMakeLists.txt uses the variable ${MERGED_HEX_NAME}. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-12-05 09:32:32 +01:00
-o ${MERGED_HEX_NAME}
cmake: flash: scripts: Include externally built hex files Allow user to add externally built hex files to the cmake property HEX_FILES_TO_MERGE. The hex files in this list will be merged with the hex file generated when building the zephyr application. This allows users to leverage the application configuration available in Kconfig and CMake to help decide what hex file should be merged with the zephyr application. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-10-30 08:39:13 +01:00
${HEX_FILES_TO_MERGE}
DEPENDS ${HEX_FILES_TO_MERGE} ${logical_target_for_zephyr_elf}
)
cmake: fix incorrect lower case variable This patch fixes a bug where a incorrect lower case variable 'MERGED_HEX_NAME' resulted in the 'flash' target not getting the correct path to the hex file to flash. This since cmake/flash/CMakeLists.txt uses the variable ${MERGED_HEX_NAME}. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-12-05 09:32:32 +01:00
add_custom_target(mergehex ALL DEPENDS ${MERGED_HEX_NAME})
cmake: flash: Conditional dependency to 'mergehex' This patch adds a dependency from the 'flash' target to the 'mergehex' target IF files to be merged are configured. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-12-05 10:15:40 +01:00
list(APPEND FLASH_DEPS mergehex)
cmake: flash: scripts: Include externally built hex files Allow user to add externally built hex files to the cmake property HEX_FILES_TO_MERGE. The hex files in this list will be merged with the hex file generated when building the zephyr application. This allows users to leverage the application configuration available in Kconfig and CMake to help decide what hex file should be merged with the zephyr application. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-10-30 08:39:13 +01:00
endif()
ld: Introduce --print-memory-usage Pass the --print-memory-usage to the linker on the first link if the toolchain supports it. Don't use this option with the second link because seeing it twice could confuse users and using it on the second link would suppress it when the first link has a ram/flash-usage issue. Note that the memory regions are symbolic concepts defined by the linker scripts and do not necessarily map directly to the real physical address space. Take also note that some platforms do two passes of the linker so the results do not match exactly to the final elf file. See also rom_report, ram_report and https://sourceware.org/binutils/docs/ld/MEMORY.html This is particularly useful when the linker fails due to excessive flash/ram usage. When a section does not fit into a memory region the linker will exit with an error code and will state how big the overflow was. But it doesn't state what the memory region size is, or what memory regions exist, which is good to know when debugging overflow issues. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-19 13:20:10 +01:00
if(CONFIG_OUTPUT_PRINT_MEMORY_USAGE)
# Use --print-memory-usage with the first link.
#
# Don't use this option with the second link because seeing it twice
# could confuse users and using it on the second link would suppress
# it when the first link has a ram/flash-usage issue.
set(option ${LINKERFLAGPREFIX},--print-memory-usage)
string(MAKE_C_IDENTIFIER check${option} check)
cmake: Fix the -Wl,--print-memory-usage compatibility test -Wl,--print-memory-usage is a relatively new LD feature (2015) and is not supported by the espressif toolchain. Unfortunately the toolchain compatibility test was broken as it was not using the flag when linking. The root cause lies in how we test LD compatibility and this same fix must be applied again in e.g. target_ld_options(). This patch fixes https://github.com/zephyrproject-rtos/zephyr/issues/5458 Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-21 10:16:43 +01:00
cmake: Fix CMAKE_REQUIRED_FLAGS corruption The --print-memory-usage check was accidentally corrupting the CMAKE_REQUIRED_FLAGS variable due to a variable de-referencing bug. This was affecting app CMakeLists.txt code that was using CMAKE_REQUIRED_FLAGS. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-27 15:21:54 +01:00
set(SAVED_CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS})
cmake: Fix the -Wl,--print-memory-usage compatibility test -Wl,--print-memory-usage is a relatively new LD feature (2015) and is not supported by the espressif toolchain. Unfortunately the toolchain compatibility test was broken as it was not using the flag when linking. The root cause lies in how we test LD compatibility and this same fix must be applied again in e.g. target_ld_options(). This patch fixes https://github.com/zephyrproject-rtos/zephyr/issues/5458 Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-21 10:16:43 +01:00
set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} ${option}")
cmake: Port Zephyr to use zephyr_check_compiler_flag This commit ports nearly all usage of check_c_compiler_flag, check_cxx_compiler_flag, and check_compiler_flag to use zephyr_check_compiler_flag instead. This has a significant CMake configure-time performance impact. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-04-17 15:08:58 +02:00
zephyr_check_compiler_flag(C "" ${check})
cmake: Fix CMAKE_REQUIRED_FLAGS corruption The --print-memory-usage check was accidentally corrupting the CMAKE_REQUIRED_FLAGS variable due to a variable de-referencing bug. This was affecting app CMakeLists.txt code that was using CMAKE_REQUIRED_FLAGS. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-27 15:21:54 +01:00
set(CMAKE_REQUIRED_FLAGS ${SAVED_CMAKE_REQUIRED_FLAGS})
cmake: Fix the -Wl,--print-memory-usage compatibility test -Wl,--print-memory-usage is a relatively new LD feature (2015) and is not supported by the espressif toolchain. Unfortunately the toolchain compatibility test was broken as it was not using the flag when linking. The root cause lies in how we test LD compatibility and this same fix must be applied again in e.g. target_ld_options(). This patch fixes https://github.com/zephyrproject-rtos/zephyr/issues/5458 Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-21 10:16:43 +01:00
cmake: Use a variable for 'zephyr_prebuilt' There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:31:02 +01:00
target_link_libraries_ifdef(${check} ${ZEPHYR_PREBUILT_EXECUTABLE} ${option})
ld: Introduce --print-memory-usage Pass the --print-memory-usage to the linker on the first link if the toolchain supports it. Don't use this option with the second link because seeing it twice could confuse users and using it on the second link would suppress it when the first link has a ram/flash-usage issue. Note that the memory regions are symbolic concepts defined by the linker scripts and do not necessarily map directly to the real physical address space. Take also note that some platforms do two passes of the linker so the results do not match exactly to the final elf file. See also rom_report, ram_report and https://sourceware.org/binutils/docs/ld/MEMORY.html This is particularly useful when the linker fails due to excessive flash/ram usage. When a section does not fit into a memory region the linker will exit with an error code and will state how big the overflow was. But it doesn't state what the memory region size is, or what memory regions exist, which is good to know when debugging overflow issues. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-19 13:20:10 +01:00
endif()
cmake: support other emulation platforms/runners Right now we are hardcoded to only qemu, with the native port, we make this more generic and support this in a plugin mode where a running has its own cmake definitons implementing the various targets. Signed-off-by: Anas Nashif <anas.nashif@intel.com> Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
2017-11-22 00:54:55 +01:00
if(EMU_PLATFORM)
cmake: Use path-corrected version of ZEPHYR_BASE Instead of accessing the environment variable ZEPHYR_BASE every time we require accessing the source code root, use an intermediate variable that has OS path separators correctly set to '/' to avoid issues on Windows. Note: This removes the ZEPHYR_SOURCE_DIR CMake variable. External applications using that will need to change to use the new ZEPHYR_BASE variable. Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2018-01-11 15:46:44 +01:00
include(${ZEPHYR_BASE}/cmake/emu/${EMU_PLATFORM}.cmake)
cmake: cleanup qemu runner configuration All runner logic was implemented in qemu.cmake, remove the generic stuff and make qemu.cmake qemu specific. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-12-21 22:45:45 +01:00
else()
add_custom_target(run
COMMAND
${CMAKE_COMMAND} -E echo
"==================================================="
cmake: Whitespace and commentary fixes Cosmetics, no functional change expected. Fixed leading space alignment. Replaced tabs with spaces. Emulation error message output is now aligned. To locate tabs in cmake, the following bash is useful: grep -PRil "\t" * | grep -i cmake | grep -v ^sanity Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2018-12-19 10:40:57 +01:00
"Emulation/Simulation not supported with this board."
cmake: cleanup qemu runner configuration All runner logic was implemented in qemu.cmake, remove the generic stuff and make qemu.cmake qemu specific. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-12-21 22:45:45 +01:00
"==================================================="
)
cmake: support other emulation platforms/runners Right now we are hardcoded to only qemu, with the native port, we make this more generic and support this in a plugin mode where a running has its own cmake definitons implementing the various targets. Signed-off-by: Anas Nashif <anas.nashif@intel.com> Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
2017-11-22 00:54:55 +01:00
endif()
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
add_subdirectory(cmake/flash)
add_subdirectory(cmake/usage)
add_subdirectory(cmake/reports)
build: suppress asserts warning if forced off This was being incorrectly printed. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2018-05-24 22:18:36 +02:00
if(CONFIG_ASSERT AND (NOT CONFIG_FORCE_NO_ASSERT))
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
message(WARNING "
------------------------------------------------------------
--- WARNING: __ASSERT() statements are globally ENABLED ---
cmake: fix warning message This commit provides a minor fix to a CMake output text which warns the user that ASSERT() statements are enabled. Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
2018-05-31 11:05:12 +02:00
--- The kernel will run more slowly and use more memory ---
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
------------------------------------------------------------"
cmake: Whitespace and commentary fixes Cosmetics, no functional change expected. Fixed leading space alignment. Replaced tabs with spaces. Emulation error message output is now aligned. To locate tabs in cmake, the following bash is useful: grep -PRil "\t" * | grep -i cmake | grep -v ^sanity Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2018-12-19 10:40:57 +01:00
)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
endif()
if(CONFIG_BOARD_DEPRECATED)
message(WARNING "
WARNING: The board '${BOARD}' is deprecated and will be
removed in version ${CONFIG_BOARD_DEPRECATED}"
cmake: Whitespace and commentary fixes Cosmetics, no functional change expected. Fixed leading space alignment. Replaced tabs with spaces. Emulation error message output is now aligned. To locate tabs in cmake, the following bash is useful: grep -PRil "\t" * | grep -i cmake | grep -v ^sanity Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2018-12-19 10:40:57 +01:00
)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
endif()
build: warn user about Meltdown vulnerability A fix for this issue is in progress, meanwhile warn the user that they may be susceptible to this problem if they enable user mode on an x86-based target that is not known to be immune. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2018-01-12 18:54:24 +01:00
if(CONFIG_X86 AND CONFIG_USERSPACE AND NOT CONFIG_X86_NO_MELTDOWN)
message(WARNING "
WARNING: You have enabled CONFIG_USERSPACE on an x86-based target.
If your CPU is vulnerable to the Meltdown CPU bug, security of
supervisor-only memory pages is not guaranteed. This version of Zephyr
does not contain a fix for this issue."
cmake: Whitespace and commentary fixes Cosmetics, no functional change expected. Fixed leading space alignment. Replaced tabs with spaces. Emulation error message output is now aligned. To locate tabs in cmake, the following bash is useful: grep -PRil "\t" * | grep -i cmake | grep -v ^sanity Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2018-12-19 10:40:57 +01:00
)
build: warn user about Meltdown vulnerability A fix for this issue is in progress, meanwhile warn the user that they may be susceptible to this problem if they enable user mode on an x86-based target that is not known to be immune. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2018-01-12 18:54:24 +01:00
endif()
Reference in a new issue Copy permalink