zephyr

History

Gerard Marull-Paretas 79e6b0e0f6 includes: prefer <zephyr/kernel.h> over <zephyr/zephyr.h> As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>. This patch proposes to then include <zephyr/kernel.h> instead of <zephyr/zephyr.h> since it is more clear that you are including the Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a catch-all header that may be confusing. Most applications need to include a bunch of other things to compile, e.g. driver headers or subsystem headers like BT, logging, etc. The idea of a catch-all header in Zephyr is probably not feasible anyway. Reason is that Zephyr is not a library, like it could be for example `libpython`. Zephyr provides many utilities nowadays: a kernel, drivers, subsystems, etc and things will likely grow. A catch-all header would be massive, difficult to keep up-to-date. It is also likely that an application will only build a small subset. Note that subsystem-level headers may use a catch-all approach to make things easier, though. NOTE: This patch is NOT removing the header, just removing its usage in-tree. I'd advocate for its deprecation (add a #warning on it), but I understand many people will have concerns. Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>		2022-09-05 16:31:47 +02:00
..
boards	samples: code_relocation_nocopy: Fix initialization of external memory	2022-06-24 20:29:00 +02:00
src	includes: prefer <zephyr/kernel.h> over <zephyr/zephyr.h>	2022-09-05 16:31:47 +02:00
CMakeLists.txt
linker_arm_nocopy.ld	linker: update files with <zephyr/...> include prefix	2022-05-09 12:45:29 -04:00
prj.conf	samples: code_relocation_nocopy: Disable gap filling	2022-06-24 20:29:00 +02:00
README.rst	samples: code_relocation_nocopy: Update documentation	2022-06-24 20:29:00 +02:00
sample.yaml

README.rst

.. _code_relocation_nocopy:

Code relocation nocopy
######################

Overview
********
A simple example that demonstrates how relocation of code, data or bss sections
using a custom linker script.

Differently from the code relocation sample, this sample is relocating the
content of the ext_code.c file to a different FLASH section and the code is XIP
directly from there without the need to copy / relocate the code.

nRF5340 DK platform instructions
********************************

The nRF5340 DK has a 64 Mb external flash memory supporting Quad SPI. It is
possible to do XIP from the external flash memory.

The external flash memory is mapped to 0x10000000.

In this sample we relocate some of the code to the external flash memory with
the remaining Zephyr kernel in the internal flash.

To build and flash the application (including the external memory part):

.. zephyr-app-commands::
   :zephyr-app: samples/application_development/code_relocation_nocopy
   :board: nrf5340dk_nrf5340_cpuapp
   :goals: build flash
   :compact:

Execution output:

.. code-block:: console

  *** Booting Zephyr OS build v3.0.0-rc3-25-g0df32cec1ff2  ***
  Address of main function 0x4f9
  Address of function_in_ext_flash 0x10000001
  Address of var_ext_sram_data 0x200000a0 (10)
  Address of function_in_sram 0x20000001
  Address of var_sram_data 0x200000a4 (10)
  Hello World! nrf5340dk_nrf5340_cpuapp