In case of the st,stm32-qspi-nor compatible
new property and node definitions will requires new macro
to get the external NOR flash base address and size
Add the config for running the sample on stm32l475 disco kit
Signed-off-by: Francois Ramu <francois.ramu@st.com>
In case of the st,stm32-ospi-nor compatible
new property and node definitions will requires new macro
to get the external NOR flash base address and size
Signed-off-by: Francois Ramu <francois.ramu@st.com>
In case of the st,stm32-xspi-nor compatible
new property and node definitions will requires new macro
to get the external NOR flash base address and size
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Fix typos in stm32 flash sizes value introduced by commit 0e1ffc7beb
("samples: code_relocation_nocopy: update macro to get flash size").
Fixes: 0e1ffc7beb
Signed-off-by: Etienne Carriere <etienne.carriere@st.com>
The flash size is the second part (size) of the first reg value,
not the first part (address) of a nonexistent second reg value.
DT_REG_SIZE get a node's (only) register block size instead
DT_REG_ADDR_BY_IDX .
Signed-off-by: Fabrice DJIATSA <fabrice.djiatsa-ext@st.com>
Define the configuration to run the code_relocation
application on the external memory xspi flash
of the stm32h573i_dk disco kit in XIP
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Define the configuration to run the code_relocation
application on the external memory octo flash
of the stm32u585 or stm32h7b3i disco kit in XIP
Signed-off-by: Francois Ramu <francois.ramu@st.com>
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>
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>
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>
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>
The autoconf.h header is not required because the definitions present in
the file are exposed using the compiler `-imacros` flag.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
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>
* 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>
