Architecturally, Set/Way operations are not guaranteed to affect all
caches prior to the PoC, and may require other IMPLEMENTATION DEFINED
maintenance (e.g. MMIO control of system-level caches).
First of all this patch was designed for Xen domain Zephyr build, set/way
ops are not easily virtualized by Xen. S/W emulation is disabled, because
IP-MMU is active for Dom0. IP-MMU is a IO-MMU made by Renesas, as any good
IO-MMU, it shares page-tables with CPU. Trying to emulate S/W with IP-MMU
active will lead to IO-MMU faults. So if we build Zephyr as a Xen Initial
domain, it won't work with cache management support enabled.
Exposing set/way cache maintenance to a virtual machine is unsafe, not
least because the instructions are not permission-checked, but also
because they are not broadcast between CPUs.
In this commit, VA data invalidate invoked after every mapping instead of
using set/way instructions on init MMU. So, it was easy to delete
sys_cache_data_invd_all from enable MMU function, becase every adding of
a new memory region to xclat tabes will cause invalidating of this memory
and in this way we sure that there are not any stale data inside.
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
The zephyr_library() used to only be called if
CONFIG_GEN_ISR_TABLES is enabled. Which means that any
zephyr_library_*() calls are putting things into another
library if CONFIG_GEN_ISR_TABLES is disabled. So pull
the call to zephyr_library() to outside. Also moves
semihost.c into the library.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
When building the 32bit native board targets variants
for x86(-64) hosts, gcc will promote float literals to double
(See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875 )
This can result in unexpected comparison differences.
This is due to the compiler using the 8087 float mode by
default.
Instead let's tell the compiler to use the SSE float path,
which is the default for 64 bit x86-64 builds.
The assumption that any x86 host used for development
will have SSE support should be safe enough.
For more background see
https://github.com/zephyrproject-rtos/zephyr/issues/61345
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
In print_pmp_entries(), start and end are function arguments
and yet another start and end are declared inside the for
loop. So rename the function arguments to fix shadow variables
warning.
The changes in csr_*() macros are needed to avoid shadowing
__v when nesting those functions together, for example,
csr_write(..., csr_read(...)).
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
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>
Instead of implementing a custom power off API (pm_system_off),
implement the sys_poweroff hook, and indicate power off is supported by
selecting HAS_POWEROFF. Note that according to the PSCI specification
(DEN0022E), the SYSTEM_OFF operation does not return, however, an error
is printed and system is halted in case this occurs.
Note that the pm_system_off has also been deleted, from now on, systems
supporting PSCI should enable CONFIG_POWEROFF and call the standard
sys_poweroff() API.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
In some very rare cases (< 1/1000 runs), in very loaded machines,
a race in the glibc pthread_cancel() seems to be triggered.
In this the cancelled thread cleanup overtakes the pthread_cancel()
code, and frees the pthread structure before pthread_cancel()
has finished, resulting in a dereference into already
free'd memory, and therefore a segfault.
Calling pthread_cancel() during cleanup is not required beyond
preventing a valgrind memory leak report (all threads will be
stopped immediately on exit).
Therefore we stop doing this, to avoid this very rare crashes.
This issue was reproduced in Ubuntu 22.04, with its default
gcc 11.3.0 and glibc 2.35.
The issue may also have been seen very rarely in Zephyr's CI.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
Add Kconfig RISCV_SOC_HAS_CUSTOM_SYS_IO symbol so that a riscv
SoC can set to specify that it has a custom implementation for
sys_io functions.
Signed-off-by: Yong Cong Sin <ycsin@meta.com>
Refactor the ESP32 target SOCs together with
all related boards. Most braking changes includes:
- changing the CONFIG_SOC_ESP32* to refer to
the actual soc line (esp32,esp32s2,esp32s3,esp32c3)
- replacing CONFIG_SOC with the CONFIG_SOC_SERIES
- creating CONFIG_SOC_FAMILY_ESP32 to embrace all
the ESP32 across all used architectures
- introducing CONFIG_SOC_PART_NUMBER_* to
provide a SOC model config
- introducing the 'common' folder to hide all
commonly used configs and files.
- updating west.yml to reflect previous changes in hal
Signed-off-by: Marek Matej <marek.matej@espressif.com>
xt-clang likes to remove any consecutive NOPs more than 8. So
we need to force the function to have no optimization to avoid
this behavior and to retain all those NOPs.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This adds a Kconfig to introduce the Xtensa specific
arch_spin_relax() which can do more NOPs. Some Xtensa SoCs
may need more NOPs after failure to lock a spinlock,
especially under SMP. This gives the bus extra time to
propagate the RCW transactions among CPUs.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
In GNU LD, the location counter (the 'dot' variable) always refers to
the byte offset from the start of current object as mentioned in
documentation[1]:
```
'.' actually refers to the byte offset from the start of the current
containing object. Normally this is the SECTIONS statement, whose start
address is 0, hence '.' can be used as an absolute address. If '.' is
used inside a section description however, it refers to the byte offset
from the start of that section, not an absolute address.
```
For example, if the section 'rom_start':
rom_start : {
. = 0x400;
_vector_start = ABSOLUTE(.);
} > FLASH
has a starting address of 0x8000000, then _vector_start will be
0x8000400
However, behavior of LLVM LLD is quite different, the value of the
location counter is always absolute (see discussion [2]), so in the
example above, the linker will return error, because it will interpret
'. = 0x400' as an attempt to move the location counter backwards.
It could be fixed by changing line to '. += 0x400' (#54796) which will
move the location counter by 0x400 for both linkers, but it would work
only when we are at the beginning of section. Consider the following
example:
rom_start : {
. = 0x400;
KEEP(*(.boot_hdr.conf))
. = 0x1000;
KEEP(*(.boot_hdr.ivt))
KEEP(*(.boot_hdr.data))
KEEP(*(.boot_hdr.dcd_data))
. = 0x2000;
_vector_start = .;
} > FLASH
In this case, _vector_start will be 0x2000, but if we change
'. = 0x2000' to '. += 0x2000', then the value of _vector_start depends
on size of data in input sections (but it's 0x3000 at least).
Actually, this example comes from final linker script when compiling
firmware for mimxrt1170_evk_cm7 board. This board failed to boot
(#55296) after #54796 was merged.
This patch introduces method compatible with both linkers. We calculate
relative offset from the beginning of the section and use that value to
calculate number of bytes by which we should move the location counter
to get CONFIG_ROM_START_OFFSET.
[1] https://sourceware.org/binutils/docs/ld/Location-Counter.html
[2] https://discourse.llvm.org/t/lld-location-counter-inside-objects
Signed-off-by: Patryk Duda <pdk@semihalf.com>
When the frame-pointer based unwinding is enabled, the stop condition
for the stack backtrace is (FP == NULL).
Set FP to 0 before jumping to C code.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
The current implementation causes a lockup of the core when the exception
originates from an invalid/unreachable pc. This fix first verifies on
armv6-m and armv8-m.base that pc was in an expected runnable region,
namely:
- .text
- .ramfunc
- .itcm
Signed-off-by: Wilfried Chauveau <wilfried.chauveau@arm.com>
Adapt to the reworked zephyr cache API.
Fix build errors when building tests/kernel/cache with CACHE_MANAGEMENT and
CPU_HAS_DCACHE enabled for x86 SoCs
Signed-off-by: Dong Wang <dong.d.wang@intel.com>
The z_arm64_fatal_error should be
extern void z_arm64_fatal_error(unsigned int reason, z_arch_esf_t *esf);
Signed-off-by: Jaxson Han <jaxson.han@arm.com>
Clarify why we use target_link_options() instead of
target_link_libraries()
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
To ease writing common drivers, let's make the host trampolines
from the native simulator avaliable to all posix based boards.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
On nRF5340 net core it was observed that when `wfi` instruction was
followed by `pop {r0, lr}` in the `arch_cpu_idle` function,
the value of `lr` sometimes got read as 0 from memory despite
having correct value stored in the memory.
This commit inserts additional `nop` instruction after waking up
to delay access to the memory.
Signed-off-by: Andrzej Kuroś <andrzej.kuros@nordicsemi.no>
Instead of keeping a replica of the nce code,
now that the native_simulator is in tree, let's use
it directly.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
Instead of failing badly later, let's give a clear error
message if the user tries to build in an unsupported platform.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
This allows building with embedded libCs in the Zephyr side,
as the POSIX arch bottom is not anymore built in Zephyr context.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
So they depend or select on the right NATIVE_BUILD
instead of NATIVE_APPLICATION.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
Zephyr provides a default NMI handler (`z_SysNmiOnReset`), which will
basically call `wfi` endlessly. It is allowed to override such handler
when CONFIG_RUNTIME_NMI=y, via `z_arm_nmi_set_handler`. However,
enabling such option also provided `z_arm_nmi_init` (via `NMI_INIT()`),
which basically sets the handler to `DefaultHandler` (a new handler that
basically printks and reboots). This is strictly not needed, and
independent of the runtime NMI option. As a result, most SoCs were
blindly calling `NMI_INIT()`, probably because of a copy&paste effect.
In the majority of cases, this was a no-op, but most SoCs do IRQ
enable/disable, making this even more convoluted. To make things worse,
the init call is expected to run after console has been initialized (for
printk to work?), but most SoCs just called it in PRE_KERNEL_1+0.
This patch just drops this NMI initializer API, and leaves only the
handler set call when CONFIG_RUNTIME_NMI=y.
NMI_INIT() dummy definition is left in this patch to preserve
bisectability, will be dropped later.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
* Add support for coredump on ARM64 architectures.
* Add the script used for post-processing coredump output.
Signed-off-by: Marcelo Ruaro <marcelo.ruaro@huawei.com>
Signed-off-by: Rodrigo Cataldo <rodrigo.cataldo@huawei.com>
Signed-off-by: Roberto Medina <roberto.medina@huawei.com>
The implementation of `z_arm_clear_arm_mpu_config` was compiled for all
ARM cores that declare to have an MPU. However, we only want to compile
it if the MPU is actually enabled.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Where the bottom is the only one which interacts with
the host operating system.
And the top the only one that interacts or is aware
of the hosted operating system (Zephyr).
The bottom uses the native simulator CPU
start/stop emulation.
By now we replicate its code as a provisional measure,
until the native simulator becomes standard.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
Where the bottom is the only one which interacts with
the host operating system, and does not necessarily
need to know about the Zephyr OS.
This is in preparation for the native simulator,
which which the bottom is also fully Zephy agnostic.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
The issue due to which we set the default compiler C std version
to C11 is not specific to any particular POSIX arch board,
but to all. Instead of setting this property for each board,
let's set it at the architecture level.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
This adds support for 32 double-precision registers in the context
switching of aarch32 architecture.
Signed-off-by: Huifeng Zhang <Huifeng.Zhang@arm.com>
`fpscr` is assigned from `struct __fpu_sf.fpscr` in `vfp_restore`, but it
wasn't saved into `struct __fpu_sf.fpscr` in the svc and isr handler, So
it may be a dirty value.
- Fix it by saving `fpscr` in the svc hand isr handler.
- Jump out if FPU isn't enabled
Signed-off-by: Huifeng Zhang <Huifeng.Zhang@arm.com>
The code_relocation feature creates generic section names that sometimes
conflict with already existing names.
This patch adds a '_reloc_' word to the created names to reduce the risk
of conflict.
This solves #54785.
Signed-off-by: Björn Stenberg <bjorn@haxx.se>
