Convert how we get the various chosen properties like "zephyr,console"
to use the new kconfig functions like dt_chosen_to_label.
Because of how kconfig parses things we define a set of variables of the
form DT_CHOSEN_Z_<PROP> since comma's are parsed as field seperators in
macros.
This conversion allows us to remove code in gen_defines.py for the
following chosen properties:
zephyr,console
zephyr,shell-uart
zephyr,bt-uart
zephyr,uart-pipe
zephyr,bt-mon-uart
zephyr,uart-mcumgr
zephyr,bt-c2h-uart
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
We re-wrote the xtensa arch code, but never got around
to purging the old implementation.
Removed those boards which hadn't been moved to the new
arch code. These were all xt-sim simulator targets and not
real hardware.
Fixes: #18138
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
From the Jailhouse days, this has been a function call. That's silly.
We now inline the EOI in the ISR when in x2APIC mode. Also clean up
z_irq_controller_eoi(), so it now uses the inline macros.
Also, we now enable x2APIC on up_squared by default.
Fixes: #17133
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
Use enumerate() to fix this pylint warning:
C0200: Consider using enumerate instead of iterating with range and
len (consider-using-enumerate)
enumerate() is handy when the loop body needs both the element and its
index. It returns (index, element) tuples.
Also use a tuple unpacking to extract 'handler' from the elements in
'vector'.
Piggyback a slightly simpler way to build a list of num_chars 0s.
Getting rid of warnings for a CI check.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Accidentally passed two arguments instead of one. Fixes this pylint
error:
arch/x86/gen_idt.py:132:8: E1121: Too many positional arguments for
function call (too-many-function-args)
Fixing pylint warning for a CI check.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Fix this warning, as a preparation for a CI check:
arch/common/gen_isr_tables.py:167:11: C0123: Using type() instead of
isinstance() for a typecheck. (unidiomatic-typecheck)
isinstance() has the advantage that it also handles inheritance, though
it doesn't really matter here. It's more common at least.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Getting slightly subjective, but fixes this pylint warning:
arch/x86/gen_idt.py:281:11: R1714: Consider merging these
comparisons with "in" to 'handler not in (spur_code, spur_nocode)'
(consider-using-in)
Getting rid of pylint warnings for a CI check. I could disable any
controversial ones (it's already a list of warnings to enable anyway).
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Promote a handy and often-overlooked sys.exit() feature: Passing it a
string (or any other non-int object) prints it to stderr and exits with
status 1.
See the documentation at
https://docs.python.org/3/library/sys.html#sys.exit.
This indirectly prints some errors to stderr that previously went to
stdout.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
This adds a simple infinite loop when double exception is raised.
Without this, if double exception occurs, it would execute
arbitrary code.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This follows the z_arch_irq_en-/dis-able() so that the SoC
definitions are responsible for functions related to multi-level
interrupts.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Currently, the interrupt service code manually raises the CPU task
priority to the priority level of the vector being serviced to defer
any lower-priority interrupts. This is unnecessary; the local APIC
is aware that an interrupt is in-service and accounts for its priority
when deciding whether to issue an overriding interrupt to the CPU.
Signed-off-by: Charles E. Youse <charles@gnuless.org>
Use the 'not in' operator. Fixes this pylint warning:
arch/xtensa/core/xtensa_intgen.py:77:7: C0113: Consider changing
"not lvl in ints_by_lvl" to "lvl not in ints_by_lvl" (unneeded-not)
Fixing pylint warnings for a CI check.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Reported by pylint's 'bad-whitespace' warning.
Not gonna enable this warning in the CI check, because it flags stuff
like deliberately aligning assignments and gets too cultish. Just a
cleanup pass.
For whatever reason, the common convention in Python is to skip spaces
around '=' when passing keyword arguments and giving default arguments:
f(x=3, y=4)
def f(x, y=8):
...
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
The code in question is very non-trivial so without good explanation
it takes a lot of time to realize what's done there and why
it still works in the end.
Here I'm trying to save a couple of man-days for the next developers
who's going to touch that piece of code.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
This commit makes it possible to infer Z_ARCH_EXCEPT()
calls in SVCs that escalate to HardFault due to being
invoked from priority level equal or higher to the
interrupt priority level of the SVC Handler.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
commit 780324b8ed ("cleanup: rename fiber/task -> thread")
seems to be done by a script and in that particular case turned
menaingful sentence into nonsense. Alas, threads might be in all
four states.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Anas Nashif <anas.nashif@intel.com>
We manage IRQs in a quite a different way now since
commit f8d061faf7 ("arch: arc: add nested interrupt support")
so that comment not only makes no sense but also may fool a reader
as disabling of interrupts happens in the very beginning of
_rirq_exit() but not here.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
we should not rely on that eret has a copy of ilink in fast
irq handling. This will cause crash for hs cores.
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
For the old codes, if nest interrupts come out after _isr_wrapper
and before _check_nest_int_by_irq_act, then multi-bits in irq_act
will be set, this will result irq stack will not be switched in
correctly
As a fix, it's still need to use nest interrupt counter to do
interrupt stack switch as before
The difference is in the past exc_nest_count is used, but here
_kernel.nested/_kernel.cpus[cpu_id].nested is used.
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
* in arc secureshield interrupts can be configured
as secure or normal
* in sw design, high interrupt priorites are allocated to
secure world, low priorities are allocated to normal world.
* secure interrupt > secure thread > normal interrupt > normal
thead
So, here secure world/firmware only checks secure interrupt
priorities
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
it's not allowed to switch to thread preempted by exception as
its context is not saved.
So if a thread switch is required in exception handling, e.g.
kill a thread, the old thread cannot be switched back
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
For arc processor equiped with secureshield, SEC_STAT.IRM
bit should be recorded, it determins which mode irq should
return
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
Set the recommended thread stack size to 40 bytes in case a build is
made for a 64-bit native posix board
Signed-off-by: Jan Van Winkel <jan.van_winkel@dxplore.eu>
Update the xtensa backend to work better with the new fatal error
architecture. Move the stack frame dump (xtensa uses a variable-size
frame becuase we don't spill unused register windows, so it doesn't
strictly have an ESF struct) into z_xtensa_fatal_error(). Unify the
older exception logging with the newer one (they'd been sort of glomed
together in the recent rework), mostly using the asm2 code but with
the exception cause stringification and the PS register field
extraction from the older one.
Note that one shortcoming is that the way the dispatch code works, we
don't have access to the spilled frame from within the spurious error
handler, so this can't log the interrupted CPU state. This isn't
fixable easily without adding overhead to every interrupt entry, so it
needs to stay the way it is for now. Longer term we could exract the
caller frame from the window state and figure it out with some
elaborate assembly, I guess.
Fixes#18140
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
It was discovered that the xtensa version of
z_arch_irq_connect_dynamic() was being removed along with the old
xtensa architecture support, because it was never included in the asm2
builds.
But there's no xtensa-specific code in it at all. Architectures that
use the existing sw_isr_table mechanism and don't (or can't, in the
case of xtensa which has fixed interrupt priority) interpret the other
parameters might as well have access to a working generic
implementation.
Fixes#18272
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Consistently place C++ use of extern "C" after all include directives,
within the negative branch of _ASMLANGUAGE if used.
Remove extern "C" support from files that don't declare objects or
functions.
In arch/arc/arch.h the extern "C" in the including context is left
active during an include to avoid more complex restructuring.
Background from issue #17997:
Declarations that use C linkage should be placed within extern "C"
so the language linkage is correct when the header is included by
a C++ compiler.
Similarly #include directives should be outside the extern "C" to
ensure the language-specific default linkage is applied to any
declarations provided by the included header.
See: https://en.cppreference.com/w/cpp/language/language_linkage
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Consistently place C++ use of extern "C" after all include directives,
within the negative branch of _ASMLANGUAGE if used.
Remove extern "C" support from files that don't declare objects or
functions.
Background from issue #17997:
Declarations that use C linkage should be placed within extern "C"
so the language linkage is correct when the header is included by
a C++ compiler.
Similarly #include directives should be outside the extern "C" to
ensure the language-specific default linkage is applied to any
declarations provided by the included header.
See: https://en.cppreference.com/w/cpp/language/language_linkage
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Consistently place C++ use of extern "C" after all include directives,
within the negative branch of _ASMLANGUAGE if used.
Background from issue #17997:
Declarations that use C linkage should be placed within extern "C"
so the language linkage is correct when the header is included by
a C++ compiler.
Similarly #include directives should be outside the extern "C" to
ensure the language-specific default linkage is applied to any
declarations provided by the included header.
See: https://en.cppreference.com/w/cpp/language/language_linkage
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Consistently place C++ use of extern "C" after all include directives,
within the negative branch of _ASMLANGUAGE if used.
In arch.h the extern "C" in the including context is left active during
include of target-specific mpu headers to avoid more complex
restructuring.
Background from issue #17997:
Declarations that use C linkage should be placed within extern "C"
so the language linkage is correct when the header is included by
a C++ compiler.
Similarly #include directives should be outside the extern "C" to
ensure the language-specific default linkage is applied to any
declarations provided by the included header.
See: https://en.cppreference.com/w/cpp/language/language_linkage
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Consistently place C++ use of extern "C" after all include directives,
within the negative branch of _ASMLANGUAGE if used.
Background from issue #17997:
Declarations that use C linkage should be placed within extern "C"
so the language linkage is correct when the header is included by
a C++ compiler.
Similarly #include directives should be outside the extern "C" to
ensure the language-specific default linkage is applied to any
declarations provided by the included header.
See: https://en.cppreference.com/w/cpp/language/language_linkage
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
'recoverable' is a value passed by reference and we
should be dereferencing the pointer, to check if the
fault has been classified as recoverable.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Consistently place C++ use of extern "C" after all include directives,
within the negative branch of _ASMLANGUAGE if used.
Remove extern "C" support from files that don't declare objects or
functions.
Background from issue #17997:
Declarations that use C linkage should be placed within extern "C"
so the language linkage is correct when the header is included by
a C++ compiler.
Similarly #include directives should be outside the extern "C" to
ensure the language-specific default linkage is applied to any
declarations provided by the included header.
See: https://en.cppreference.com/w/cpp/language/language_linkage
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
SR and LR were used as global names for load and store RISC-V assembler
operations, colliding with other uses such as SR for STATUS REGISTER in
some peripherals. Renamed them to a longer more specific name to avoid
the collision.
Signed-off-by: Karsten Koenig <karsten.koenig.030@gmail.com>
When coming out of an exception, we need to mask interrupts
to avoid races when decrementing the nested count. Move
the instruction that does this earlier.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Related to #17997, for the POSIX arch:
* Remove some unnecessary extern "C" and ifdef blocks
* Move an include out of one of these blocks
* Add a missing extern "C" block
Background:
Declarations that use C linkage should be placed within extern "C"
so the language linkage is correct when the header is included by
a C++ compiler.
Similarly #include directives should be outside the extern "C" to
ensure the language-specific default linkage is applied to any
declarations provided by the included header.
See: https://en.cppreference.com/w/cpp/language/language_linkage
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
* it's based on ARC SecureShield
* add basic secure service in arch/arc/core/secureshield
* necesssary changes in arch level
* thread switch
* irq/exception handling
* initialization
* add secure time support
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
according to high-level design,in user mode software-triggered system
fatal exceptions only allow oops and stack check failure
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
exception, different with irq offload, may be raised interrupt
handling, e.g.
* z_check_stack_sentinel
* wrong code
we need to add specific handling of this case in exception handling
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
