michaelh/zephyr
1
0
Fork 0
Code Releases Activity
zephyr/include/linker/linker-defs.h

449 lines
13 KiB
C
Raw Normal View History

First commit Signed-off-by: <inaky.perez-gonzalez@intel.com>
2015-04-10 16:44:37 -07:00
/*
* Copyright (c) 2013-2014, Wind River Systems, Inc.
*
license: Replace Apache boilerplate with SPDX tag Replace the existing Apache 2.0 boilerplate header with an SPDX tag throughout the zephyr code tree. This patch was generated via a script run over the master branch. Also updated doc/porting/application.rst that had a dependency on line numbers in a literal include. Manually updated subsys/logging/sys_log.c that had a malformed header in the original file. Also cleanup several cases that already had a SPDX tag and we either got a duplicate or missed updating. Jira: ZEP-1457 Change-Id: I6131a1d4ee0e58f5b938300c2d2fc77d2e69572c Signed-off-by: David B. Kinder <david.b.kinder@intel.com> Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2017-01-18 17:01:01 -08:00
* SPDX-License-Identifier: Apache-2.0
First commit Signed-off-by: <inaky.perez-gonzalez@intel.com>
2015-04-10 16:44:37 -07:00
*/
/*
checkpatch: warning - block_comment_style Change-Id: I6da43e41f9c6efee577b70513ec368ae3cce0144 Signed-off-by: Dan Kalowsky <daniel.kalowsky@intel.com> Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2015-10-20 09:42:33 -07:00
* DESCRIPTION
* Platform independent, commonly used macros and defines related to linker
* script.
*
* This file may be included by:
* - Linker script files: for linker section declarations
* - C files: for external declaration of address or size of linker section
* - Assembly files: for external declaration of address or size of linker
* section
doxygen: change comment style to match javadoc The change replaces multiple asterisks to ** at the beginning of comments and adds a space before the asterisks at the beginning of lines. Change-Id: I7656bde3bf4d9a31e38941e43b580520432dabc1 Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2015-07-01 17:22:39 -04:00
*/
First commit Signed-off-by: <inaky.perez-gonzalez@intel.com>
2015-04-10 16:44:37 -07:00
headers: Fix headers across the project Any word started with underscore followed by and uppercase letter or a second underscore is a reserved word according with C99. Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
2018-09-14 10:43:44 -07:00
#ifndef ZEPHYR_INCLUDE_LINKER_LINKER_DEFS_H_
#define ZEPHYR_INCLUDE_LINKER_LINKER_DEFS_H_
First commit Signed-off-by: <inaky.perez-gonzalez@intel.com>
2015-04-10 16:44:37 -07:00
#include <toolchain.h>
linker: add iterable section macros For iterable areas defined with Z_STRUCT_SECTION_ITERABLE(), the corresponding output section in the linker script is just boilerplate. Add macros to make these definitions simpler. Unfortunately, we have a fair number of iterable sections not defined with Z_STRUCT_SECTION_ITERABLE(), this patch does not address this. The output sections are all named <struct name>_area, update sanitylib.py with this. sys_sem with no userspace, and k_lifo/k_fifo are special cases where different data types that are all equivalent need to be put in the same iterable area. Add Z_STRUCT_SECTION_ITERABLE_ALTERNATE() for this special case. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2020-05-23 14:38:39 -07:00
#include <toolchain/common.h>
linker: move all linker headers to include/linker Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-06-17 11:30:47 -04:00
#include <linker/sections.h>
cleanup: include/: move misc/util.h to sys/util.h move misc/util.h to sys/util.h and create a shim for backward-compatibility. No functional changes to the headers. A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES. Related to #16539 Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-06-26 10:33:55 -04:00
#include <sys/util.h>
ld: Put 'sizeof(struct device)' in the generated offsets header Rename _DEVICE_STRUCT_SIZE to _DEVICE_STRUCT_SIZEOF. This causes it to be picked by the script 'gen_offset_header.py' and inserted into the header file 'include/generated/offsets.h'. Renaming from x_SIZE to x_SIZEOF will align it's name with the other symbols that denote a sctruct's size, like K_THREAD_SIZEOF. Furthermore, it will allow the symbol to be accessed through a header file define, instead of only as an extern symbol. This is more flexible, and more aligned with the other symbols in offsets. Finally, if we are able to move all of offsets.c symbols into the offsets.h header file we be able to remove offsets.o from the link and thereby simplify the linking process. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-08-10 17:05:10 +02:00
#include <offsets.h>
First commit Signed-off-by: <inaky.perez-gonzalez@intel.com>
2015-04-10 16:44:37 -07:00
devicetree: remove DT_HAS_NODE_STATUS_OKAY Several reviewers agreed that DT_HAS_NODE_STATUS_OKAY(...) was an undesirable API for the following reasons: - it's inconsistent with the rest of the DT_NODE_HAS_FOO names - DT_NODE_HAS_FOO_BAR_BAZ(node) was agreed upon as a shorthand for macros which are equivalent to DT_NODE_HAS_FOO(node) && DT_NODE_HAS_BAR(node) && - DT_NODE_HAS_BAZ(node), and DT_HAS_NODE_STATUS_OKAY is an odd duck - DT_NODE_HAS_STATUS(..., okay) was viewed as more readable anyway - it is seen as a somewhat aesthetically challenged name Replace all users with DT_NODE_HAS_STATUS(..., okay), which is semantically equivalent. This is mostly done with sed, but a few remaining cases were done by hand, along with whitespace, docs, and comment changes. These special cases include the Nordic SOC static assert files. Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
2020-05-11 11:56:08 -07:00
/* We need to dummy out DT_NODE_HAS_STATUS when building the unittests.
* Including devicetree.h would require generating dummy header files
* to match what gen_defines creates, so it's easier to just dummy out
* DT_NODE_HAS_STATUS.
arm: Convert DT_DTCM_* to new devicetree.h macros Convert various DT_DTCM_* macros to use DT_CHOSEN(zephyr_dtcm) and associated macros from devicetree.h. Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2020-04-23 17:51:08 -05:00
*/
#ifdef ZTEST_UNITTEST
devicetree: remove DT_HAS_NODE_STATUS_OKAY Several reviewers agreed that DT_HAS_NODE_STATUS_OKAY(...) was an undesirable API for the following reasons: - it's inconsistent with the rest of the DT_NODE_HAS_FOO names - DT_NODE_HAS_FOO_BAR_BAZ(node) was agreed upon as a shorthand for macros which are equivalent to DT_NODE_HAS_FOO(node) && DT_NODE_HAS_BAR(node) && - DT_NODE_HAS_BAZ(node), and DT_HAS_NODE_STATUS_OKAY is an odd duck - DT_NODE_HAS_STATUS(..., okay) was viewed as more readable anyway - it is seen as a somewhat aesthetically challenged name Replace all users with DT_NODE_HAS_STATUS(..., okay), which is semantically equivalent. This is mostly done with sed, but a few remaining cases were done by hand, along with whitespace, docs, and comment changes. These special cases include the Nordic SOC static assert files. Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
2020-05-11 11:56:08 -07:00
#define DT_NODE_HAS_STATUS(node, status) 0
arm: Convert DT_DTCM_* to new devicetree.h macros Convert various DT_DTCM_* macros to use DT_CHOSEN(zephyr_dtcm) and associated macros from devicetree.h. Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2020-04-23 17:51:08 -05:00
#else
reserved-memory: Introduce support for reserved-memory node Introduce a set of header files to be able to define and declare sections and regions in the linker script. Introduce also DT helpers to retrieve data back. Signed-off-by: Carlo Caione <ccaione@baylibre.com>
2021-05-17 17:31:35 +02:00
#include <linker/devicetree_reserved.h>
arm: Convert DT_DTCM_* to new devicetree.h macros Convert various DT_DTCM_* macros to use DT_CHOSEN(zephyr_dtcm) and associated macros from devicetree.h. Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2020-04-23 17:51:08 -05:00
#include <devicetree.h>
#endif
First commit Signed-off-by: <inaky.perez-gonzalez@intel.com>
2015-04-10 16:44:37 -07:00
#ifdef _LINKER
doc: reference: add a page for iterable sections Group together the iterable section functions and add a corresponding documentation page. Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
2021-08-03 17:12:03 +01:00
/**
* @addtogroup iterable_section_apis
* @{
*/
linker: add iterable section macros For iterable areas defined with Z_STRUCT_SECTION_ITERABLE(), the corresponding output section in the linker script is just boilerplate. Add macros to make these definitions simpler. Unfortunately, we have a fair number of iterable sections not defined with Z_STRUCT_SECTION_ITERABLE(), this patch does not address this. The output sections are all named <struct name>_area, update sanitylib.py with this. sys_sem with no userspace, and k_lifo/k_fifo are special cases where different data types that are all equivalent need to be put in the same iterable area. Add Z_STRUCT_SECTION_ITERABLE_ALTERNATE() for this special case. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2020-05-23 14:38:39 -07:00
#define Z_LINK_ITERABLE(struct_type) \
_CONCAT(_##struct_type, _list_start) = .; \
linker: tweak section naming to feet all linkers MWDT toolchain adds additional suffix to sections name in case of ffunction-sections / fdata-sections are enabled. As proposed by Andy Ross let's pick a single set of rules and syntax that work. Suggested-by: Andy Ross <andy@plausible.org> Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
2020-09-02 16:52:09 +03:00
KEEP(*(SORT_BY_NAME(._##struct_type.static.*))); \
linker: add iterable section macros For iterable areas defined with Z_STRUCT_SECTION_ITERABLE(), the corresponding output section in the linker script is just boilerplate. Add macros to make these definitions simpler. Unfortunately, we have a fair number of iterable sections not defined with Z_STRUCT_SECTION_ITERABLE(), this patch does not address this. The output sections are all named <struct name>_area, update sanitylib.py with this. sys_sem with no userspace, and k_lifo/k_fifo are special cases where different data types that are all equivalent need to be put in the same iterable area. Add Z_STRUCT_SECTION_ITERABLE_ALTERNATE() for this special case. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2020-05-23 14:38:39 -07:00
_CONCAT(_##struct_type, _list_end) = .
linker: tweak link iterable with padding This adds a new Z_LINK_ITERABLE_ALIGNED option that includes alignment. Main reason is to avoid repeting ALIGN() calls for every iterable needed on ESP32 linker script. Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
2021-06-01 12:09:02 -03:00
#define Z_LINK_ITERABLE_ALIGNED(struct_type, align) \
. = ALIGN(align); \
Z_LINK_ITERABLE(struct_type);
linker: add macros so iterable sections can be garbage collected The iterable section macros Z_ITERABLE_SECTION_ROM()/_RAM() uses Z_LINK_ITERABLE() which does KEEP() on all symbols. This results in all symbols under those sections being kept in final image even though these symbols are not referred directly from the code. This adds the new set of macros which does not force KEEP() on the symbols, and allows symbols to be garbage collected. The existing macros are kept as-is so as not to change their behaviors. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2020-09-16 16:19:15 -07:00
#define Z_LINK_ITERABLE_GC_ALLOWED(struct_type) \
_CONCAT(_##struct_type, _list_start) = .; \
*(SORT_BY_NAME(._##struct_type.static.*)); \
_CONCAT(_##struct_type, _list_end) = .
toolchain: redefine iterable section APIs as non internal Redefine the APIs used to deal with iterable sections to an alias without the Z_ prefix, so that they can be used by Zephyr applications. Fix the associated comments so that they are handled correctly by Doxygen. Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
2021-08-03 18:24:28 +01:00
/**
* @brief Define a read-only iterable section output.
*
* @details
* Define an output section which will set up an iterable area
* of equally-sized data structures. For use with STRUCT_SECTION_ITERABLE().
linker: add iterable section macros For iterable areas defined with Z_STRUCT_SECTION_ITERABLE(), the corresponding output section in the linker script is just boilerplate. Add macros to make these definitions simpler. Unfortunately, we have a fair number of iterable sections not defined with Z_STRUCT_SECTION_ITERABLE(), this patch does not address this. The output sections are all named <struct name>_area, update sanitylib.py with this. sys_sem with no userspace, and k_lifo/k_fifo are special cases where different data types that are all equivalent need to be put in the same iterable area. Add Z_STRUCT_SECTION_ITERABLE_ALTERNATE() for this special case. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2020-05-23 14:38:39 -07:00
* Input sections will be sorted by name, per ld's SORT_BY_NAME.
*
* This macro should be used for read-only data.
linker: add macros so iterable sections can be garbage collected The iterable section macros Z_ITERABLE_SECTION_ROM()/_RAM() uses Z_LINK_ITERABLE() which does KEEP() on all symbols. This results in all symbols under those sections being kept in final image even though these symbols are not referred directly from the code. This adds the new set of macros which does not force KEEP() on the symbols, and allows symbols to be garbage collected. The existing macros are kept as-is so as not to change their behaviors. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2020-09-16 16:19:15 -07:00
*
* Note that this keeps the symbols in the image even though
* they are not being directly referenced. Use this when symbols
* are indirectly referenced by iterating through the section.
linker: add iterable section macros For iterable areas defined with Z_STRUCT_SECTION_ITERABLE(), the corresponding output section in the linker script is just boilerplate. Add macros to make these definitions simpler. Unfortunately, we have a fair number of iterable sections not defined with Z_STRUCT_SECTION_ITERABLE(), this patch does not address this. The output sections are all named <struct name>_area, update sanitylib.py with this. sys_sem with no userspace, and k_lifo/k_fifo are special cases where different data types that are all equivalent need to be put in the same iterable area. Add Z_STRUCT_SECTION_ITERABLE_ALTERNATE() for this special case. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2020-05-23 14:38:39 -07:00
*/
toolchain: redefine iterable section APIs as non internal Redefine the APIs used to deal with iterable sections to an alias without the Z_ prefix, so that they can be used by Zephyr applications. Fix the associated comments so that they are handled correctly by Doxygen. Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
2021-08-03 18:24:28 +01:00
#define ITERABLE_SECTION_ROM(struct_type, subalign) \
linker: add iterable section macros For iterable areas defined with Z_STRUCT_SECTION_ITERABLE(), the corresponding output section in the linker script is just boilerplate. Add macros to make these definitions simpler. Unfortunately, we have a fair number of iterable sections not defined with Z_STRUCT_SECTION_ITERABLE(), this patch does not address this. The output sections are all named <struct name>_area, update sanitylib.py with this. sys_sem with no userspace, and k_lifo/k_fifo are special cases where different data types that are all equivalent need to be put in the same iterable area. Add Z_STRUCT_SECTION_ITERABLE_ALTERNATE() for this special case. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2020-05-23 14:38:39 -07:00
SECTION_PROLOGUE(struct_type##_area,,SUBALIGN(subalign)) \
{ \
Z_LINK_ITERABLE(struct_type); \
linker-tool-gcc: revise for MMU support We need to do a few things differently if we are to support a virtual memory map, i.e. CONFIG_MMU where CONFIG_KERNEL_VM_BASE is not the same as CONFIG_SRAM_BASE_ADDRESS. - All sections must be specified with a VMA and LMA, where VMA is the virtual address and LMA is the physical memory location. - All sections must be specified with ALIGN_WITH_INPUT to keep VMAs and LMAs synchronized To do this, the existing linker macros need some adjustment: - GROUP_LINK_IN undefined when CONFIG_KERNEL_VM_BASE is not the same as CONFIG_SRAM_BASE_ADDRESS. - New macro GROUP_ROM_LINK_IN for text/rodata sections - New macro GROUP_NOLOAD_LINK_IN for bss/noinit sections - Implicit ALIGN_WITH_INPUT for all sections GROUP_FOLLOWS_AT is unused anywhere in the kernel for years now and has been removed. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com> Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2021-03-06 17:44:44 -08:00
} GROUP_ROM_LINK_IN(RAMABLE_REGION, ROMABLE_REGION)
linker: add iterable section macros For iterable areas defined with Z_STRUCT_SECTION_ITERABLE(), the corresponding output section in the linker script is just boilerplate. Add macros to make these definitions simpler. Unfortunately, we have a fair number of iterable sections not defined with Z_STRUCT_SECTION_ITERABLE(), this patch does not address this. The output sections are all named <struct name>_area, update sanitylib.py with this. sys_sem with no userspace, and k_lifo/k_fifo are special cases where different data types that are all equivalent need to be put in the same iterable area. Add Z_STRUCT_SECTION_ITERABLE_ALTERNATE() for this special case. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2020-05-23 14:38:39 -07:00
toolchain: deprecate the Z_ iterables api Switch the actual API implementation to the external API and mark the internal ones as __DEPRECATED_MACRO. Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
2021-08-04 19:28:46 +01:00
#define Z_ITERABLE_SECTION_ROM(struct_type, subalign) \
ITERABLE_SECTION_ROM(struct_type, subalign)
toolchain: redefine iterable section APIs as non internal Redefine the APIs used to deal with iterable sections to an alias without the Z_ prefix, so that they can be used by Zephyr applications. Fix the associated comments so that they are handled correctly by Doxygen. Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
2021-08-03 18:24:28 +01:00
/**
* @brief Define a garbage collectable read-only iterable section output.
*
* @details
* Define an output section which will set up an iterable area
* of equally-sized data structures. For use with STRUCT_SECTION_ITERABLE().
linker: add macros so iterable sections can be garbage collected The iterable section macros Z_ITERABLE_SECTION_ROM()/_RAM() uses Z_LINK_ITERABLE() which does KEEP() on all symbols. This results in all symbols under those sections being kept in final image even though these symbols are not referred directly from the code. This adds the new set of macros which does not force KEEP() on the symbols, and allows symbols to be garbage collected. The existing macros are kept as-is so as not to change their behaviors. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2020-09-16 16:19:15 -07:00
* Input sections will be sorted by name, per ld's SORT_BY_NAME.
*
* This macro should be used for read-only data.
*
* Note that the symbols within the section can be garbage collected.
*/
toolchain: redefine iterable section APIs as non internal Redefine the APIs used to deal with iterable sections to an alias without the Z_ prefix, so that they can be used by Zephyr applications. Fix the associated comments so that they are handled correctly by Doxygen. Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
2021-08-03 18:24:28 +01:00
#define ITERABLE_SECTION_ROM_GC_ALLOWED(struct_type, subalign) \
linker: add macros so iterable sections can be garbage collected The iterable section macros Z_ITERABLE_SECTION_ROM()/_RAM() uses Z_LINK_ITERABLE() which does KEEP() on all symbols. This results in all symbols under those sections being kept in final image even though these symbols are not referred directly from the code. This adds the new set of macros which does not force KEEP() on the symbols, and allows symbols to be garbage collected. The existing macros are kept as-is so as not to change their behaviors. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2020-09-16 16:19:15 -07:00
SECTION_PROLOGUE(struct_type##_area,,SUBALIGN(subalign)) \
{ \
Z_LINK_ITERABLE_GC_ALLOWED(struct_type); \
} GROUP_LINK_IN(ROMABLE_REGION)
toolchain: deprecate the Z_ iterables api Switch the actual API implementation to the external API and mark the internal ones as __DEPRECATED_MACRO. Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
2021-08-04 19:28:46 +01:00
#define Z_ITERABLE_SECTION_ROM_GC_ALLOWED(struct_type, subalign) \
ITERABLE_SECTION_ROM_GC_ALLOWED(struct_type, subalign)
toolchain: redefine iterable section APIs as non internal Redefine the APIs used to deal with iterable sections to an alias without the Z_ prefix, so that they can be used by Zephyr applications. Fix the associated comments so that they are handled correctly by Doxygen. Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
2021-08-03 18:24:28 +01:00
/**
* @brief Define a read-write iterable section output.
*
* @details
* Define an output section which will set up an iterable area
* of equally-sized data structures. For use with STRUCT_SECTION_ITERABLE().
linker: add iterable section macros For iterable areas defined with Z_STRUCT_SECTION_ITERABLE(), the corresponding output section in the linker script is just boilerplate. Add macros to make these definitions simpler. Unfortunately, we have a fair number of iterable sections not defined with Z_STRUCT_SECTION_ITERABLE(), this patch does not address this. The output sections are all named <struct name>_area, update sanitylib.py with this. sys_sem with no userspace, and k_lifo/k_fifo are special cases where different data types that are all equivalent need to be put in the same iterable area. Add Z_STRUCT_SECTION_ITERABLE_ALTERNATE() for this special case. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2020-05-23 14:38:39 -07:00
* Input sections will be sorted by name, per ld's SORT_BY_NAME.
*
* This macro should be used for read-write data that is modified at runtime.
linker: add macros so iterable sections can be garbage collected The iterable section macros Z_ITERABLE_SECTION_ROM()/_RAM() uses Z_LINK_ITERABLE() which does KEEP() on all symbols. This results in all symbols under those sections being kept in final image even though these symbols are not referred directly from the code. This adds the new set of macros which does not force KEEP() on the symbols, and allows symbols to be garbage collected. The existing macros are kept as-is so as not to change their behaviors. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2020-09-16 16:19:15 -07:00
*
* Note that this keeps the symbols in the image even though
* they are not being directly referenced. Use this when symbols
* are indirectly referenced by iterating through the section.
linker: add iterable section macros For iterable areas defined with Z_STRUCT_SECTION_ITERABLE(), the corresponding output section in the linker script is just boilerplate. Add macros to make these definitions simpler. Unfortunately, we have a fair number of iterable sections not defined with Z_STRUCT_SECTION_ITERABLE(), this patch does not address this. The output sections are all named <struct name>_area, update sanitylib.py with this. sys_sem with no userspace, and k_lifo/k_fifo are special cases where different data types that are all equivalent need to be put in the same iterable area. Add Z_STRUCT_SECTION_ITERABLE_ALTERNATE() for this special case. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2020-05-23 14:38:39 -07:00
*/
toolchain: redefine iterable section APIs as non internal Redefine the APIs used to deal with iterable sections to an alias without the Z_ prefix, so that they can be used by Zephyr applications. Fix the associated comments so that they are handled correctly by Doxygen. Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
2021-08-03 18:24:28 +01:00
#define ITERABLE_SECTION_RAM(struct_type, subalign) \
linker: add iterable section macros For iterable areas defined with Z_STRUCT_SECTION_ITERABLE(), the corresponding output section in the linker script is just boilerplate. Add macros to make these definitions simpler. Unfortunately, we have a fair number of iterable sections not defined with Z_STRUCT_SECTION_ITERABLE(), this patch does not address this. The output sections are all named <struct name>_area, update sanitylib.py with this. sys_sem with no userspace, and k_lifo/k_fifo are special cases where different data types that are all equivalent need to be put in the same iterable area. Add Z_STRUCT_SECTION_ITERABLE_ALTERNATE() for this special case. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2020-05-23 14:38:39 -07:00
SECTION_DATA_PROLOGUE(struct_type##_area,,SUBALIGN(subalign)) \
{ \
Z_LINK_ITERABLE(struct_type); \
} GROUP_DATA_LINK_IN(RAMABLE_REGION, ROMABLE_REGION)
toolchain: deprecate the Z_ iterables api Switch the actual API implementation to the external API and mark the internal ones as __DEPRECATED_MACRO. Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
2021-08-04 19:28:46 +01:00
#define Z_ITERABLE_SECTION_RAM(struct_type, subalign) \
ITERABLE_SECTION_RAM(struct_type, subalign)
linker: add macros so iterable sections can be garbage collected The iterable section macros Z_ITERABLE_SECTION_ROM()/_RAM() uses Z_LINK_ITERABLE() which does KEEP() on all symbols. This results in all symbols under those sections being kept in final image even though these symbols are not referred directly from the code. This adds the new set of macros which does not force KEEP() on the symbols, and allows symbols to be garbage collected. The existing macros are kept as-is so as not to change their behaviors. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2020-09-16 16:19:15 -07:00
toolchain: redefine iterable section APIs as non internal Redefine the APIs used to deal with iterable sections to an alias without the Z_ prefix, so that they can be used by Zephyr applications. Fix the associated comments so that they are handled correctly by Doxygen. Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
2021-08-03 18:24:28 +01:00
/**
* @brief Define a garbage collectable read-write iterable section output.
*
* @details
* Define an output section which will set up an iterable area
* of equally-sized data structures. For use with STRUCT_SECTION_ITERABLE().
linker: add macros so iterable sections can be garbage collected The iterable section macros Z_ITERABLE_SECTION_ROM()/_RAM() uses Z_LINK_ITERABLE() which does KEEP() on all symbols. This results in all symbols under those sections being kept in final image even though these symbols are not referred directly from the code. This adds the new set of macros which does not force KEEP() on the symbols, and allows symbols to be garbage collected. The existing macros are kept as-is so as not to change their behaviors. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2020-09-16 16:19:15 -07:00
* Input sections will be sorted by name, per ld's SORT_BY_NAME.
*
* This macro should be used for read-write data that is modified at runtime.
*
* Note that the symbols within the section can be garbage collected.
*/
toolchain: redefine iterable section APIs as non internal Redefine the APIs used to deal with iterable sections to an alias without the Z_ prefix, so that they can be used by Zephyr applications. Fix the associated comments so that they are handled correctly by Doxygen. Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
2021-08-03 18:24:28 +01:00
#define ITERABLE_SECTION_RAM_GC_ALLOWED(struct_type, subalign) \
linker: add macros so iterable sections can be garbage collected The iterable section macros Z_ITERABLE_SECTION_ROM()/_RAM() uses Z_LINK_ITERABLE() which does KEEP() on all symbols. This results in all symbols under those sections being kept in final image even though these symbols are not referred directly from the code. This adds the new set of macros which does not force KEEP() on the symbols, and allows symbols to be garbage collected. The existing macros are kept as-is so as not to change their behaviors. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2020-09-16 16:19:15 -07:00
SECTION_DATA_PROLOGUE(struct_type##_area,,SUBALIGN(subalign)) \
{ \
Z_LINK_ITERABLE_GC_ALLOWED(struct_type); \
} GROUP_DATA_LINK_IN(RAMABLE_REGION, ROMABLE_REGION)
toolchain: deprecate the Z_ iterables api Switch the actual API implementation to the external API and mark the internal ones as __DEPRECATED_MACRO. Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
2021-08-04 19:28:46 +01:00
#define Z_ITERABLE_SECTION_RAM_GC_ALLOWED(struct_type, subalign) \
ITERABLE_SECTION_RAM_GC_ALLOWED(struct_type, subalign)
doc: reference: add a page for iterable sections Group together the iterable section functions and add a corresponding documentation page. Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
2021-08-03 17:12:03 +01:00
/**
* @}
*/ /* end of struct_section_apis */
init: Support fine-grained device initialization priorities Introduces the SYS_DEFINE_DEVICE() macro, which supports 5 distinct levels of device initialization and 100 priorities within each level. Note: The existing init macros (e.g. nano_early_init()) have been adapted to utilize the enhanced initialization model, but will eventually be retired. Change-Id: If677029d8b711a3fae9b2f32b5470cd97d19aeda Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
2015-10-14 11:17:20 -04:00
/*
device: Refactor device structures When the device driver model got introduced, there were no concept of SYS_INIT() which can be seen as software service. These were introduced afterwards and reusing the device infrastructure for simplicity. However, it meant to allocate a bit too much for something that only required an initialization function to be called at right time. Thus refactoring the devices structures relevantly: - introducing struct init_entry which is a generic init end-point - struct deviceconfig is removed and struct device owns everything now. - SYS_INIT() generates only a struct init_entry via calling INIT_ENTRY_DEFINE() - DEVICE_AND_API_INIT() generates a struct device and calls INIT_ENTRY_DEFINE() - init objects sections are in ROM - device objects sections are in RAM (but will end up in ROM once they will be 'constified') It also generate a tiny memory gain on both ROM and RAM, which is nice. Perhaps kernel/device.c could be renamed to something more relevant. Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2020-03-09 11:02:20 +01:00
* generate a symbol to mark the start of the objects array for
* the specified object and level, then link all of those objects
* (sorted by priority). Ensure the objects aren't discarded if there is
* no direct reference to them
init: Support fine-grained device initialization priorities Introduces the SYS_DEFINE_DEVICE() macro, which supports 5 distinct levels of device initialization and 100 priorities within each level. Note: The existing init macros (e.g. nano_early_init()) have been adapted to utilize the enhanced initialization model, but will eventually be retired. Change-Id: If677029d8b711a3fae9b2f32b5470cd97d19aeda Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
2015-10-14 11:17:20 -04:00
*/
device: Refactor device structures When the device driver model got introduced, there were no concept of SYS_INIT() which can be seen as software service. These were introduced afterwards and reusing the device infrastructure for simplicity. However, it meant to allocate a bit too much for something that only required an initialization function to be called at right time. Thus refactoring the devices structures relevantly: - introducing struct init_entry which is a generic init end-point - struct deviceconfig is removed and struct device owns everything now. - SYS_INIT() generates only a struct init_entry via calling INIT_ENTRY_DEFINE() - DEVICE_AND_API_INIT() generates a struct device and calls INIT_ENTRY_DEFINE() - init objects sections are in ROM - device objects sections are in RAM (but will end up in ROM once they will be 'constified') It also generate a tiny memory gain on both ROM and RAM, which is nice. Perhaps kernel/device.c could be renamed to something more relevant. Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2020-03-09 11:02:20 +01:00
#define CREATE_OBJ_LEVEL(object, level) \
__##object##_##level##_start = .; \
init: tweak Zephyr .init* section name conflicting with toolchain In case of ARC MWDT toolchain and C++ support enabled the Zephyr .init* section conflicts with .init* sections derived from toolchain libs. Let's add 'z_' prefix to Zephyr .init* section (and therefore .device section as they share the same macros) to make Zephyr section name unique. Signed-off-by: Evgeniy Paltsev <PaltsevEvgeniy@gmail.com>
2021-04-23 15:55:53 +03:00
KEEP(*(SORT(.z_##object##_##level[0-9]_*))); \
KEEP(*(SORT(.z_##object##_##level[1-9][0-9]_*)));
console: shell: Support multiple modules Ability to use Zephyr shell by multiple modules simultaneously, each module for its own usage. Old shell implementation enabled the user to call only one module commands, not all of the modules simultaneously. Change-Id: I0ef8fa2fd190b7490c44fe91d1016363258302c9 Signed-off-by: Yael Avramovich <yael.avramovich@intel.com> Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2016-07-31 16:16:29 +03:00
logging: subsystem major redesign Adding new implementation of logging subsystem. New features includes: support for multiple backends, improving performance by deferring log processing to the known context, adding timestamps and logs filtering options (compile time, runtime, module level, instance level). Console backend added as the example backend. Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
2018-05-16 08:50:33 +02:00
/*
* link in shell initialization objects for all modules that use shell and
* their shell commands are automatically initialized by the kernel.
*/
First commit Signed-off-by: <inaky.perez-gonzalez@intel.com>
2015-04-10 16:44:37 -07:00
#elif defined(_ASMLANGUAGE)
init: Support fine-grained device initialization priorities Introduces the SYS_DEFINE_DEVICE() macro, which supports 5 distinct levels of device initialization and 100 priorities within each level. Note: The existing init macros (e.g. nano_early_init()) have been adapted to utilize the enhanced initialization model, but will eventually be retired. Change-Id: If677029d8b711a3fae9b2f32b5470cd97d19aeda Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
2015-10-14 11:17:20 -04:00
First commit Signed-off-by: <inaky.perez-gonzalez@intel.com>
2015-04-10 16:44:37 -07:00
/* Assembly FILES: declaration defined by the linker script */
GDATA(__bss_start)
GDATA(__bss_num_words)
#ifdef CONFIG_XIP
linker: align __data_ram/rom_start/end linker symbol names Cleanup and preparation commit for linker script generator. Zephyr linker scripts provides start and end symbols for each section, and sometimes even size and LMA start symbols. Generally, start and end symbols uses the following pattern, as: Section name: foo Section start symbol: __foo_start Section end symbol: __foo_end However, this pattern is not followed consistently. To allow for linker script generation and ensure consistent naming of symbols then the following pattern is introduced consistently to allow for cleaner linker script generation. Section name: foo Section start symbol: __foo_start Section end symbol: __foo_end Section size symbol: __foo_size Section LMA start symbol: __foo_load_start This commit aligns the symbols for _data_ram/rom to other symbols and in such a way they follow consistent pattern which allows for linker script and scatter file generation. The symbols are named according to the section name they describe. Section name is `data` A new group named data_region is introduced which instead spans all the input and output sections that was previously covered by __data_ram_start, __data_ram_end, and __data_rom_start. The following symbols are aligned in this commit: - __data_ram_start -> __data_region_start - __data_ram_end -> __data_region_end - __data_rom_start -> __data_region_load_start The following new symbols are introduced so that the data section is aligned with other sections: - __data_end - __data_start value identical to __data_region_start but describes start of the section. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2021-05-21 21:21:52 +02:00
GDATA(__data_region_load_start)
GDATA(__data_region_start)
GDATA(__data_region_num_words)
First commit Signed-off-by: <inaky.perez-gonzalez@intel.com>
2015-04-10 16:44:37 -07:00
#endif
init: Support fine-grained device initialization priorities Introduces the SYS_DEFINE_DEVICE() macro, which supports 5 distinct levels of device initialization and 100 priorities within each level. Note: The existing init macros (e.g. nano_early_init()) have been adapted to utilize the enhanced initialization model, but will eventually be retired. Change-Id: If677029d8b711a3fae9b2f32b5470cd97d19aeda Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
2015-10-14 11:17:20 -04:00
#else /* ! _ASMLANGUAGE */
First commit Signed-off-by: <inaky.perez-gonzalez@intel.com>
2015-04-10 16:44:37 -07:00
Introduce new sized integer typedefs This is a start to move away from the C99 {u}int{8,16,32,64}_t types to Zephyr defined u{8,16,32,64}_t and s{8,16,32,64}_t. This allows Zephyr to define the sized types in a consistent manor across all the architectures we support and not conflict with what various compilers and libc might do with regards to the C99 types. We introduce <zephyr/types.h> as part of this and have it include <stdint.h> for now until we transition all the code away from the C99 types. We go with u{8,16,32,64}_t and s{8,16,32,64}_t as there are some existing variables defined u8 & u16 as well as to be consistent with Zephyr naming conventions. Jira: ZEP-2051 Change-Id: I451fed0623b029d65866622e478225dfab2c0ca8 Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2017-04-19 10:32:08 -05:00
#include <zephyr/types.h>
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 10:14:02 -04:00
/*
include: linker: improve documentation of app shared mem symbols This commit adds minor improvements to the documentation of the linker symbols related to Application Shared Memory. Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
2018-11-06 11:46:05 +01:00
* Memory owned by the kernel, to be used as shared memory between
* application threads.
*
* The following are extern symbols from the linker. This enables
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 10:14:02 -04:00
* the dynamic k_mem_domain and k_mem_partition creation and alignment
* to the section produced in the linker.
include: linker: improve documentation of app shared mem symbols This commit adds minor improvements to the documentation of the linker symbols related to Application Shared Memory. Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
2018-11-06 11:46:05 +01:00
* The policy for this memory will be to initially configure all of it as
* kernel / supervisor thread accessible.
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 10:14:02 -04:00
*/
extern char _app_smem_start[];
extern char _app_smem_end[];
extern char _app_smem_size[];
extern char _app_smem_rom_start[];
x86: fix app shared memory if XIP enabled This is a separate data section which needs to be copied into RAM. Most arches just use the kernel's _data_copy(), but x86 has its own optimized copying code. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com> Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2018-12-20 15:34:04 +05:30
extern char _app_smem_num_words[];
linker-defs.h: add some comments Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2017-06-14 13:31:11 -07:00
kernel: app_smem: allowing pinning memory partitions This allows memory partitions to be put into the pinned section so they are available during boot. For example, the stack guard (in libc partition) is needed during boot but before the paging mechanism is initialized. Without pinning it in physical memory, it would fault in early boot process. A new cmake property app_smem,pinned_partitions is introduced so that additional partitions can be pinned if needed. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2021-07-12 13:33:32 -07:00
#ifdef CONFIG_LINKER_USE_PINNED_SECTION
extern char _app_smem_pinned_start[];
extern char _app_smem_pinned_end[];
extern char _app_smem_pinned_size[];
extern char _app_smem_pinned_num_words[];
#endif
linker-defs: add size values for kernel/app memory These can be computed from start/end values, but such arithmetic can't be done when populating at build time struct member values. Some documentation has been added to explain exactly what these symbols mean. It is intended for application RAM to come first, then followed by kernel RAM and then all unclaimed memory (also considered kernel RAM). Obsolete _image_ram_all[] removed. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2017-08-01 15:13:44 -07:00
/* Memory owned by the kernel. Start and end will be aligned for memory
include: linker: improve documentation of app shared mem symbols This commit adds minor improvements to the documentation of the linker symbols related to Application Shared Memory. Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
2018-11-06 11:46:05 +01:00
* management/protection hardware for the target architecture.
linker-defs: add size values for kernel/app memory These can be computed from start/end values, but such arithmetic can't be done when populating at build time struct member values. Some documentation has been added to explain exactly what these symbols mean. It is intended for application RAM to come first, then followed by kernel RAM and then all unclaimed memory (also considered kernel RAM). Obsolete _image_ram_all[] removed. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2017-08-01 15:13:44 -07:00
*
* Consists of all kernel-side globals, all kernel objects, all thread stacks,
userspace: remove APPLICATION_MEMORY feature This was never a long-term solution, more of a gross hack to get test cases working until we could figure out a good end-to-end solution for memory domains that generated appropriate linker sections. Now that we have this with the app shared memory feature, and have converted all tests to remove it, delete this feature. To date all userspace APIs have been tagged as 'experimental' which sidesteps deprecation policies. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2019-01-31 15:53:24 -08:00
* and all currently unused RAM.
linker-defs: add size values for kernel/app memory These can be computed from start/end values, but such arithmetic can't be done when populating at build time struct member values. Some documentation has been added to explain exactly what these symbols mean. It is intended for application RAM to come first, then followed by kernel RAM and then all unclaimed memory (also considered kernel RAM). Obsolete _image_ram_all[] removed. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2017-08-01 15:13:44 -07:00
*
* Except for the stack of the currently executing thread, none of this memory
* is normally accessible to user threads unless specifically granted at
* runtime.
*/
kernel: add early init routines for app RAM Applications will have their own BSS and data sections which will need to be additionally copied. This covers the common C implementation of these functions. Arches which implement their own optimized versions will need to be updated. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2017-06-19 11:13:19 -07:00
extern char __kernel_ram_start[];
extern char __kernel_ram_end[];
linker-defs: add size values for kernel/app memory These can be computed from start/end values, but such arithmetic can't be done when populating at build time struct member values. Some documentation has been added to explain exactly what these symbols mean. It is intended for application RAM to come first, then followed by kernel RAM and then all unclaimed memory (also considered kernel RAM). Obsolete _image_ram_all[] removed. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2017-08-01 15:13:44 -07:00
extern char __kernel_ram_size[];
kernel: add early init routines for app RAM Applications will have their own BSS and data sections which will need to be additionally copied. This covers the common C implementation of these functions. Arches which implement their own optimized versions will need to be updated. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2017-06-19 11:13:19 -07:00
all: Update reserved function names Update reserved function names starting with one underscore, replacing them as follows: '_k_' with 'z_' '_K_' with 'Z_' '_handler_' with 'z_handl_' '_Cstart' with 'z_cstart' '_Swap' with 'z_swap' This renaming is done on both global and those static function names in kernel/include and include/. Other static function names in kernel/ are renamed by removing the leading underscore. Other function names not starting with any prefix listed above are renamed starting with a 'z_' or 'Z_' prefix. Function names starting with two or three leading underscores are not automatcally renamed since these names will collide with the variants with two or three leading underscores. Various generator scripts have also been updated as well as perf, linker and usb files. These are drivers/serial/uart_handlers.c include/linker/kobject-text.ld kernel/include/syscall_handler.h scripts/gen_kobject_list.py scripts/gen_syscall_header.py Signed-off-by: Patrik Flykt <patrik.flykt@intel.com>
2019-03-08 14:19:05 -07:00
/* Used by z_bss_zero or arch-specific implementation */
First commit Signed-off-by: <inaky.perez-gonzalez@intel.com>
2015-04-10 16:44:37 -07:00
extern char __bss_start[];
nios2: support more global pointer scenarios We now allow use of -mgpopt=global and -mgpopt=data. The 'global' option is now the default instead of compiler-default local, expanding global pointer usage to all small data in the system. For systems where all RAM is less than 64K, the 'data' option may be appropriate. Some fixes had to be made to the system in order to get around some issues: * prep_c.c no longer uses fake linker variables to figure out the size of data or BSS, as these gave the linker fits as it tried to compute relative addresses to them. * _k_task_ptr_idle is create by sysgen and placed in a special section. Any small data in a special section needs to be declared extern with __attribute__((section)) else the compiler will assume it's in .sdata. * same situation with extern references to k_pipe_t (fixed pipe_priv test) For legacy applications being ported to Nios II which do things that freak out global pointer calculation, it can be disabled entirely. Change-Id: I5eb86ee8aefb8e2fac49c5cdd104ee19cea23f6f Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2016-06-30 16:45:08 -07:00
extern char __bss_end[];
linker-defs.h: add some comments Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2017-06-14 13:31:11 -07:00
all: Update reserved function names Update reserved function names starting with one underscore, replacing them as follows: '_k_' with 'z_' '_K_' with 'Z_' '_handler_' with 'z_handl_' '_Cstart' with 'z_cstart' '_Swap' with 'z_swap' This renaming is done on both global and those static function names in kernel/include and include/. Other static function names in kernel/ are renamed by removing the leading underscore. Other function names not starting with any prefix listed above are renamed starting with a 'z_' or 'Z_' prefix. Function names starting with two or three leading underscores are not automatcally renamed since these names will collide with the variants with two or three leading underscores. Various generator scripts have also been updated as well as perf, linker and usb files. These are drivers/serial/uart_handlers.c include/linker/kobject-text.ld kernel/include/syscall_handler.h scripts/gen_kobject_list.py scripts/gen_syscall_header.py Signed-off-by: Patrik Flykt <patrik.flykt@intel.com>
2019-03-08 14:19:05 -07:00
/* Used by z_data_copy() or arch-specific implementation */
First commit Signed-off-by: <inaky.perez-gonzalez@intel.com>
2015-04-10 16:44:37 -07:00
#ifdef CONFIG_XIP
linker: align __data_ram/rom_start/end linker symbol names Cleanup and preparation commit for linker script generator. Zephyr linker scripts provides start and end symbols for each section, and sometimes even size and LMA start symbols. Generally, start and end symbols uses the following pattern, as: Section name: foo Section start symbol: __foo_start Section end symbol: __foo_end However, this pattern is not followed consistently. To allow for linker script generation and ensure consistent naming of symbols then the following pattern is introduced consistently to allow for cleaner linker script generation. Section name: foo Section start symbol: __foo_start Section end symbol: __foo_end Section size symbol: __foo_size Section LMA start symbol: __foo_load_start This commit aligns the symbols for _data_ram/rom to other symbols and in such a way they follow consistent pattern which allows for linker script and scatter file generation. The symbols are named according to the section name they describe. Section name is `data` A new group named data_region is introduced which instead spans all the input and output sections that was previously covered by __data_ram_start, __data_ram_end, and __data_rom_start. The following symbols are aligned in this commit: - __data_ram_start -> __data_region_start - __data_ram_end -> __data_region_end - __data_rom_start -> __data_region_load_start The following new symbols are introduced so that the data section is aligned with other sections: - __data_end - __data_start value identical to __data_region_start but describes start of the section. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2021-05-21 21:21:52 +02:00
extern char __data_region_load_start[];
extern char __data_region_start[];
extern char __data_region_end[];
kernel: add early init routines for app RAM Applications will have their own BSS and data sections which will need to be additionally copied. This covers the common C implementation of these functions. Arches which implement their own optimized versions will need to be updated. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2017-06-19 11:13:19 -07:00
#endif /* CONFIG_XIP */
First commit Signed-off-by: <inaky.perez-gonzalez@intel.com>
2015-04-10 16:44:37 -07:00
linker-defs: add syms for kernel image bounds These are needed on MMU systems and define where the kernel image resides in virtual memory at boot so that it may be memory-mapped. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2020-12-10 12:33:12 -08:00
#ifdef CONFIG_MMU
/* Virtual addresses of page-aligned kernel image mapped into RAM at boot */
extern char z_mapped_start[];
extern char z_mapped_end[];
#endif /* CONFIG_MMU */
linker-defs: add some new _image_* defines 1) start/end addresses for rodata 2) size of image ROM area 3) size of RAM (not including rodata/text) up to the limit of physical memory Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2017-07-11 08:58:43 -07:00
/* Includes text and rodata */
linker: align _image_rodata and _image_rom start/end/size linker symbols Cleanup and preparation commit for linker script generator. Zephyr linker scripts provides start and end symbols for each larger areas in the linker script. The symbols _image_rom_start and _image_rom_end corresponds to the group ROMABLE_REGION defined in the ld linker scripts. The symbols _image_rodata_start and _image_rodata_end is not placed as independent group but covers common-rom.ld, thread-local-storage.ld, kobject-rom.ld and snippets-rodata.ld. This commit align those names and prepares for generation of groups in linker scripts. The symbols describing the ROMABLE_REGION will be renamed to: _image_rom_start -> __rom_region_start _image_rom_end -> __rom_region_end The rodata will also use the group symbol notation as: _image_rodata_start -> __rodata_region_start _image_rodata_end -> __rodata_region_end Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2021-08-09 18:16:51 +02:00
extern char __rom_region_start[];
extern char __rom_region_end[];
extern char __rom_region_size[];
linker-defs: add some new _image_* defines 1) start/end addresses for rodata 2) size of image ROM area 3) size of RAM (not including rodata/text) up to the limit of physical memory Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2017-07-11 08:58:43 -07:00
arch: arm: Add symbol for flash used Add symbol which contains the number of bytes contained in the image. Using '_image_rom_end' will not work, as there are symbols loaded after its value. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-11-29 12:12:19 +00:00
/* Includes all ROMable data, i.e. the size of the output image file. */
extern char _flash_used[];
linker-defs: add some new _image_* defines 1) start/end addresses for rodata 2) size of image ROM area 3) size of RAM (not including rodata/text) up to the limit of physical memory Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2017-07-11 08:58:43 -07:00
/* datas, bss, noinit */
linker scripts: add symbols for ROM/RAM boundaries These symbols have more meaningful names when trying to figure out where the ROM/RAM starts/ends, rather than relying on e.g. __data_rom_start for the end of the ROM (__data_rom_start is the beginning of the data in ROM, thus is not part of the image). Change-Id: I4aa0354ee414fd0d46d0f40952e091ba090e7bce Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
2015-09-16 19:14:40 -04:00
extern char _image_ram_start[];
extern char _image_ram_end[];
linker-defs: add some new _image_* defines 1) start/end addresses for rodata 2) size of image ROM area 3) size of RAM (not including rodata/text) up to the limit of physical memory Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2017-07-11 08:58:43 -07:00
linker: align _image_text_start/end/size linker symbols name Cleanup and preparation commit for linker script generator. Zephyr linker scripts provides start and end symbols for each larger areas in the linker script. The symbols _image_text_start and _image_text_end sometimes includes linker/kobject-text.ld. This mean there must be both the regular __text_start and __text_end symbols for the pure text section, as well as <group>_start and <group>_end symbols. The symbols describing the text region which covers more than just the text section itself will thus be changed to: _image_text_start -> __text_region_start _image_text_end -> __text_region_end Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2021-08-09 21:24:02 +02:00
extern char __text_region_start[];
extern char __text_region_end[];
extern char __text_region_size[];
linker scripts: add symbols for ROM/RAM boundaries These symbols have more meaningful names when trying to figure out where the ROM/RAM starts/ends, rather than relying on e.g. __data_rom_start for the end of the ROM (__data_rom_start is the beginning of the data in ROM, thus is not part of the image). Change-Id: I4aa0354ee414fd0d46d0f40952e091ba090e7bce Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
2015-09-16 19:14:40 -04:00
linker: align _image_rodata and _image_rom start/end/size linker symbols Cleanup and preparation commit for linker script generator. Zephyr linker scripts provides start and end symbols for each larger areas in the linker script. The symbols _image_rom_start and _image_rom_end corresponds to the group ROMABLE_REGION defined in the ld linker scripts. The symbols _image_rodata_start and _image_rodata_end is not placed as independent group but covers common-rom.ld, thread-local-storage.ld, kobject-rom.ld and snippets-rodata.ld. This commit align those names and prepares for generation of groups in linker scripts. The symbols describing the ROMABLE_REGION will be renamed to: _image_rom_start -> __rom_region_start _image_rom_end -> __rom_region_end The rodata will also use the group symbol notation as: _image_rodata_start -> __rodata_region_start _image_rodata_end -> __rodata_region_end Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2021-08-09 18:16:51 +02:00
extern char __rodata_region_start[];
extern char __rodata_region_end[];
extern char __rodata_region_size[];
linker-defs: add some new _image_* defines 1) start/end addresses for rodata 2) size of image ROM area 3) size of RAM (not including rodata/text) up to the limit of physical memory Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2017-07-11 08:58:43 -07:00
arm: armv6-m: Support relocating vector table An abnormal crash was encountered in ARMv6-M SoCs that don't have flash starting at 0. With Zephyr OS the reason for this crash is that, on ARMv6-M the system requires an exception vector table at the 0 address. We implement the relocate_vector_table function to move the vector table code to address 0 on systems which don't have the start of code already at 0. [kumar.gala: reworderd commit message, tweaked how we check if we need to copy vector table] Signed-off-by: Xiaorui Hu <xiaorui.hu@linaro.org> Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2017-06-23 11:02:50 +08:00
extern char _vector_start[];
extern char _vector_end[];
reserved-memory: Introduce support for reserved-memory node Introduce a set of header files to be able to define and declare sections and regions in the linker script. Introduce also DT helpers to retrieve data back. Signed-off-by: Carlo Caione <ccaione@baylibre.com>
2021-05-17 17:31:35 +02:00
#if DT_NODE_HAS_STATUS(_NODE_RESERVED, okay)
DT_RESERVED_MEM_SYMBOLS()
#endif
arch/arm/aarch32: add IRQ relay mechanism to ARMv7/8-M This patch allows the `SW_VECTOR_RELAY` and `SW_VECTOR_RELAY_CLIENT` pair to be enabled on the ARMv7-M and ARMv8-M architectures and covers all additional interrupt vectors. Signed-off-by: Rafał Kuźnia <rafal.kuznia@nordicsemi.no> Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
2020-05-13 14:01:55 +02:00
#ifdef CONFIG_SW_VECTOR_RELAY
extern char __vector_relay_table[];
#endif
Gcov: Added linker changes needed by Gcov. This patch adds all the required hooks needed in the linker script. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-08-31 15:09:26 +05:30
#ifdef CONFIG_COVERAGE_GCOV
extern char __gcov_bss_start[];
extern char __gcov_bss_end[];
extern char __gcov_bss_size[];
#endif /* CONFIG_COVERAGE_GCOV */
linker-defs.h: add some comments Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2017-06-14 13:31:11 -07:00
/* end address of image, used by newlib for the heap */
First commit Signed-off-by: <inaky.perez-gonzalez@intel.com>
2015-04-10 16:44:37 -07:00
extern char _end[];
devicetree: remove DT_HAS_NODE_STATUS_OKAY Several reviewers agreed that DT_HAS_NODE_STATUS_OKAY(...) was an undesirable API for the following reasons: - it's inconsistent with the rest of the DT_NODE_HAS_FOO names - DT_NODE_HAS_FOO_BAR_BAZ(node) was agreed upon as a shorthand for macros which are equivalent to DT_NODE_HAS_FOO(node) && DT_NODE_HAS_BAR(node) && - DT_NODE_HAS_BAZ(node), and DT_HAS_NODE_STATUS_OKAY is an odd duck - DT_NODE_HAS_STATUS(..., okay) was viewed as more readable anyway - it is seen as a somewhat aesthetically challenged name Replace all users with DT_NODE_HAS_STATUS(..., okay), which is semantically equivalent. This is mostly done with sed, but a few remaining cases were done by hand, along with whitespace, docs, and comment changes. These special cases include the Nordic SOC static assert files. Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
2020-05-11 11:56:08 -07:00
#if DT_NODE_HAS_STATUS(DT_CHOSEN(zephyr_ccm), okay)
linker: arm: add stm32 ccm sections The STM32 has special Core Coupled Memory, ccm for short, that can only be accessed through the CPU and can not be use for DMA. The following 3 sections have been added. - ccm_bss for zero initialized data - ccm_data for initialized data - ccm_noinit for uninitialized data Signed-off-by: Erwin Rol <erwin@erwinrol.com>
2017-10-05 01:20:21 +02:00
extern char __ccm_data_rom_start[];
extern char __ccm_start[];
extern char __ccm_data_start[];
extern char __ccm_data_end[];
extern char __ccm_bss_start[];
extern char __ccm_bss_end[];
extern char __ccm_noinit_start[];
extern char __ccm_noinit_end[];
extern char __ccm_end[];
arm: Convert DT_CCM_* to new devicetree.h macros Convert various DT_CCM_* macros to use DT_CHOSEN(zephyr_ccm) and associated macros from devicetree.h. We remove CCM references from cortex_a and cortex_r linker scripts as its only a feature on Cortex-M STM32 SoCs. Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2020-04-23 17:55:58 -05:00
#endif
linker: arm: add stm32 ccm sections The STM32 has special Core Coupled Memory, ccm for short, that can only be accessed through the CPU and can not be use for DMA. The following 3 sections have been added. - ccm_bss for zero initialized data - ccm_data for initialized data - ccm_noinit for uninitialized data Signed-off-by: Erwin Rol <erwin@erwinrol.com>
2017-10-05 01:20:21 +02:00
linker: arm: Add cortex_m itcm section Adds a linker section for Cortex-M instruction tightly coupled memory (ITCM), similar to the existing section for DTCM. A new executable MPU region is not added as there isn't currently a need to make this section accessible to user mode. This section can be enabled by setting a device tree chosen node zephyr,itcm. Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
2021-01-06 08:52:28 -06:00
#if DT_NODE_HAS_STATUS(DT_CHOSEN(zephyr_itcm), okay)
extern char __itcm_start[];
extern char __itcm_end[];
extern char __itcm_size[];
extern char __itcm_rom_start[];
#endif
devicetree: remove DT_HAS_NODE_STATUS_OKAY Several reviewers agreed that DT_HAS_NODE_STATUS_OKAY(...) was an undesirable API for the following reasons: - it's inconsistent with the rest of the DT_NODE_HAS_FOO names - DT_NODE_HAS_FOO_BAR_BAZ(node) was agreed upon as a shorthand for macros which are equivalent to DT_NODE_HAS_FOO(node) && DT_NODE_HAS_BAR(node) && - DT_NODE_HAS_BAZ(node), and DT_HAS_NODE_STATUS_OKAY is an odd duck - DT_NODE_HAS_STATUS(..., okay) was viewed as more readable anyway - it is seen as a somewhat aesthetically challenged name Replace all users with DT_NODE_HAS_STATUS(..., okay), which is semantically equivalent. This is mostly done with sed, but a few remaining cases were done by hand, along with whitespace, docs, and comment changes. These special cases include the Nordic SOC static assert files. Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
2020-05-11 11:56:08 -07:00
#if DT_NODE_HAS_STATUS(DT_CHOSEN(zephyr_dtcm), okay)
linker: Add dtcm section for Cortex M7 MCUs This commit adds a DTCM (Device Tightly Coupled Memory) section for Cortex F7 MCUs. The Address and length is defined in the corresponding device tree file. Signed-off-by: Alexander Wachter <alexander.wachter@student.tugraz.at>
2019-07-03 14:19:29 +02:00
extern char __dtcm_data_start[];
extern char __dtcm_data_end[];
extern char __dtcm_bss_start[];
extern char __dtcm_bss_end[];
extern char __dtcm_noinit_start[];
extern char __dtcm_noinit_end[];
extern char __dtcm_data_rom_start[];
extern char __dtcm_start[];
extern char __dtcm_end[];
arm: Convert DT_DTCM_* to new devicetree.h macros Convert various DT_DTCM_* macros to use DT_CHOSEN(zephyr_dtcm) and associated macros from devicetree.h. Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2020-04-23 17:51:08 -05:00
#endif
linker: Add dtcm section for Cortex M7 MCUs This commit adds a DTCM (Device Tightly Coupled Memory) section for Cortex F7 MCUs. The Address and length is defined in the corresponding device tree file. Signed-off-by: Alexander Wachter <alexander.wachter@student.tugraz.at>
2019-07-03 14:19:29 +02:00
arch: arm: add option to define an NSC region This commit adds K-config options that allow the user to signify an ARM Secure Firmware that contains Secure Entry functions and to define the starting address of the linker section that will contain the Secure Entry functions. It also instructs the linker to append the NSC section if instructed so by the user. Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
2018-04-03 09:39:43 +02:00
/* Used by the Security Attribution Unit to configure the
* Non-Secure Callable region.
*/
#ifdef CONFIG_ARM_FIRMWARE_HAS_SECURE_ENTRY_FUNCS
extern char __sg_start[];
extern char __sg_end[];
extern char __sg_size[];
#endif /* CONFIG_ARM_FIRMWARE_HAS_SECURE_ENTRY_FUNCS */
kernel: Add a "nocache" read-write memory section Add a "nocache" read-write memory section that is configured to not be cached. This memory section can be used to perform DMA transfers when cache coherence issues are not optimal or can not be solved using cache maintenance operations. This is currently only supported on ARM Cortex M7 with MPU. Fixes #2927 Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2018-11-07 23:40:43 +01:00
/*
* Non-cached kernel memory region, currently only available on ARM Cortex-M7
* with a MPU. Start and end will be aligned for memory management/protection
* hardware for the target architecture.
*
* All the functions with '__nocache' keyword will be placed into this
* section.
*/
#ifdef CONFIG_NOCACHE_MEMORY
extern char _nocache_ram_start[];
extern char _nocache_ram_end[];
extern char _nocache_ram_size[];
#endif /* CONFIG_NOCACHE_MEMORY */
linker: arm: add stm32 ccm sections The STM32 has special Core Coupled Memory, ccm for short, that can only be accessed through the CPU and can not be use for DMA. The following 3 sections have been added. - ccm_bss for zero initialized data - ccm_data for initialized data - ccm_noinit for uninitialized data Signed-off-by: Erwin Rol <erwin@erwinrol.com>
2017-10-05 01:20:21 +02:00
arm: Placing the functions which holds __ramfunc into '.ramfunc' Using __ramfunc to places a function in RAM instead of Flash. Code that for example reprograms flash at runtime can't execute from flash, in that case must placing code into RAM. This commit create a new section named '.ramfunc' in link scripts, all functions has __ramfunc keyword saved in thats sections and will load from flash to sram after the system booted. Fixes: #10253 Signed-off-by: qianfan Zhao <qianfanguijin@163.com>
2018-09-27 14:14:17 +08:00
/* Memory owned by the kernel. Start and end will be aligned for memory
* management/protection hardware for the target architecture.
*
* All the functions with '__ramfunc' keyword will be placed into this
arch: make __ramfunc support transparent Instead of having to enable ramfunc support manually, just make it transparently available to users, keeping the MPU region disabled if not used to not waste a MPU region. This however wastes 24 bytes of code area when the MPU is disabled and 48 bytes when it is enabled, and probably a dozen of CPU cycles during boot. I believe it is something acceptable. Note that when XIP is used, code is already in RAM, so the __ramfunc keyword does nothing, but does not generate an error. Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2019-02-10 11:05:51 +01:00
* section, stored in RAM instead of FLASH.
arm: Placing the functions which holds __ramfunc into '.ramfunc' Using __ramfunc to places a function in RAM instead of Flash. Code that for example reprograms flash at runtime can't execute from flash, in that case must placing code into RAM. This commit create a new section named '.ramfunc' in link scripts, all functions has __ramfunc keyword saved in thats sections and will load from flash to sram after the system booted. Fixes: #10253 Signed-off-by: qianfan Zhao <qianfanguijin@163.com>
2018-09-27 14:14:17 +08:00
*/
arch: make __ramfunc support transparent Instead of having to enable ramfunc support manually, just make it transparently available to users, keeping the MPU region disabled if not used to not waste a MPU region. This however wastes 24 bytes of code area when the MPU is disabled and 48 bytes when it is enabled, and probably a dozen of CPU cycles during boot. I believe it is something acceptable. Note that when XIP is used, code is already in RAM, so the __ramfunc keyword does nothing, but does not generate an error. Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2019-02-10 11:05:51 +01:00
#ifdef CONFIG_ARCH_HAS_RAMFUNC_SUPPORT
linker: align _ramfunc_ram/rom_start/size linker symbol names Cleanup and preparation commit for linker script generator. Zephyr linker scripts provides start and end symbols for each section, and sometimes even size and LMA start symbols. Generally, start and end symbols uses the following pattern, as: Section name: foo Section start symbol: __foo_start Section end symbol: __foo_end However, this pattern is not followed consistently. To allow for linker script generation and ensure consistent naming of symbols then the following pattern is introduced consistently to allow for cleaner linker script generation. Section name: foo Section start symbol: __foo_start Section end symbol: __foo_end Section size symbol: __foo_size Section LMA start symbol: __foo_load_start This commit aligns the symbols for _ramfunc_ram/rom to other symbols and in such a way they follow consistent pattern which allows for linker script and scatter file generation. The symbols are named according to the section name they describe. Section name is `ramfunc` The following symbols are aligned in this commit: - _ramfunc_ram_start -> __ramfunc_start - _ramfunc_ram_end -> __ramfunc_end - _ramfunc_ram_size -> __ramfunc_size - _ramfunc_rom_start -> __ramfunc_load_start Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2021-05-21 21:29:59 +02:00
extern char __ramfunc_start[];
extern char __ramfunc_end[];
extern char __ramfunc_size[];
extern char __ramfunc_load_start[];
arch: make __ramfunc support transparent Instead of having to enable ramfunc support manually, just make it transparently available to users, keeping the MPU region disabled if not used to not waste a MPU region. This however wastes 24 bytes of code area when the MPU is disabled and 48 bytes when it is enabled, and probably a dozen of CPU cycles during boot. I believe it is something acceptable. Note that when XIP is used, code is already in RAM, so the __ramfunc keyword does nothing, but does not generate an error. Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2019-02-10 11:05:51 +01:00
#endif /* CONFIG_ARCH_HAS_RAMFUNC_SUPPORT */
arm: Placing the functions which holds __ramfunc into '.ramfunc' Using __ramfunc to places a function in RAM instead of Flash. Code that for example reprograms flash at runtime can't execute from flash, in that case must placing code into RAM. This commit create a new section named '.ramfunc' in link scripts, all functions has __ramfunc keyword saved in thats sections and will load from flash to sram after the system booted. Fixes: #10253 Signed-off-by: qianfan Zhao <qianfanguijin@163.com>
2018-09-27 14:14:17 +08:00
arch: arm: expose start/end limits of the thread priv stack section We introduce linker symbols to hold the start and end address of the memory area holding the thread privilege stack buffers, applicable when building with support for User Mode. Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
2019-06-14 09:08:11 +02:00
/* Memory owned by the kernel. Memory region for thread privilege stack buffers,
* currently only applicable on ARM Cortex-M architecture when building with
* support for User Mode.
*
* All thread privilege stack buffers will be placed into this section.
*/
#ifdef CONFIG_USERSPACE
extern char z_priv_stacks_ram_start[];
extern char z_priv_stacks_ram_end[];
kernel: introduce supervisor-only stacks These stacks are appropriate for threads that run purely in supervisor mode, and also as stacks for interrupt and exception handling. Two new arch defines are introduced: - ARCH_KERNEL_STACK_GUARD_SIZE - ARCH_KERNEL_STACK_OBJ_ALIGN New public declaration macros: - K_KERNEL_STACK_RESERVED - K_KERNEL_STACK_EXTERN - K_KERNEL_STACK_DEFINE - K_KERNEL_STACK_ARRAY_DEFINE - K_KERNEL_STACK_MEMBER - K_KERNEL_STACK_SIZEOF If user mode is not enabled, K_KERNEL_STACK_* and K_THREAD_STACK_* are equivalent. Separately generated privilege elevation stacks are now declared like kernel stacks, removing the need for K_PRIVILEGE_STACK_ALIGN. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2020-04-24 16:24:46 -07:00
extern char z_user_stacks_start[];
extern char z_user_stacks_end[];
mmu: ensure gperf data is mapped Page tables created at build time may not include the gperf data at the very end of RAM. Ensure this is mapped properly at runtime to work around this. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2020-12-18 15:18:04 -08:00
extern char z_kobject_data_begin[];
arch: arm: expose start/end limits of the thread priv stack section We introduce linker symbols to hold the start and end address of the memory area holding the thread privilege stack buffers, applicable when building with support for User Mode. Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
2019-06-14 09:08:11 +02:00
#endif /* CONFIG_USERSPACE */
linker: add linker sections for thread local storage This adds the tdata and tbss sections required for thread local storage. They are in ROM area as these sections are not to be directly accessed, but copied to thread local storage area at thread creation. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2020-09-25 13:10:00 -07:00
#ifdef CONFIG_THREAD_LOCAL_STORAGE
extern char __tdata_start[];
extern char __tdata_end[];
extern char __tdata_size[];
kernel: tls: align tdata/tbss sections in stack This lets the linker tell us what kind of alignment is required for both tdata and tbss data when copying them into stack. If they are not aligned as expected by the toolchain, generated code would be accessing incorrect location for thread variables. Fixes #32015 Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2021-02-04 20:05:45 -08:00
extern char __tdata_align[];
linker: add linker sections for thread local storage This adds the tdata and tbss sections required for thread local storage. They are in ROM area as these sections are not to be directly accessed, but copied to thread local storage area at thread creation. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2020-09-25 13:10:00 -07:00
extern char __tbss_start[];
extern char __tbss_end[];
extern char __tbss_size[];
kernel: tls: align tdata/tbss sections in stack This lets the linker tell us what kind of alignment is required for both tdata and tbss data when copying them into stack. If they are not aligned as expected by the toolchain, generated code would be accessing incorrect location for thread variables. Fixes #32015 Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2021-02-04 20:05:45 -08:00
extern char __tbss_align[];
linker: add linker sections for thread local storage This adds the tdata and tbss sections required for thread local storage. They are in ROM area as these sections are not to be directly accessed, but copied to thread local storage area at thread creation. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2020-09-25 13:10:00 -07:00
extern char __tls_start[];
extern char __tls_end[];
extern char __tls_size[];
#endif /* CONFIG_THREAD_LOCAL_STORAGE */
linker: add bits for boot regions This adds the necessary bits for linker scripts and source code to specify which symbols are needed for boot process so they can be grouped together. One use of this is to group boot related code and data so these won't interval with other kernel and application for better caching. This is a must for demand paging as some functions and data must be available during the boot process and before the memory manager is initialized. During this time, paging cannot be used so symbols linked in virtual memory space are unavailable. This is up to the arch/SoC/board to define the sections in their linker scripts as section may need special alignment which cannot be done in common script snippets. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2021-02-24 10:18:34 -08:00
#ifdef CONFIG_LINKER_USE_BOOT_SECTION
/* lnkr_boot_start[] and lnkr_boot_end[]
* must encapsulate all the boot sections.
*/
extern char lnkr_boot_start[];
extern char lnkr_boot_end[];
extern char lnkr_boot_text_start[];
extern char lnkr_boot_text_end[];
extern char lnkr_boot_text_size[];
extern char lnkr_boot_data_start[];
extern char lnkr_boot_data_end[];
extern char lnkr_boot_data_size[];
extern char lnkr_boot_rodata_start[];
extern char lnkr_boot_rodata_end[];
extern char lnkr_boot_rodata_size[];
extern char lnkr_boot_bss_start[];
extern char lnkr_boot_bss_end[];
extern char lnkr_boot_bss_size[];
extern char lnkr_boot_noinit_start[];
extern char lnkr_boot_noinit_end[];
extern char lnkr_boot_noinit_size[];
#endif /* CONFIG_LINKER_USE_BOOT_SECTION */
linker: add bits for pinned regions This adds the necessary bits for linker scripts and source code to specify which symbols need to be pinned in memory. This is needed for demand paging as some functions and data must reside in memory all the time and cannot be paged out (e.g. paging, scheduler, and interrupt routines for functionality). This is up to the arch/SoC/board to define the sections in their linker scripts as the pinned section may need special alignment which cannot be done in common script snippets. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2021-02-23 13:33:38 -08:00
#ifdef CONFIG_LINKER_USE_PINNED_SECTION
/* lnkr_pinned_start[] and lnkr_pinned_end[] must encapsulate
* all the pinned sections as these are used by
* the MMU code to mark the physical page frames with
* Z_PAGE_FRAME_PINNED.
*/
extern char lnkr_pinned_start[];
extern char lnkr_pinned_end[];
extern char lnkr_pinned_text_start[];
extern char lnkr_pinned_text_end[];
extern char lnkr_pinned_text_size[];
extern char lnkr_pinned_data_start[];
extern char lnkr_pinned_data_end[];
extern char lnkr_pinned_data_size[];
extern char lnkr_pinned_rodata_start[];
extern char lnkr_pinned_rodata_end[];
extern char lnkr_pinned_rodata_size[];
extern char lnkr_pinned_bss_start[];
extern char lnkr_pinned_bss_end[];
extern char lnkr_pinned_bss_size[];
extern char lnkr_pinned_noinit_start[];
extern char lnkr_pinned_noinit_end[];
extern char lnkr_pinned_noinit_size[];
linker: helper functions to test if pointer/region is pinned This adds two helper functions to test if a pointer or a region resides in the pinned region. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2021-08-03 13:49:25 -07:00
__pinned_func
static inline bool lnkr_is_pinned(uint8_t *addr)
{
if ((addr >= (uint8_t *)lnkr_pinned_start) &&
(addr < (uint8_t *)lnkr_pinned_end)) {
return true;
} else {
return false;
}
}
__pinned_func
static inline bool lnkr_is_region_pinned(uint8_t *addr, size_t sz)
{
if ((addr >= (uint8_t *)lnkr_pinned_start) &&
((addr + sz) < (uint8_t *)lnkr_pinned_end)) {
return true;
} else {
return false;
}
}
linker: add bits for pinned regions This adds the necessary bits for linker scripts and source code to specify which symbols need to be pinned in memory. This is needed for demand paging as some functions and data must reside in memory all the time and cannot be paged out (e.g. paging, scheduler, and interrupt routines for functionality). This is up to the arch/SoC/board to define the sections in their linker scripts as the pinned section may need special alignment which cannot be done in common script snippets. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2021-02-23 13:33:38 -08:00
#endif /* CONFIG_LINKER_USE_PINNED_SECTION */
First commit Signed-off-by: <inaky.perez-gonzalez@intel.com>
2015-04-10 16:44:37 -07:00
#endif /* ! _ASMLANGUAGE */
headers: Fix headers across the project Any word started with underscore followed by and uppercase letter or a second underscore is a reserved word according with C99. Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
2018-09-14 10:43:44 -07:00
#endif /* ZEPHYR_INCLUDE_LINKER_LINKER_DEFS_H_ */
Copy permalink