Align backtrace output with the style used in rest of the codespace.
This makes it more convenient to compare the backtrace to e.g. objdump
output.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
On GICv3, when we send an IPI interrupt, aff3, aff2 and aff1 should
be assigned a value corespond to a PE for which interrupt will be
generated. target_list only corresponds to aff0.
On real hardware, aff3, aff2, aff1 and aff0 should be treated as a
whole to determine a PE.
Signed-off-by: Huifeng Zhang <Huifeng.Zhang@arm.com>
VMPIDR_EL2 is assigned the value returned by EL2 reads of MPIDR_EL1
MPIDR_EL1 is the register holding the Multiprocessor ID which is to
identify different cores. Because of the virtualization requirements
for AArch64, MPIDR_EL1 should be virtualized (the different virtualized
cores can run on the same physical core). Thus the value of MPIDR_EL1
should be switched when the VM is switched. Setting the VMPIDR_EL2 is
the way to change the value returned by EL1 reads of MPIDR_EL1. Even
without virtualization, we still need to set VMPIDR_EL2 during booting
at EL2 or EL3. Otherwise, all cores' IDs are zero at the EL1 stage
which will break the SMP system.
Signed-off-by: Huifeng Zhang <Huifeng.Zhang@arm.com>
This commit is fixing placing the vectors section through
zephyr_linker_sources(ROM_START ...) (as done in the ARM
architecture port) so its order can be adjusted by SORT_KEY.
Fixes#49903
Signed-off-by: Mateusz Sierszulski <msierszulski@antmicro.com>
The Xtensa arch has historically had state/user register accessor
macros with bare three-byte symbol names. I think this might have
been in the original Cadence-contributed arch integration, but I'm not
sure. In any case they also exist in the same names in vendor
HAL/toolchain code and are causing collisions. We never should have
had these symbols exposed in our header.
Put them under an XTENSA_ prefix to decollide.
Signed-off-by: Andy Ross <andyross@google.com>
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>
Convert the device to be Devicetree based. Adjusted tests and other
areas that were using old Kconfig properties.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The "framebuf" driver was an incomplete driver expecting _clients_ to
implement missing functionality (i.e. init and device definition)
outside of the driver. This pattern of scattering driver code throughout
the tree is not common (if used at all). If certain drivers share
functionality, one can create a common module within the subsystem (see
e.g. ILI9XXX drivers).
The _generic_ framebuffer code was only used to implement the Intel
Multiboot framebuffer driver. This patch centralizes all the scattered
code in the subsystem and adjusts the driver name to "intel_multibootfb"
to make things clear. If there's ever another framebuffer driver that
shares code, it can be split into multiple modules.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Two issues:
- A unnecessary parentheses pair caused rounding errors (by truncating
a small value before multiplying it).
- arch_timing_cycles_to_ns_avg() wasn't actually converting the result
to nanoseconds.
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
This commit renames the ARC64 output format from `elf64-littlearc` to
`elf64-littlearc64` as required by the updated ARC patches for the GCC
12.1 release.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
This PR allows the user to add symbols to the nocache
section. The use for this could be as follows
zephyr_linker_sources_ifdef(CONFIG_NOCACHE_MEMORY
NOCACHE_SECTION
nocache.ld
)
nocache.ld (as shown below) can define additional
symbols to go into the nocache section
. = ALIGN(4);
KEEP(*(NonCacheable))
Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
Add support for LLVM's libfuzzer utility. This works by building an
executable with a "LLVMFuzzerTestOneInput()" entry point (which is
external to Zephyr, running in the host process environment!), which
it drives out of its own main() routine. The toolchain API is exposed
as just another sanitizer variant, which is clean.
Signed-off-by: Andy Ross <andyross@google.com>
GCC 12 performs bounds checking on the pointer arguments specified like
an array (e.g. `int arg[]`) and treats such arguments with an empty
length as having the length of 0, resulting in the compiler printing
out `stringop-overread' warning when they are accessed.
This commit corrects any pointer arguments declared using the array
expression to use the pointer expression instead.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
This implements support for relocating code to chosen memory regions via
the `zephyr_code_relocate` CMake function for RISC-V SoCs. ARM-specific
assumptions that were made by gen_relocate_app.py need to be corrected,
in particular not assuming any particular name for the default RAM
section (which is 'SRAM' for most ARM pltaforms) and not assuming 32-bit
pointers (so the test works on RV64).
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Support for CODE_DATA_RELOCATION is not inherently limited to ARM, so
move the Kconfig definition to top-level so it can be used by other
architectures. Since support is opt-in (requiring linker script
support), add a helper symbol enabled by architecture config that gates
whether CODE_DATA_RELOCATION is available instead of listing all
supported systems inline.
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
When a cache API function is called from userspace, this results on
ARM64 in an OOPS (bad syscall error). This is due to at least two
different factors:
- the location of the cache handlers is preventing the linker to
actually find the handlers
- specifically for ARM64 and ARC some cache handling functions are not
implemented (when userspace is not used the compiler simply optimizes
out these calls)
Fix the problem by:
- moving the userspace cache handlers to a their logical and proper
location (in the drivers directory)
- adding the missing handlers for ARM64 and ARC
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Some platforms have the possibility to cancel the powering off until the
very latest moment (for example if an IRQ is received). Deal with this
kind of failures.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
In case of ARCv3 64 bit we have only one 64bit accumulator
register instead of register pair, so fixup register
save & restore code.
While we at it also make ARC_HAS_ACCL_REGS option (which
controls accumulator reg/regs save & restore) default
for HS5x and HS6x as well - as it should be.
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Signed-off-by: Evgeniy Paltsev <PaltsevEvgeniy@gmail.com>
It is frequent to find variable definitions like this:
```c
static const struct device *dev = DEVICE_DT_GET(...)
```
That is, module level variables that are statically initialized with a
device reference. Such value is, in most cases, never changed meaning
the variable can also be declared as const (immutable). This patch
constifies all such cases.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Wire this up the same way ASAN works. Right now it's support only by
recent clang versions (not gcc), and only in 64 bit mode. But it's
capable of detecting uninitialized data reads, which ASAN is not.
This support is wired into the sys_heap (and thus k_heap/k_malloc)
layers, allowing detection of heap misuse like use-after-free. Note
that there is one false negative lurking: due to complexity, in the
case where a sys_heap_realloc() call is able to shrink memory in
place, the now-unused suffix is not marked uninitialized immediately,
making it impossible to detect use-after-free of those particular
bytes. But the system will recover cleanly the next time the memory
gets allocated.
Also no attempt was made to integrate this handling into the newlib or
picolibc allocators, though that should hopefully be possible via
similar means.
Signed-off-by: Andy Ross <andyross@google.com>
This had bitrotten a bit, and didn't build as shipped. Current
libasan implementations want -fsanitize=address passed as a linker
argument too. We have grown a "lld" linker variant that needs the
same cmake treatment as the "ld" binutils one, but never got it. But
the various flags had been cut/pasted around to different places, with
slightly different forms. That's really sort of a mess, as sanitizer
support was only ever support with host toolchains for native_posix
(and AFAICT no one anywhere has made this work on cross compilers in
an embedded environment). And the separate "gcc" vs. "llvm" layers
were silly, as there has only ever been one API for this feature (from
LLVM, then picked up compatibly by gcc).
Pull this stuff out and just do it in one place in the posix arch for
simplicity.
Also recent sanitizers are trying to add instrumentation padding
around data that we use linker trickery to pack tightly
(c.f. SYS_INIT, STRUCT_SECTION_ITERABLE) and we need a way
("__noasan") to turn that off. Actually for gcc, it was enough to
just make the records const (already true for most of them, except a
native_posix init struct), but clang apparently isn't smart enough.
Finally, add an ASAN_RECOVER kconfig that enables the use of
"halt_on_error=0" in $ASAN_OPTIONS, which continues execution past the
first error.
Signed-off-by: Andy Ross <andyross@google.com>
Changing $(ARCH_DIR)/common/Kconfig to arch/common/Kconfig.
The use of ARCH_DIR at this place is wrong, as it suddenly requires out
of tree archs to support a common/Kconfig file, which may make no sense
to them.
If an out of tree arch wants to place common Kconfig code in a common
Kconfig file, that's their choice and they should source such file
themselves.
Instead just source the Zephyr arch common file directly.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
We have now:
- CPU_HAS_{D,I}CACHE: when the CPU has support for d-cache and i-cache
- {D,I}CACHE: to enable / disable d-cache and i-cache
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
A Cortex-M BusFault often arises from the execution of a function
pointer that got corrupted.
The Zephyr Cortex-M fault handler de-references the `$pc` in
`z_arm_is_synchronous_svc()` to determine if the fault was due to a
kernel oops (ARCH_EXCEPT). This can cause a BusFault if the pc itself
was corrupt. A BusFault from a HardFault will trigger ARM Cortex-M
"Lockup" preventing the Zephyr fault handler from running to
completion. This in turn, results in no fault handling information
getting dumped by the Zephyr fault handler.
To fix the issue, we can simply set the `CCR.BFHFNMIGN` bit prior to
the instruction address dereference which will cause the processor to
ignore the BusFault and return a value of 0x0 instead of entering
lockup. After the operation is complete, we clear `CCR.BFHFNMIGN` as
it would be unexpected for any other code in the fault handler to
trigger a fault.
The issue can be reproduced programmatically with:
```
void (*unaligned_func)(void) = (void (*)(void))0x50000001;
unaligned_func();
```
I bumped into this problem while debugging an issue on the nRF9160DK
(`west build --board nrf9160dk_nrf9160ns`) and confirmed that after
making this change I now see the full fault handler print:
```
[00:00:45.582,214] <err> os: Exception occurred in Secure State
[00:00:45.582,244] <err> os: ***** HARD FAULT *****
[...]
[00:00:45.583,984] <err> os: Current thread: 0x2000d340 (shell_uart)
[00:00:45.829,498] <err> fatal_error: Resetting system
```
Signed-off-by: Chris Coleman <chris@memfault.com>
Allow enabling FPU with TF-M with the following limitations:
- Only IPC mode is supported by TF-M.
- Disallow FPU hard ABI when building the NS application, the TF-M build
system does not pass the flags correctly to all dependencies.
Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
QEMU requires that the semihosting trap instruction sequence, which
consists of three uncompressed instructions, lie in the same page, and
refuses to interpret the trap sequence if these instructions are placed
across two different pages.
This commit adds 16-byte alignment requirement to the `semihost_exec`
function, which occupies 12 bytes, to ensure that the three trap
sequence instructions in this function are never placed across two
different pages.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
All SOC_ERET definitions expand to the mret instruction (used to return
from a trap: exception or interruption). The 'eret' instruction existed
in previous RISC-V privileged specs, but it doesn't seem to be used in
Zephyr (ref. RISC-V Privileged Architectures 3.2.2).
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Some processors support Dual-redundant Core Lock-step
DCLS) topology but the processor still can be ran in
split-lock mode (by default or changed at flash time).
So, introduce config DCLS that is enabled by default if
config CPU_HAS_DCLS is set, it should be disabled if
processor is used in split-lock mode.
Signed-off-by: Dat Nguyen Duy <dat.nguyenduy@nxp.com>
ICI (Inter-Core Interrupt Unit) interrupts and priorities were hardcoded
in C files. This patch moves this information to Devicetree and updates
code to make use of it.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Transfer the entry point and initial parameters in the callee_saved
struct rather than on the stack. This saves 48 byte stack per thread
and simplifies the logic.
Signed-off-by: Julius Barendt <julius.barendt@gaisler.com>
Execute data and instruction sync barriers after writing to SCTLR
to disable the MPU, to ensure the registers are set before
proceeding and that the new changes are seen by the instructions
that follow.
Signed-off-by: Manuel Arguelles <manuel.arguelles@nxp.com>
Execute data and instruction sync barriers after writing to SCTLR
to enable the MPU, to ensure the registers are set before
proceeding and that the new changes are seen by the instructions
that follow.
Signed-off-by: Manuel Arguelles <manuel.arguelles@nxp.com>
The simulator seems to drop garbage addresses (somewhere in the ROM it
looks like) into this SR at arbitrary times. I don't know if this is
a hardware exception handler that we can't turn off, or a simulator
bug, or what. But our code that assumes it will be cleared to zero or
valid is breaking. Set it every time in every context switch for now
pending someone figuring out what's going wrong.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
When compiling OpenAMP with Zephyr Cache Management, undefined references
are listed for all functions called with in the cache management
Signed-off-by: Ryan McClelland <ryanmcclelland@fb.com>
Move those defines and values back to headers. Kconfig is not a good
place for this, later this should move to DTS.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Kai Vehmanen