The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
Add support to record scheduler operations. This support is especially
important for tests in SMP configurations since the thread switch extension is
quite difficult to use due to the asynchronous nature of thread dispatching.
In contrast, the scheduler operations occur normally in a deterministic order.
Update #3716.
This function may be used to burn a couple of processor cycles with
minimum impact on the system bus. It may be used in busy wait loops.
Since it is a global function, it is possible to wrap it in device
driver test code.
When committed, the MicroBlaze RAM size was hard-coded to 16MB. This
changes the default to 256MB and sets the KCU105 BSPs to 2GB since that
is what the board has on it.
Add MicroBlaze support for libdebugger. This uses only software break
type instructions to provide self-hosted GDB debugging support for
applications since internal control of debug hardware is not possible.
Also of note, this implementation for MicroBlaze would typically use the
brki instruction for software break, but instead uses an illegal opcode
to manage software breaks as exceptions. This is due to poor interaction
with the debug hardware where the debug hardware will intercept software
breaks instead of allowing the software break vector to execute.
This patch adds a vector for debug events along with a hook similar to
the exception framework. The debug vector generates an exception frame
for use by libdebugger.
This patch updates the CPU_Exception_frame to include all necessary
registers, combines hardware snd software exception handlers into a
shared vector, provides an architecture-specific hook for taking
control of exception handling, and moves exception handling over to
actually using the CPU_Exception_frame instead of a minimal interrupt
stack frame. As the significant contents of _exception_handler.S have
been entirely rewritten, the copyright information on this file has been
updated to reflect that.
When the stack checker is not enabled, the stack checker reporting
function can still be called. This prevents that call from performing a
null memory access in trying to find the high water mark if the stack
checker was never initialized.
This also introduces a test to ensure this call does not cause a crash.
Closes#4588
GCC versions prior to 6.1 used a RTEMS thread model based on
rtems_gxx_*() functions. GCC version 6.1 or later uses the
self-contained synchronization objects of Newlib <sys/lock.h> for the
RTEMS thread model.
Remove the obsolete implementation.
Close#3143.
Most BSPs which used the stubbed benachmark timer provide a CPU counter.
All BSPs provide at least a stub CPU counter. Simply use the benchmark
timer implementation using the CPU counter.
Always start the executive in Exception Level 1, Non-Secure mode.
If we boot in EL3 Secure with GICv3 then we have to initialize
the distributor and redistributor to set up G1NS interrupts
early in the boot sequence before stepping down from EL3S to EL1NS.
Now there is no need to distinguish between secure and non-secure
world execution after the primary core boots, so get rid of the
AARCH64_IS_NONSECURE configuration option.
