OrgZephyr/zephyr
OrgZephyr
/
zephyr
mirror of https://github.com/zephyrproject-rtos/zephyr.git
1
0
Fork 0
Code Issues Releases Wiki Activity
zephyr/samples/application_development/code_relocation_nocopy/linker_arm_nocopy.ld

46 lines
1.0 KiB
Plaintext
Raw Normal View History

code_relocation: Add NOCOPY feature * Use case of interest: Some platforms are shipping in parallel to the internal FLASH some other storage / external FLASH (usually a QSPI FLASH) that can be used to execute (XIP) code from. The content of this external FLASH can usually be written at flash time using proper tools (see for example the case of the external FLASH on the nRF5340DK that can be written at flash time using nrfjprog). The external FLASH is a nice addition that is extremely useful when a large application code doesn't entirely fit on the internal FLASH so that we could want to move part of it in the auxiliary FLASH to XIP the code from there. * The problem: Right now Zephyr doesn't have a formal and generic way to move at build time part of the code to a different memory region. * The current status: Zephyr is indeed shipping a code_relocation feature but that doesn't entirely match our needs. When XIP is enabled, the code_relocation feature is used in Zephyr to move the selected code (that is to copy text section, to initialize data and zero bss) from FLASH to SRAM at run time and execute code from SRAM. The relocation is done by a generated snippet of code that is memcpy()-ing the right content to the destination region also using some build-time generated portions of linker script to retrieve start and destination addresses and regions. * This patch: This patch is leveraging the code_relocation code and adding a NOCOPY feature. This feature is using the code_relocation feature to dynamically build the linker script snippets but entirely skipping the run-time code relocation so that the code can be XIP-ed from the destination region. * Example: Let's say that we have a big file called `huge_file.c` that we want to XIP from the external FLASH that is mapped in an EXTFLASH region. In this case we should enable `CONFIG_XIP` and `CONFIG_CODE_DATA_RELOCATION` and instruct cmake as follows: zephyr_code_relocate(src/huge_file.c EXTFLASH_TEXT NOCOPY) zephyr_code_relocate(src/huge_file.c SRAM_DATA) this means that: - The .text section of the `huge_file.c` must reside in the EXTFLASH memory region and we do not need to copy the section there because we are going to XIP it (and we assume that the file is going to be placed in the external FLASH at flash time). - The .data section of the `huge_file.c` must still reside in the SRAM memory region. * TODOs: It's desirable to have the possibility to relocate libraries and pre-build files instead of source code files. Signed-off-by: Carlo Caione <ccaione@baylibre.com>
2022-02-16 04:18:50 +08:00
/*
* Copyright (c) 2022 Carlo Caione <ccaione@baylibre.com>
*
* SPDX-License-Identifier: Apache-2.0
*/
/**
* @file
* @brief Linker command/script file
*
* Linker script for the Cortex-M platforms.
*/
linker: update files with <zephyr/...> include prefix Linker files were not migrated with the new <zephyr/...> prefix. Note that the conversion has been scripted, refer to #45388 for more details. Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-05-09 19:20:58 +08:00
#include <zephyr/linker/sections.h>
#include <zephyr/devicetree.h>
code_relocation: Add NOCOPY feature * Use case of interest: Some platforms are shipping in parallel to the internal FLASH some other storage / external FLASH (usually a QSPI FLASH) that can be used to execute (XIP) code from. The content of this external FLASH can usually be written at flash time using proper tools (see for example the case of the external FLASH on the nRF5340DK that can be written at flash time using nrfjprog). The external FLASH is a nice addition that is extremely useful when a large application code doesn't entirely fit on the internal FLASH so that we could want to move part of it in the auxiliary FLASH to XIP the code from there. * The problem: Right now Zephyr doesn't have a formal and generic way to move at build time part of the code to a different memory region. * The current status: Zephyr is indeed shipping a code_relocation feature but that doesn't entirely match our needs. When XIP is enabled, the code_relocation feature is used in Zephyr to move the selected code (that is to copy text section, to initialize data and zero bss) from FLASH to SRAM at run time and execute code from SRAM. The relocation is done by a generated snippet of code that is memcpy()-ing the right content to the destination region also using some build-time generated portions of linker script to retrieve start and destination addresses and regions. * This patch: This patch is leveraging the code_relocation code and adding a NOCOPY feature. This feature is using the code_relocation feature to dynamically build the linker script snippets but entirely skipping the run-time code relocation so that the code can be XIP-ed from the destination region. * Example: Let's say that we have a big file called `huge_file.c` that we want to XIP from the external FLASH that is mapped in an EXTFLASH region. In this case we should enable `CONFIG_XIP` and `CONFIG_CODE_DATA_RELOCATION` and instruct cmake as follows: zephyr_code_relocate(src/huge_file.c EXTFLASH_TEXT NOCOPY) zephyr_code_relocate(src/huge_file.c SRAM_DATA) this means that: - The .text section of the `huge_file.c` must reside in the EXTFLASH memory region and we do not need to copy the section there because we are going to XIP it (and we assume that the file is going to be placed in the external FLASH at flash time). - The .data section of the `huge_file.c` must still reside in the SRAM memory region. * TODOs: It's desirable to have the possibility to relocate libraries and pre-build files instead of source code files. Signed-off-by: Carlo Caione <ccaione@baylibre.com>
2022-02-16 04:18:50 +08:00
linker: update files with <zephyr/...> include prefix Linker files were not migrated with the new <zephyr/...> prefix. Note that the conversion has been scripted, refer to #45388 for more details. Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-05-09 19:20:58 +08:00
#include <zephyr/linker/linker-defs.h>
#include <zephyr/linker/linker-tool.h>
code_relocation: Add NOCOPY feature * Use case of interest: Some platforms are shipping in parallel to the internal FLASH some other storage / external FLASH (usually a QSPI FLASH) that can be used to execute (XIP) code from. The content of this external FLASH can usually be written at flash time using proper tools (see for example the case of the external FLASH on the nRF5340DK that can be written at flash time using nrfjprog). The external FLASH is a nice addition that is extremely useful when a large application code doesn't entirely fit on the internal FLASH so that we could want to move part of it in the auxiliary FLASH to XIP the code from there. * The problem: Right now Zephyr doesn't have a formal and generic way to move at build time part of the code to a different memory region. * The current status: Zephyr is indeed shipping a code_relocation feature but that doesn't entirely match our needs. When XIP is enabled, the code_relocation feature is used in Zephyr to move the selected code (that is to copy text section, to initialize data and zero bss) from FLASH to SRAM at run time and execute code from SRAM. The relocation is done by a generated snippet of code that is memcpy()-ing the right content to the destination region also using some build-time generated portions of linker script to retrieve start and destination addresses and regions. * This patch: This patch is leveraging the code_relocation code and adding a NOCOPY feature. This feature is using the code_relocation feature to dynamically build the linker script snippets but entirely skipping the run-time code relocation so that the code can be XIP-ed from the destination region. * Example: Let's say that we have a big file called `huge_file.c` that we want to XIP from the external FLASH that is mapped in an EXTFLASH region. In this case we should enable `CONFIG_XIP` and `CONFIG_CODE_DATA_RELOCATION` and instruct cmake as follows: zephyr_code_relocate(src/huge_file.c EXTFLASH_TEXT NOCOPY) zephyr_code_relocate(src/huge_file.c SRAM_DATA) this means that: - The .text section of the `huge_file.c` must reside in the EXTFLASH memory region and we do not need to copy the section there because we are going to XIP it (and we assume that the file is going to be placed in the external FLASH at flash time). - The .data section of the `huge_file.c` must still reside in the SRAM memory region. * TODOs: It's desirable to have the possibility to relocate libraries and pre-build files instead of source code files. Signed-off-by: Carlo Caione <ccaione@baylibre.com>
2022-02-16 04:18:50 +08:00
samples: code_relocation_nocopy: Make linker script more generic Instead of depending on the nRF5340 DK, use a path specific to just the nRF5340 SoC and get the size of the external flash in this case from devicetree so that the sample could be easily run on other boards based on the nRF5340 SoC (after just adding proper overlays). On the occasion, correct the attributes of the EXTFLASH memory region. Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-09-13 18:39:02 +08:00
#if defined(CONFIG_NORDIC_QSPI_NOR) && defined(CONFIG_SOC_NRF5340_CPUAPP)
code_relocation: Extend the nocopy sample to nRF5340dk The nRF5340dk is shipping an external QSPI flash that can be used to do XIP from. Extend the code_relocation nocopy sample to support this platform so that part of the functions are executed from internal flash and others from external flash. Signed-off-by: Carlo Caione <ccaione@baylibre.com>
2022-02-17 20:04:00 +08:00
samples: code_relocation_nocopy: Make linker script more generic Instead of depending on the nRF5340 DK, use a path specific to just the nRF5340 SoC and get the size of the external flash in this case from devicetree so that the sample could be easily run on other boards based on the nRF5340 SoC (after just adding proper overlays). On the occasion, correct the attributes of the EXTFLASH memory region. Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-09-13 18:39:02 +08:00
/* On nRF5340, external flash is mapped in XIP region at 0x1000_0000. */
#define EXTFLASH_NODE DT_INST(0, nordic_qspi_nor)
#define EXTFLASH_ADDR 0x10000000
#define EXTFLASH_SIZE DT_PROP_OR(EXTFLASH_NODE, size_in_bytes, \
DT_PROP(EXTFLASH_NODE, size) / 8)
code_relocation: Extend the nocopy sample to nRF5340dk The nRF5340dk is shipping an external QSPI flash that can be used to do XIP from. Extend the code_relocation nocopy sample to support this platform so that part of the functions are executed from internal flash and others from external flash. Signed-off-by: Carlo Caione <ccaione@baylibre.com>
2022-02-17 20:04:00 +08:00
#else
code_relocation: Add NOCOPY feature * Use case of interest: Some platforms are shipping in parallel to the internal FLASH some other storage / external FLASH (usually a QSPI FLASH) that can be used to execute (XIP) code from. The content of this external FLASH can usually be written at flash time using proper tools (see for example the case of the external FLASH on the nRF5340DK that can be written at flash time using nrfjprog). The external FLASH is a nice addition that is extremely useful when a large application code doesn't entirely fit on the internal FLASH so that we could want to move part of it in the auxiliary FLASH to XIP the code from there. * The problem: Right now Zephyr doesn't have a formal and generic way to move at build time part of the code to a different memory region. * The current status: Zephyr is indeed shipping a code_relocation feature but that doesn't entirely match our needs. When XIP is enabled, the code_relocation feature is used in Zephyr to move the selected code (that is to copy text section, to initialize data and zero bss) from FLASH to SRAM at run time and execute code from SRAM. The relocation is done by a generated snippet of code that is memcpy()-ing the right content to the destination region also using some build-time generated portions of linker script to retrieve start and destination addresses and regions. * This patch: This patch is leveraging the code_relocation code and adding a NOCOPY feature. This feature is using the code_relocation feature to dynamically build the linker script snippets but entirely skipping the run-time code relocation so that the code can be XIP-ed from the destination region. * Example: Let's say that we have a big file called `huge_file.c` that we want to XIP from the external FLASH that is mapped in an EXTFLASH region. In this case we should enable `CONFIG_XIP` and `CONFIG_CODE_DATA_RELOCATION` and instruct cmake as follows: zephyr_code_relocate(src/huge_file.c EXTFLASH_TEXT NOCOPY) zephyr_code_relocate(src/huge_file.c SRAM_DATA) this means that: - The .text section of the `huge_file.c` must reside in the EXTFLASH memory region and we do not need to copy the section there because we are going to XIP it (and we assume that the file is going to be placed in the external FLASH at flash time). - The .data section of the `huge_file.c` must still reside in the SRAM memory region. * TODOs: It's desirable to have the possibility to relocate libraries and pre-build files instead of source code files. Signed-off-by: Carlo Caione <ccaione@baylibre.com>
2022-02-16 04:18:50 +08:00
/*
* Add another fake portion of FLASH to simulate a secondary or external FLASH
* that we can do XIP from.
*/
samples/code_relocation_nocopy: Increase fake flash size When linking with the 0.16.3 SDK version of picolibc, using long long cbprintf support pulls in the full floating point printf which is much larger than the integer-only version. This ends up overflowing the memory region available for it. Increase the size of that by bumping the start of the fake region by 8kB. Signed-off-by: Keith Packard <keithp@keithp.com>
2023-09-28 01:25:50 +08:00
#define EXTFLASH_ADDR 0x7000
code_relocation: Add NOCOPY feature * Use case of interest: Some platforms are shipping in parallel to the internal FLASH some other storage / external FLASH (usually a QSPI FLASH) that can be used to execute (XIP) code from. The content of this external FLASH can usually be written at flash time using proper tools (see for example the case of the external FLASH on the nRF5340DK that can be written at flash time using nrfjprog). The external FLASH is a nice addition that is extremely useful when a large application code doesn't entirely fit on the internal FLASH so that we could want to move part of it in the auxiliary FLASH to XIP the code from there. * The problem: Right now Zephyr doesn't have a formal and generic way to move at build time part of the code to a different memory region. * The current status: Zephyr is indeed shipping a code_relocation feature but that doesn't entirely match our needs. When XIP is enabled, the code_relocation feature is used in Zephyr to move the selected code (that is to copy text section, to initialize data and zero bss) from FLASH to SRAM at run time and execute code from SRAM. The relocation is done by a generated snippet of code that is memcpy()-ing the right content to the destination region also using some build-time generated portions of linker script to retrieve start and destination addresses and regions. * This patch: This patch is leveraging the code_relocation code and adding a NOCOPY feature. This feature is using the code_relocation feature to dynamically build the linker script snippets but entirely skipping the run-time code relocation so that the code can be XIP-ed from the destination region. * Example: Let's say that we have a big file called `huge_file.c` that we want to XIP from the external FLASH that is mapped in an EXTFLASH region. In this case we should enable `CONFIG_XIP` and `CONFIG_CODE_DATA_RELOCATION` and instruct cmake as follows: zephyr_code_relocate(src/huge_file.c EXTFLASH_TEXT NOCOPY) zephyr_code_relocate(src/huge_file.c SRAM_DATA) this means that: - The .text section of the `huge_file.c` must reside in the EXTFLASH memory region and we do not need to copy the section there because we are going to XIP it (and we assume that the file is going to be placed in the external FLASH at flash time). - The .data section of the `huge_file.c` must still reside in the SRAM memory region. * TODOs: It's desirable to have the possibility to relocate libraries and pre-build files instead of source code files. Signed-off-by: Carlo Caione <ccaione@baylibre.com>
2022-02-16 04:18:50 +08:00
#define EXTFLASH_SIZE (CONFIG_FLASH_SIZE * 1K - EXTFLASH_ADDR)
samples: code_relocation_nocopy: Make linker script more generic Instead of depending on the nRF5340 DK, use a path specific to just the nRF5340 SoC and get the size of the external flash in this case from devicetree so that the sample could be easily run on other boards based on the nRF5340 SoC (after just adding proper overlays). On the occasion, correct the attributes of the EXTFLASH memory region. Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-09-13 18:39:02 +08:00
#endif
code_relocation: Add NOCOPY feature * Use case of interest: Some platforms are shipping in parallel to the internal FLASH some other storage / external FLASH (usually a QSPI FLASH) that can be used to execute (XIP) code from. The content of this external FLASH can usually be written at flash time using proper tools (see for example the case of the external FLASH on the nRF5340DK that can be written at flash time using nrfjprog). The external FLASH is a nice addition that is extremely useful when a large application code doesn't entirely fit on the internal FLASH so that we could want to move part of it in the auxiliary FLASH to XIP the code from there. * The problem: Right now Zephyr doesn't have a formal and generic way to move at build time part of the code to a different memory region. * The current status: Zephyr is indeed shipping a code_relocation feature but that doesn't entirely match our needs. When XIP is enabled, the code_relocation feature is used in Zephyr to move the selected code (that is to copy text section, to initialize data and zero bss) from FLASH to SRAM at run time and execute code from SRAM. The relocation is done by a generated snippet of code that is memcpy()-ing the right content to the destination region also using some build-time generated portions of linker script to retrieve start and destination addresses and regions. * This patch: This patch is leveraging the code_relocation code and adding a NOCOPY feature. This feature is using the code_relocation feature to dynamically build the linker script snippets but entirely skipping the run-time code relocation so that the code can be XIP-ed from the destination region. * Example: Let's say that we have a big file called `huge_file.c` that we want to XIP from the external FLASH that is mapped in an EXTFLASH region. In this case we should enable `CONFIG_XIP` and `CONFIG_CODE_DATA_RELOCATION` and instruct cmake as follows: zephyr_code_relocate(src/huge_file.c EXTFLASH_TEXT NOCOPY) zephyr_code_relocate(src/huge_file.c SRAM_DATA) this means that: - The .text section of the `huge_file.c` must reside in the EXTFLASH memory region and we do not need to copy the section there because we are going to XIP it (and we assume that the file is going to be placed in the external FLASH at flash time). - The .data section of the `huge_file.c` must still reside in the SRAM memory region. * TODOs: It's desirable to have the possibility to relocate libraries and pre-build files instead of source code files. Signed-off-by: Carlo Caione <ccaione@baylibre.com>
2022-02-16 04:18:50 +08:00
MEMORY
{
samples: code_relocation_nocopy: Make linker script more generic Instead of depending on the nRF5340 DK, use a path specific to just the nRF5340 SoC and get the size of the external flash in this case from devicetree so that the sample could be easily run on other boards based on the nRF5340 SoC (after just adding proper overlays). On the occasion, correct the attributes of the EXTFLASH memory region. Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2023-09-13 18:39:02 +08:00
EXTFLASH (rx) : ORIGIN = EXTFLASH_ADDR, LENGTH = EXTFLASH_SIZE
code_relocation: Add NOCOPY feature * Use case of interest: Some platforms are shipping in parallel to the internal FLASH some other storage / external FLASH (usually a QSPI FLASH) that can be used to execute (XIP) code from. The content of this external FLASH can usually be written at flash time using proper tools (see for example the case of the external FLASH on the nRF5340DK that can be written at flash time using nrfjprog). The external FLASH is a nice addition that is extremely useful when a large application code doesn't entirely fit on the internal FLASH so that we could want to move part of it in the auxiliary FLASH to XIP the code from there. * The problem: Right now Zephyr doesn't have a formal and generic way to move at build time part of the code to a different memory region. * The current status: Zephyr is indeed shipping a code_relocation feature but that doesn't entirely match our needs. When XIP is enabled, the code_relocation feature is used in Zephyr to move the selected code (that is to copy text section, to initialize data and zero bss) from FLASH to SRAM at run time and execute code from SRAM. The relocation is done by a generated snippet of code that is memcpy()-ing the right content to the destination region also using some build-time generated portions of linker script to retrieve start and destination addresses and regions. * This patch: This patch is leveraging the code_relocation code and adding a NOCOPY feature. This feature is using the code_relocation feature to dynamically build the linker script snippets but entirely skipping the run-time code relocation so that the code can be XIP-ed from the destination region. * Example: Let's say that we have a big file called `huge_file.c` that we want to XIP from the external FLASH that is mapped in an EXTFLASH region. In this case we should enable `CONFIG_XIP` and `CONFIG_CODE_DATA_RELOCATION` and instruct cmake as follows: zephyr_code_relocate(src/huge_file.c EXTFLASH_TEXT NOCOPY) zephyr_code_relocate(src/huge_file.c SRAM_DATA) this means that: - The .text section of the `huge_file.c` must reside in the EXTFLASH memory region and we do not need to copy the section there because we are going to XIP it (and we assume that the file is going to be placed in the external FLASH at flash time). - The .data section of the `huge_file.c` must still reside in the SRAM memory region. * TODOs: It's desirable to have the possibility to relocate libraries and pre-build files instead of source code files. Signed-off-by: Carlo Caione <ccaione@baylibre.com>
2022-02-16 04:18:50 +08:00
}
include: arch: arm: Remove aarch32 directory This commit follows the parent commit work. This commit introduces the following major changes. 1. Move all directories and files in 'include/zephyr/arch/arm/aarch32' to the 'include/zephyr/arch/arm' directory. 2. Change the path string which is influenced by the changement 1. Signed-off-by: Huifeng Zhang <Huifeng.Zhang@arm.com>
2023-07-04 16:01:39 +08:00
#include <zephyr/arch/arm/cortex_m/scripts/linker.ld>