Commit Graph

10 Commits

Author SHA1 Message Date
Flavio Ceolin d16c5b9048 kernel: canaries: Allow using TLS to store it
Add new option to use thread local storage for stack
canaries. This makes harder to find the canaries location
and value. This is made optional because there is
a performance and size penalty when using it.

Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
2023-08-08 19:08:04 -04:00
Gerard Marull-Paretas afffc1006f kernel: remove redundant <zephyr/zephyr.h> includes
Files including <zephyr/kernel.h> do not have to include
<zephyr/zephyr.h>, a shim to <zephyr/kernel.h>.

Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-06-15 09:13:11 +02:00
Gerard Marull-Paretas cffefc818d kernel: migrate includes to <zephyr/...>
In order to bring consistency in-tree, migrate all kernel code to the
new prefix <zephyr/...>. Note that the conversion has been scripted,
refer to zephyrproject-rtos#45388 for more details.

Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-05-09 09:26:20 +02:00
Nicolas Pitre 678b76e4b0 kernel/init.c: allow for memset/memcpy alternatives during early boot
Zeroing the BSS and copying data to RAM with regular memset/memcpy may
cause problems when those functions are assuming a fully initialized
system for their optimizations to work e.g. some instructions require
an active MMU, but turning the MMU on needs the .bss section to be
cleared first, etc.

Commit c5b898743a ("aarch64: Fix alignment fault on z_bss_zero()")
provides a detailed explanation of such a case.

Replacing z_bss_zero() with an architecture specific one is problematic
as the former may see new sections added to it that would be missed by
the later. The same reasoning goes for z_data_copy().

Let's make maintenance much easier by providing weak versions of
memset/memcpy that can be overridden by architecture-specific safe
versions when needed.

Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2022-02-21 21:00:12 -05:00
Daniel Leung d3b030be9b kernel: remove @return doc for void functions
For functions returning nothing, there is no need to document
with @return, as Doxgen complains about "documented empty
return type of ...".

Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2022-01-12 16:02:16 -05:00
Torsten Rasmussen a28830b811 linker: align __itcm_load_start / __dtcm_data_load_start linker symbols
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 __itcm_load_start and
__dtcm_data_load_start 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 names are itcm and dtcm.

The following symbols are aligned in this commit:
-  __itcm_rom_start      -> __itcm_load_start
-  __dtcm_data_rom_start -> __dtcm_data_load_start

Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2021-08-28 08:48:03 -04:00
Torsten Rasmussen 510d7dbfb6 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-08-28 08:48:03 -04:00
Torsten Rasmussen 65a2de84a9 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-08-28 08:48:03 -04:00
Maureen Helm f63385204c 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-15 14:51:20 +01:00
Anas Nashif de69edbf42 kernel: move xip code to dedicated file
No functional changes, just moving the XIP code out and build it only
when XIP is enabled.

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2020-11-27 20:08:14 -05:00