Ensure when both RTEMS_DEBUG is specified and pointers are large that
enough space is allocated to accomodate the Per_CPU_Control structure.
This changes the calculation to be more compositional instead of trying
to list out every permutation of options possible.
---
cpukit/include/rtems/score/per
These lines were accidentally committed with a leading + which resulted
in them being non-functional. This restores them to functionality such
that the patch gets downloaded and applied appropriately.
---
rtems/config/tools/rtems-gcc-10-newlib-head.cfg | 4 ++--
1 file changed, 2 insertions(+), 2
Fixing the debug mask flag broke nested interrupts. This restores that
functionality.
---
bsps/aarch64/include/dev/irq/arm-gic-arch.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/bsps/aarch64/include/dev/irq/arm-gic-arch.h
b/bsps/aarch64/include/dev/irq/arm-gic-arch.h
in
This adds the documentation for the application configuration option
CONFIGURE_EXCEPTION_TO_SIGNAL_MAPPING.
---
c-user/config/device-driver.rst | 30 ++
1 file changed, 30 insertions(+)
diff --git a/c-user/config/device-driver.rst b/c-user/config/device-driver.rst
inde
---
spec/acfg/if/exception-to-signal-mapping.yml | 22
1 file changed, 22 insertions(+)
create mode 100644 spec/acfg/if/exception-to-signal-mapping.yml
diff --git a/spec/acfg/if/exception-to-signal-mapping.yml
b/spec/acfg/if/exception-to-signal-mapping.yml
new file mode 100
AArch64 now supports SMP for the Xilinx ZynqMP BSP family.
---
cpu-supplement/aarch64.rst | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/cpu-supplement/aarch64.rst b/cpu-supplement/aarch64.rst
index a102817..2b3d620 100644
--- a/cpu-supplement/aarch64.rst
+++ b/cpu-suppl
This adds support for libdebugger under AArch64 using software
breakpoints and the single-step execution mode present in all AArch64
CPUs.
---
bsps/aarch64/include/bsp/aarch64-mmu.h | 11 +
cpukit/libdebugger/rtems-debugger-aarch64.c | 1884 +++
spec/build/cpukit/libdebugger
The N used in the breakpoint and watchpoint register names is intended
to be an integer between 0 and 15 (inclusive) and will not compile when
used as is. This adds the accessors necessary to access all of these
breakpoint and watchpoint registers.
---
.../rtems/score/aarch64-system-registers.h
Debug events should be masked at least until after the first context
switch and should usually be masked until a debugger is attached for
application debugging.
---
bsps/aarch64/shared/start/start.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/bsps/aarch64/shared/start/s
The existing code is functional but inccorrect and blindly modifies the
other masking bits. It is important to preserve those other bits since
they control masking of important system events.
---
bsps/aarch64/include/dev/irq/arm-gic-arch.h | 2 +-
cpukit/score/cpu/aarch64/cpu.c | 16
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSBSPsAArch64Shared
+ *
+ * @brief AArch64 MMU dummy implementation.
+ */
+
+/*
+ * Copyright (C) 2021 On-Line Applications Research Corporation (OAR)
+ * Written by Kinsey Moore
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * m
Certain input parameters for MMU mapping operations could cause an
infinite recursion if block end boundaries didn't align to 4k. This
ensures that recursion descent does not exceed 2 levels and instead
rounds up to the nearest 4k block if necessary.
---
bsps/aarch64/include/bsp/aarch64-mmu.h | 9
Use uintptr_t instead of DB_UINT when the variable in question describes
a pointer.
---
cpukit/libdebugger/rtems-debugger-i386.c| 12 ++--
cpukit/libdebugger/rtems-debugger-target.c | 2 +-
cpukit/libdebugger/rtems-debugger-target.h | 10 +-
cpukit/libdebugger/rtems-debugger
Compare the function result instead of the function pointer for non-SMP
builds.
---
cpukit/score/src/exceptionmapping.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cpukit/score/src/exceptionmapping.c
b/cpukit/score/src/exceptionmapping.c
index 1baa047eb7..19f04cc31d 100644
This patch set adds libdebugger support to AArch64 and resolves several
bugs found along the way.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
On 10/29/2021 10:42, Sebastian Huber wrote:
On 28/10/2021 23:11, Kinsey Moore wrote:
Updates from previous patch set:
* moved raise to a post-switch action
* prevented mapping from occurring before the first context switch
* adjusted the api according to suggestions
Thanks, the patch set
Add a test to verify that mapping of machine exceptions to POSIX signals
operates properly when the application requests it.
---
spec/build/testsuites/psxtests/grp.yml| 2 +
.../build/testsuites/psxtests/psxsignal09.yml | 22 ++
testsuites/psxtests/psxsignal09/init.c| 73 +
cpukit/score/src/exceptionmapping.c
@@ -0,0 +1,104 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSScoreExceptionMapping
+ *
+ * @brief AArch64 machine exception to POSIX signal mapping.
+ */
+
+/*
+ * Copyright (C) 2021 On-Line Applications Rese
This adds the set of functions necessary to allow more generic handling
of machine exceptions. This initial patch offers the ability to
manipulate a CPU_Exception_frame and resume execution using that
exception information with or without thread dispatch. These functions
are gated behind the RTEMS_
Add a test to verify that intercepted exceptions can be resolved and
execution can be resumed.
---
spec/build/testsuites/sptests/grp.yml | 2 +
spec/build/testsuites/sptests/spfatal35.yml | 20 +
testsuites/sptests/spfatal35/init.c | 89 +
testsuites/sptests/
This adds the function implementations necessary to add exception
extensions support to AArch64.
---
.../cpu/aarch64/aarch64-exception-default.S | 131 +-
.../cpu/aarch64/aarch64-exception-default.c | 59 ++-
.../cpu/aarch64/aarch64-exception-interrupt.S | 165
Updates from previous patch set:
* moved raise to a post-switch action
* prevented mapping from occurring before the first context switch
* adjusted the api according to suggestions
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/l
On 10/28/2021 01:02, Sebastian Huber wrote:
On 27/10/2021 23:44, Kinsey Moore wrote:
+/*
+ * Exception handler. Map the exception class to SIGFPE, SIGSEGV
+ * or SIGILL for Ada or other runtimes.
+ */
+void _Exception_Raise_signal(
+ Internal_errors_Source source,
+ bool
On 10/28/2021 00:51, Sebastian Huber wrote:
On 27/10/2021 23:44, Kinsey Moore wrote:
This patch set is a rework of the previous Exception Management API
patch set based on feedback from the community. From the last revision:
* Everything has been moved out of the RTEMS Classic API namespace
On 10/28/2021 01:00, Sebastian Huber wrote:
On 27/10/2021 23:44, Kinsey Moore wrote:
This adds the set of functions necessary to allow more generic handling
of machine exceptions. This initial patch offers the ability to
manipulate a CPU_Exception_frame and resume execution using that
Add a test to verify that mapping of machine exceptions to POSIX signals
operates properly when the application requests it.
---
spec/build/testsuites/psxtests/grp.yml| 2 +
.../build/testsuites/psxtests/psxsignal09.yml | 22 ++
testsuites/psxtests/psxsignal09/init.c| 73 +
+++ b/cpukit/score/src/exceptionmapping.c
@@ -0,0 +1,77 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSScoreExceptionMapping
+ *
+ * @brief AArch64 machine exception to POSIX signal mapping.
+ */
+
+/*
+ * Copyright (C) 2021 On-Line Applications Rese
Add a test to verify that intercepted exceptions can be resolved and
execution can be resumed.
---
spec/build/testsuites/sptests/grp.yml | 2 +
spec/build/testsuites/sptests/spfatal35.yml | 20 +
testsuites/sptests/spfatal35/init.c | 89 +
testsuites/sptests/
This adds the calls and support functions necessary to add exception
extensions support to AArch64.
---
.../cpu/aarch64/aarch64-exception-default.S | 131 +-
.../cpu/aarch64/aarch64-exception-default.c | 59 ++-
.../cpu/aarch64/aarch64-exception-interrupt.S | 165 +
This patch set is a rework of the previous Exception Management API
patch set based on feedback from the community. From the last revision:
* Everything has been moved out of the RTEMS Classic API namespace
* The concept of exception classes have been removed in favor of a
direct CPU_Exception_fr
This adds the set of functions necessary to allow more generic handling
of machine exceptions. This initial patch offers the ability to
manipulate a CPU_Exception_frame and resume execution using that
exception information with or without thread dispatch. These functions
are gated behind the RTEMS_
Looks good.
On 10/19/2021 22:16, chr...@rtems.org wrote:
From: Chris Johns
---
libbsd.py | 1 +
rtemsbsd/include/bsp/nexus-devices.h | 9 +
.../include/machine/rtems-bsd-nexus-bus.h | 28 +++
rtemsbsd/sys/arm64/xilinx/versal_slcr.c
Looks good.
On 10/19/2021 22:16, chr...@rtems.org wrote:
From: Chris Johns
- memset may be optimized for performance and might work
with device type memory. Clear a byte at a time.
---
rtemsbsd/rtems/rtems-kernel-bus-dma.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
d
Thanks for this fix. It had been on my todo list for a while now.
Kinsey
On 10/19/2021 22:16, chr...@rtems.org wrote:
From: Chris Johns
- This change lets you rebuild libbsd after it is installed
---
waf_libbsd.py | 29 +
1 file changed, 21 insertions(+), 8 del
The spconfig01 and spmisc01 tests were disabled for all AArch64 BSPs due
to a toolchain issue preventing them from compiling correctly. The
binutils version that contains the fix has been released and integrated
into RSB such that these two tests now build and operate correctly.
---
spec/build/bsp
On 10/18/2021 00:44, Chris Johns wrote:
Hi,
I cannot run libbsd on real hardware because the cadence rx descriptor cache
coherent allocation crashes in `memset`. It is used to clear the memory.
The rtemsbsd allocator call optionally clears the memory and it seems the newlib
aarch64 memset code
Comments below.
On 10/16/2021 15:12, Gedare Bloom wrote:
---
bsps/shared/start/bspreset-arm-psci.c | 20
1 file changed, 20 insertions(+)
diff --git a/bsps/shared/start/bspreset-arm-psci.c
b/bsps/shared/start/bspreset-arm-psci.c
index 215be5c9b5..bafdfe6299 100644
--- a
Comments inline below.
On 10/16/2021 15:12, Gedare Bloom wrote:
---
cpukit/score/cpu/aarch64/aarch64-smc.c| 72
.../aarch64/include/rtems/score/aarch64-smc.h | 84 +++
spec/build/cpukit/cpuaarch64.yml | 2 +
3 files changed, 158 inserti
On 10/14/2021 10:18, Joel Sherrill wrote:
On Thu, Oct 14, 2021 at 9:56 AM Kinsey Moore wrote:
On 10/14/2021 01:40, Chris Johns wrote:
Hi,
I have come across this define in zynqmp_slcr.h:
#define ZYNQMP_DEFAULT_PS_CLK_FREQUENCY
What if the cpu freq is changed by a user? If this
On 10/14/2021 01:40, Chris Johns wrote:
Hi,
I have come across this define in zynqmp_slcr.h:
#define ZYNQMP_DEFAULT_PS_CLK_FREQUENCY
What if the cpu freq is changed by a user? If this value still valid?
If CPU frequency scaling is used, I believe this value remains
unchanged. This is
When the cmpset and fcmpset functions were refactored, the return value
of the operation was discarded instead of being returned for SMP builds
outside of gcc 4.x. This had the effect of turning these functions into
a long busywait loop that eventually failed due to integer overflow.
This patch re
There was a typo in the patch that added the HAVE_ definition
that prevented "./waf configure" from succeeding. This adds the missing
character.
---
waf_libbsd.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/waf_libbsd.py b/waf_libbsd.py
index 613797aa..9e3724d6 100644
--- a
On 10/5/2021 02:48, Chris Johns wrote:
On 5/10/21 10:27 am, Kinsey Moore wrote:
Currently debugger01 is the only user of the test-if-library in libbsd and it
doesn't seem to work as expected. The configure step that detects libdebugger
occurs and succeeds as it should for the zynq a9 qem
Conditionally compiled tests (consisting only of debugger01) were not
compiling as expected when libdebugger was present. This appears to have
occurred during the transition from header detection or due to an
intervening change in the waf internal libraries. The result of
check_cc() is the only loc
Currently debugger01 is the only user of the test-if-library in libbsd
and it doesn't seem to work as expected. The configure step that detects
libdebugger occurs and succeeds as it should for the zynq a9 qemu BSP,
but debugger01.exe never gets compiled. I found this behavior while
working on t
On 10/1/2021 08:29, Sebastian Huber wrote:
On 01/10/2021 06:39, Gedare Bloom wrote:
You also might separate the exception manager addition away from the
topic of recoverable exceptions. This introduces/extends the classic
API, so it needs to be vetted carefully. Although the new header
claims to
On 9/30/2021 23:24, Gedare Bloom wrote:
If the rest of the patch set isn't ready, please split this out for
separate submission. It looks fine to me.
It appears not. I'll go ahead and get this patch committed and remove it
from the set.
Thanks,
Kinsey
_
Context validation for AArch64 was ported from the ARM implementation
without a reinterpretation of the actual requirements. The spcontext01
test just happened to pass because the set of scratch registers in ARM
is a subset of the scratch registers in AArch64.
---
.../cpu/aarch64/aarch64-context-v
On 9/22/2021 21:06, Chris Johns wrote:
On 23/9/21 10:16 am, Kinsey Moore wrote:
This adds a confdef option allowing an application to request mapping
machine exceptions to POSIX signals. This is required for some languages
such as Ada.> --- a/cpukit/include/rtems/confdefs/extensions.h
++
Add a test to verify that mapping of machine exceptions to POSIX signals
operates properly when the application requests it.
---
spec/build/testsuites/psxtests/grp.yml| 2 +
.../build/testsuites/psxtests/psxsignal09.yml | 22 ++
testsuites/psxtests/psxsignal09/init.c| 73 +
cense-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSScoreExceptionMapping
+ *
+ * @brief AArch64 machine exception to POSIX signal mapping.
+ */
+
+/*
+ * Copyright (C) 2021 On-Line Applications Research Corporation (OAR)
+ * Written by Kinsey Moore
+ *
+ * Redistribution and
All other architectures use uint32_t for interrupt levels and there is
no reason not to do so on AArch64.
---
cpukit/score/cpu/aarch64/cpu.c | 4 ++--
cpukit/score/cpu/aarch64/include/rtems/score/cpu.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/cpu
This adds the call and support functions necessary to add Exception
Manager support to AArch64.
---
.../cpu/aarch64/aarch64-exception-default.S | 81 +
.../cpu/aarch64/aarch64-exception-default.c | 62 +++
.../cpu/aarch64/aarch64-exception-interrupt.S | 165 ++
sp
Add a test to verify that intercepted exceptions can be resolved and
execution can be resumed.
---
spec/build/testsuites/sptests/grp.yml | 2 +
spec/build/testsuites/sptests/spfatal35.yml | 20 +
testsuites/sptests/spfatal35/init.c | 93 +
testsuites/sptests/
This adds the framework necessary to allow more generic handling of
machine exceptions. This initial patch offers the ability to get the
class of exception from the CPU_Exception_frame provided. Future
extensions of the Exception Manager could include the ability to get
the address of the exception
This is a reworked patch set for management of recoverable exceptions.
The assembly that would have followed the exception handler has been
moved to a pair of epilogue functions to avoid the appearance of dead
code following the fatal error handlers and the signal mapping code has
been refactored i
When Joel was looking over his build scripts, he noticed that ERC32 is listed
in spec/build/cpukit/optsmp.yml as supporting SMP and yet he isn't aware of any
ERC32 hardware that was multicore. LEON2 isn't listed there, but has a SMP stub
that gets linked in with it. It appears that SPARC is the
On 9/21/2021 00:52, Sebastian Huber wrote:
On 21/09/2021 02:15, Gedare Bloom wrote:
looks good, thanks. I'll follow-up later as I make progress on the
versal smp side too. that's still a bit broken.
On Mon, Sep 20, 2021 at 4:56 PM Kinsey
Moore wrote:
Version 1 of this patch did
Version 1 of this patch did not update the Versal BSP's usage of the MMU
calls.
Kinsey
On 9/20/2021 17:43, Kinsey Moore wrote:
This adds SMP support for AArch64 in cpukit and for the ZynqMP BSPs.
---
bsps/aarch64/include/bsp/aarch64-mmu.h| 13 ++-
bsps/aarch64/shared/start/aa
RTEMSBSPsAArch64Shared
+ *
+ * @brief SMP startup and interop code.
+ */
+
+/*
+ * Copyright (C) 2021 On-Line Applications Research Corporation (OAR)
+ * Written by Kinsey Moore
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the
interop code.
+ */
+
+/*
+ * Copyright (C) 2021 On-Line Applications Research Corporation (OAR)
+ * Written by Kinsey Moore
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1
/irq/arm-gicv2-zynqmp.c
@@ -0,0 +1,76 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSBSPsShared
+ *
+ * @brief This source file contains the interrupt get attribute implementation.
+ */
+
+/*
+ * Copyright (C) 2021 On-Line Applications Research Corporation (OAR
GICv2 can support up to 1024 interrupts, but ZynqMP hardware is only
configured for 192 interrupts.
---
bsps/aarch64/xilinx-zynqmp/include/bsp/irq.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bsps/aarch64/xilinx-zynqmp/include/bsp/irq.h
b/bsps/aarch64/xilinx-zynqmp/includ
The order in which step checks for 1 and 2 are not rigidly defined and
may actually occur in either order depending on how the threads execute.
This waits for the job to complete to enforce the existing ordering.
---
testsuites/smptests/smpmulticast01/init.c | 1 +
1 file changed, 1 insertion(+)
Corporation (OAR)
+ * Written by Kinsey Moore
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list
On 9/17/2021 00:39, Sebastian Huber wrote:
On 16/09/2021 22:50, Kinsey Moore wrote:
There is currently a narrow window between the CPU state being set to UP
and the dispatch disable flag being set. It is possible to perform a
cross-processor thread dispatch in this window which catches the CPU
There is currently a narrow window between the CPU state being set to UP
and the dispatch disable flag being set. It is possible to perform a
cross-processor thread dispatch in this window which catches the CPU in
a state which is not actually fully ready for that type of thread
dispatch.
This mov
Comment below.
On 9/6/2021 23:38, chr...@rtems.org wrote:
From: Chris Johns
- Only reset if the bootloader error is hardware related.
---
tester/rtems/testing/bsps/xilinx_zynqmp_ilp32_zu3eg.ini | 2 +-
tester/rtems/testing/bsps/xilinx_zynqmp_lp64_zu3eg.ini | 2 +-
2 files changed, 2 inser
Looks good.
On 9/6/2021 23:31, chr...@rtems.org wrote:
From: Chris Johns
---
tester/rtems/testing/bsps/xilinx_zynqmp_lp64_zu3eg.ini | 1 +
1 file changed, 1 insertion(+)
diff --git a/tester/rtems/testing/bsps/xilinx_zynqmp_lp64_zu3eg.ini
b/tester/rtems/testing/bsps/xilinx_zynqmp_lp64_zu3e
Looks good to me.
On 9/6/2021 23:31, chr...@rtems.org wrote:
From: Chris Johns
- Limit the reopen to once a second
- Make sure the socket is closed when reopening
---
tester/rt/telnet.py | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/tester/rt/telnet.py b/tes
Looks good to me.
On 9/6/2021 23:31, chr...@rtems.org wrote:
From: Chris Johns
- Fix data decoding
- Fix get MAC call
---
misc/tools/tftpproxy.py | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/misc/tools/tftpproxy.py b/misc/tools/tftpproxy.py
index c0aebb
Patch looks good except for one comment below.
On 9/6/2021 23:31, chr...@rtems.org wrote:
From: Chris Johns
- Remove the hard tester error and count the header errors.
---
tester/rt/config.py | 2 +-
tester/rt/report.py | 32 +++-
tester/rt/test.py | 7 +
I know of someone who has run this BSP on hardware and I'm not aware of
any usage with xen (though it could very well be the case). It really
needs more documentation which is something I guess I should sit down
and do at some point. The ILP32 AArch64 BSP isn't a direct replacement
for this BSP
These two patches look good with one minor nit below.
On 9/5/2021 02:57, chr...@rtems.org wrote:
From: Chris Johns
- Remove the hard tester error and count the header errors.
---
tester/rt/report.py | 17 +
tester/rt/test.py | 7 +--
2 files changed, 18 insertions(+)
This change looks good.
On 9/2/2021 04:21, Sebastian Huber wrote:
Declaring functions used only through function pointers as inline makes
absolutely no sense at all.
---
eng/coding-conventions.rst | 2 --
1 file changed, 2 deletions(-)
diff --git a/eng/coding-conventions.rst b/eng/coding-con
On 9/1/2021 10:58, Sebastian Huber wrote:
On 01/09/2021 17:48, Sebastian Huber wrote:
So, my proposal would be something like this:
1. Processor jumps to exception prologue
2. Exception prologue saves the context to CPU exception frame
3. Exception prologue calls rtems_fatal() which does not
On 8/31/2021 18:00, Chris Johns wrote:
On 31/8/21 6:30 pm, Sebastian Huber wrote:
On 31/08/2021 09:00, Chris Johns wrote:
On 31/8/21 3:20 pm, Sebastian Huber wrote:
On 30/08/2021 20:32, Kinsey Moore wrote:
On 8/30/2021 12:12, Sebastian Huber wrote:
On 24/08/2021 20:45, Kinsey Moore wrote
On 8/31/2021 17:50, Chris Johns wrote:
On 31/8/21 11:35 pm, Kinsey Moore wrote:
On 8/31/2021 04:31, Sebastian Huber wrote:
On 30/08/2021 17:13, Kinsey Moore wrote:
On 8/30/2021 07:50, Sebastian Huber wrote:
On 30/08/2021 14:27, Kinsey Moore wrote:
On 8/30/2021 00:42, Sebastian Huber wrote
On 8/31/2021 04:31, Sebastian Huber wrote:
On 30/08/2021 17:13, Kinsey Moore wrote:
On 8/30/2021 07:50, Sebastian Huber wrote:
On 30/08/2021 14:27, Kinsey Moore wrote:
On 8/30/2021 00:42, Sebastian Huber wrote:
Hello Kinsey,
why can't you use the existing fatal error extension for this
On 8/30/2021 00:42, Sebastian Huber wrote:
Hello Kinsey,
why can't you use the existing fatal error extension for this? You just have to
test for an RTEMS_FATAL_SOURCE_EXTENSION source. The fatal code is a pointer
to the exception frame.
Unfortunately, the fatal error extensions framework n
On 8/30/2021 07:50, Sebastian Huber wrote:
On 30/08/2021 14:27, Kinsey Moore wrote:
On 8/30/2021 00:42, Sebastian Huber wrote:
Hello Kinsey,
why can't you use the existing fatal error extension for this? You
just have to test for an RTEMS_FATAL_SOURCE_EXTENSION source. The
fatal code
On 8/30/2021 12:12, Sebastian Huber wrote:
On 24/08/2021 20:45, Kinsey Moore wrote:
diff --git a/tester/rtems/testing/bsps/a53_ilp32_qemu.ini
b/tester/rtems/testing/bsps/a53_ilp32_qemu.ini
index 3beba06..581c59c 100644
--- a/tester/rtems/testing/bsps/a53_ilp32_qemu.ini
+++ b/tester/rtems
On 8/27/2021 19:04, Chris Johns wrote:
On 24/8/21 10:34 pm, Kinsey Moore wrote:
On 8/23/2021 21:41, Chris Johns wrote:
On 24/8/21 9:50 am, Kinsey Moore wrote:
This patch set contains the result of the Exception Manager work I
proposed a while back to manage handling of machine exceptions
On 8/27/2021 19:01, Chris Johns wrote:
On 27/8/21 9:36 am, Kinsey Moore wrote:
Since I'm working on SMP and I've had some of those tests failing
sporadically
as well, I took a dive into smpschededf01.exe on AArch64 and the issue that
particular test seems to be encountering is
On 8/20/2021 22:06, Chris Johns wrote:
On 21/8/21 2:38 am, Kinsey Moore wrote:
On 8/19/2021 18:03, Chris Johns wrote:
On 20/8/21 4:55 am, Kinsey Moore wrote:
On 8/19/2021 13:32, Gedare Bloom wrote:
On Thu, Aug 19, 2021 at 11:43 AM Kinsey Moore wrote:
I've seen these failures on my
There is an emulation problem between RTEMS and QEMU that causes several
sets of tests to fail in circumstances where there is high load on the
host machine. Running multiple instances of QEMU simultaneously
exacerbates this problem which includes all of the spintrcritical tests,
psx12, and some of
On 8/23/2021 21:41, Chris Johns wrote:
On 24/8/21 9:50 am, Kinsey Moore wrote:
This patch set contains the result of the Exception Manager work I
proposed a while back to manage handling of machine exceptions along
with a general feature for mapping exceptions to POSIX signals without
delving
Add a test to verify that mapping of machine exceptions to POSIX signals
operates properly when the application requests it.
---
spec/build/testsuites/psxtests/grp.yml| 2 +
.../build/testsuites/psxtests/psxsignal09.yml | 22 ++
testsuites/psxtests/psxsignal09/init.c| 73 +
+ * Copyright (C) 2021 On-Line Applications Research Corporation (OAR)
+ * Written by Kinsey Moore
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code m
This adds the call and support functions necessary to add Exception
Manager support to AArch64.
---
.../cpu/aarch64/aarch64-exception-default.S | 50 +
.../cpu/aarch64/aarch64-exception-default.c | 55 ++-
.../cpu/aarch64/aarch64-exception-interrupt.S | 18 -
All other architectures use uint32_t for interrupt levels and there is
no reason not to do so on AArch64.
---
cpukit/score/cpu/aarch64/cpu.c | 4 ++--
cpukit/score/cpu/aarch64/include/rtems/score/cpu.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/cpu
This adds the framework necessary to allow more generic handling of
machine exceptions. This initial patch offers the ability to get the
class of exception from the CPU_Exception_frame provided. Future
extensions of the Exception Manager could include the ability to get
the address of the exception
This patch set contains the result of the Exception Manager work I
proposed a while back to manage handling of machine exceptions along
with a general feature for mapping exceptions to POSIX signals without
delving into the CPU Port-specific details. This is a pretty basic
initial implementation, b
On 8/19/2021 18:03, Chris Johns wrote:
On 20/8/21 4:55 am, Kinsey Moore wrote:
On 8/19/2021 13:32, Gedare Bloom wrote:
On Thu, Aug 19, 2021 at 11:43 AM Kinsey Moore wrote:
I've seen these failures on my local system, in our CI, and on a build
server that I sometimes
use for develo
On 8/19/2021 13:32, Gedare Bloom wrote:
On Thu, Aug 19, 2021 at 11:43 AM Kinsey Moore wrote:
I've seen these failures on my local system, in our CI, and on a build
server that I sometimes
use for development/testing so if it's a configuration issue we're being
pretty c
I've seen these failures on my local system, in our CI, and on a build
server that I sometimes
use for development/testing so if it's a configuration issue we're being
pretty consistent about
misconfiguration across some pretty different environments (docker,
bare-metal, VM, different
OSs, diffe
On 8/18/2021 18:02, Chris Johns wrote:
On 19/8/21 5:49 am, Kinsey Moore wrote:
On 8/18/2021 13:20, Chris Johns wrote:
On 19/8/21 3:41 am, Kinsey Moore wrote:
This is functional on the ZynqMP board I currently have setup for testing and on
ZynqMP QEMU except for the data corruption/loss
On 8/18/2021 13:20, Chris Johns wrote:
On 19/8/21 3:41 am, Kinsey Moore wrote:
This is functional on the ZynqMP board I currently have setup for testing and on
ZynqMP QEMU except for the data corruption/loss caused by the removal of the
post-baud-set null write.
Thanks for the testing.
I am
This is functional on the ZynqMP board I currently have setup for
testing and on ZynqMP QEMU except for the data corruption/loss caused by
the removal of the post-baud-set null write.
Unrelated to this patch, I just realized that zynq_uart_set_attributes
needs a call to zynq_uart_reset_tx_flus
Looks good to me.
Kinsey
On 8/16/2021 05:27, pranav wrote:
---
user/bsps/arm/raspberrypi.rst | 51 ++-
1 file changed, 45 insertions(+), 6 deletions(-)
diff --git a/user/bsps/arm/raspberrypi.rst b/user/bsps/arm/raspberrypi.rst
index c26f4b5..11dcc30 100644
-
601 - 700 of 1009 matches
Mail list logo
