Add "zephyr,ocm" to the list of supported "chosen" nodes in
the devicetree reference docs.
Signed-off-by: Immo Birnbaum <Immo.Birnbaum@weidmueller.com>
Instead of setting XCC_USE_CLANG=1, this patch adds xcc-clang toolchain
that is basically xcc using the clang compiler.
Initially, the new toolchain simply includes files from current xcc
toolchain and (re)sets some variables. This should be a more scalable
approach to diverge the toolchains in the future than placing
"if($ENV{XCC_USE_CLANG})" at several places.
It should also help to filter tests that run (or not) exclusively with
the clang variant of XCC on twister.
The XCC_USE_CLANG flag is documented as deprecated, and a message is
emitted during build if still in use. Its new behaviour is to instruct
Zephyr to use `xcc-clang` toolchain.
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
The item mode is really a specialization of the byte mode. And in-tree
usage shows the byte mode is prominent. It feels more natural if the
byte mode is presented first with the item mode second. Swap the code
and documentation order accordingly. No code change.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
This code is rather hairy. When I look at it I don't like the way it
stares back at me.
First, the rewind business looks fishy. It has to die.
And we don't have to rely on modulus either. Not even for non-power-of-2
buffers. Let's kill that distinction too and make all sizes always
"high performance".
The code is now entirely relying only on simple ALU operations (add,
sub and compare).
The key assumption: 32-bit values do wrap around after max range has
been reached. No saturation. All architectures supported by Zephyr
do that.
Some stats:
lib/os/ring_buffer.c: 62 insertions(+), 124 deletions(-)
ring_buffer.c.obj before after diff
----------------------------------------------
frdm_k64f 1224 1136 -88
m2gl025_miv 2485 2079 -406
mps2_an385 1228 1132 -96
mps2_an521 1228 1132 -96
native_posix 1546 1496 -50
native_posix_64 1598 1595 -3
nsim_hs_mpuv6 1252 1192 -60
nsim_hs_smp 1252 1192 -60
nsim_sem 1252 1192 -60
qemu_arc_em 1324 1192 -132
qemu_arc_hs6x 1824 1620 -204
qemu_arc_hs 1252 1192 -60
qemu_cortex_a53_smp 2154 1888 -266
qemu_cortex_a53 2154 1888 -266
qemu_cortex_a9 1938 1792 -146
Before (qemu_cortex_a53):
START - test_ringbuffer_performance
1 byte put-get, avg cycles: 52
4 byte put-get, avg cycles: 47
1 byte put claim-finish, avg cycles: 39
5 byte put claim-finish, avg cycles: 41
5 byte get claim-finish, avg cycles: 52
PASS - test_ringbuffer_performance in 0.8 seconds
After (qemu_cortex_a53):
START - test_ringbuffer_performance
1 byte put-get, avg cycles: 34
4 byte put-get, avg cycles: 41
1 byte put claim-finish, avg cycles: 27
5 byte put claim-finish, avg cycles: 29
5 byte get claim-finish, avg cycles: 29
PASS - test_ringbuffer_performance in 0.4 seconds
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Conceptually, ring_buf_item_put() and ring_buf_item_get() are specialized
versions of ring_buf_put() and ring_buf_get(). Make it so to rationalize
the code to open the way for more optimizations.
This means we need specialized wrappers on top of ring_buf_init()
accordingly, given that the core machinery is now common and byte based.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
The documentation was somewhat confused. Bring it closer to reality.
The SIZE32_OF() usage, while not wrong per se, is not as clear as
using the number of words directly. Let's favor the later to make the
documentation clearer.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Aligning with the rest of PM API, replace pm_power_state_exit_post_ops
with pm_state_exit_post_ops.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
The filtered warnings are warnings we can't fix due to Sphinx
limitations, so showing them just adds noise to the doc build process.
The extension already defaults to silent mode.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Rework the contribution guide's Signed-off-by: language to be clearer
and reflect the TSC guidance that legal names are required. Also
clarify that existing s-o-b lines should be preserved.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Creating a doc.cmake to the new Zephyr CMake modules dir.
This removes the need for `set(NO_BOILERPLATE TRUE)` before loading the
Zephyr CMake package.
It also removes the need within the doc/CMakeLists.txt file to manually
include individual parts of the Zephyr CMake files as this is now
controlled through a single Zephyr CMake doc module.
This aligns the way a Zephyr package is sourced with other places.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
* 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>
We use a specific experimental Kconfig option when describing the
behavior of CONFIG_WARN_EXPERIMENTAL.
However, this option may not be experimental forever. This therefore
may go stale. Rather than try to keep generic documentation about
experimental options up to date with whatever the bluetooth subsystem
happens to consider experimental or not, use a placeholder CONFIG_FOO
instead of a real option.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Similar to Kconfig turbo mode, add a Devicetree bindings turbo mode. In
this mode, the Devicetree bindings pages are not generated. Instead, a
page with dummy symbols is created. This takes ~1K pages out of the
build, resulting in faster builds. This mode can be useful while in
development or CI PRs.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Zephyr docs should mention OTA:
- Define Over-the-Air update
- Indicate OTA can be used with MCUboot
- Link examples of the OTA DFU process
Signed-off-by: Mike Szczys <mike@golioth.io>
The logo did not display black text when using the Github light theme in
a system configured to prefer dark mode. An alternative solution: just
make text grayish (#4e4e4e) so that it looks "ok" in both light and dark
modes.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Remove issues related to the backporting of fixes to the 1.14 branch as
they are not related to the 3.0 release.
Signed-off-by: Dan Kalowsky <dank@deadmime.org>
Add details to the release note about Cortex-R behavioral changes and
the general arm MPU use of CMSIS versus the older inline assembler.
Signed-off-by: Dan Kalowsky <dank@deadmime.org>
The second and third bytes of the packaged string headers
have new meanings after support for fully self-contained
(fsc) packaged string was added in commit
5d80cbae59. So update
the document to reflect this.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Use an SVG based logo with embedded style that toggles title color using
media queries. The SVG logo is not exactly the same as the previous one
as I only had this version in SVG (taken from docs actually).
Note that we cannot use the method described in
https://github.blog/changelog/
2021-11-24-specify-theme-context-for-images-in-markdown/ because the
README is written in rst, not Markdown.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
