[PATCH] validation: Improve IRQ handler dispatch test
Clarify wording. Use a function wrapper for the SMP spurious interrupt setup.
Update #3716.
---
.../testsuites/validation/validation-intr.yml | 3 +-
...sp-interrupt-handler-dispatch-unchecked.c} | 314 ++
2 files changed, 173 insertions(+), 144 deletions(-)
rename testsuites/validation/{tc-bsp-interrupt-spurious.c =>
tc-bsp-interrupt-handler-dispatch-unchecked.c} (50%)
diff --git a/spec/build/testsuites/validation/validation-intr.yml
b/spec/build/testsuites/validation/validation-intr.yml
index ced15b9490..dc4fc03a2d 100644
--- a/spec/build/testsuites/validation/validation-intr.yml
+++ b/spec/build/testsuites/validation/validation-intr.yml
@@ -10,9 +10,10 @@ features: c cprogram
includes: []
ldflags:
- -Wl,--wrap=bsp_interrupt_handler_default
+- -Wl,--wrap=bsp_interrupt_spurious
links: []
source:
-- testsuites/validation/tc-bsp-interrupt-spurious.c
+- testsuites/validation/tc-bsp-interrupt-handler-dispatch-unchecked.c
- testsuites/validation/tc-intr-clear.c
- testsuites/validation/tc-intr-entry-install.c
- testsuites/validation/tc-intr-entry-remove.c
diff --git a/testsuites/validation/tc-bsp-interrupt-spurious.c
b/testsuites/validation/tc-bsp-interrupt-handler-dispatch-unchecked.c
similarity index 50%
rename from testsuites/validation/tc-bsp-interrupt-spurious.c
rename to testsuites/validation/tc-bsp-interrupt-handler-dispatch-unchecked.c
index f1230cb7e0..f6cb5852f1 100644
--- a/testsuites/validation/tc-bsp-interrupt-spurious.c
+++ b/testsuites/validation/tc-bsp-interrupt-handler-dispatch-unchecked.c
@@ -3,11 +3,11 @@
/**
* @file
*
- * @ingroup RTEMSTestCaseBspReqInterruptSpurious
+ * @ingroup RTEMSTestCaseBspReqInterruptHandlerDispatchUnchecked
*/
/*
- * Copyright (C) 2021 embedded brains GmbH (http://www.embedded-brains.de)
+ * Copyright (C) 2021, 2023 embedded brains GmbH
(http://www.embedded-brains.de)
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
@@ -60,8 +60,8 @@
#include
/**
- * @defgroup RTEMSTestCaseBspReqInterruptSpurious \
- * spec:/bsp/req/interrupt-spurious
+ * @defgroup RTEMSTestCaseBspReqInterruptHandlerDispatchUnchecked \
+ * spec:/bsp/req/interrupt-handler-dispatch-unchecked
*
* @ingroup RTEMSTestSuiteTestsuitesValidationIntr
*
@@ -69,44 +69,45 @@
*/
typedef enum {
- BspReqInterruptSpurious_Pre_First_Null,
- BspReqInterruptSpurious_Pre_First_Entry,
- BspReqInterruptSpurious_Pre_First_NA
-} BspReqInterruptSpurious_Pre_First;
+ BspReqInterruptHandlerDispatchUnchecked_Pre_LoadFirst_Null,
+ BspReqInterruptHandlerDispatchUnchecked_Pre_LoadFirst_Entry,
+ BspReqInterruptHandlerDispatchUnchecked_Pre_LoadFirst_NA
+} BspReqInterruptHandlerDispatchUnchecked_Pre_LoadFirst;
typedef enum {
- BspReqInterruptSpurious_Pre_FirstAgain_Null,
- BspReqInterruptSpurious_Pre_FirstAgain_Entry,
- BspReqInterruptSpurious_Pre_FirstAgain_NA
-} BspReqInterruptSpurious_Pre_FirstAgain;
+ BspReqInterruptHandlerDispatchUnchecked_Pre_LoadFirstAgain_Null,
+ BspReqInterruptHandlerDispatchUnchecked_Pre_LoadFirstAgain_Entry,
+ BspReqInterruptHandlerDispatchUnchecked_Pre_LoadFirstAgain_NA
+} BspReqInterruptHandlerDispatchUnchecked_Pre_LoadFirstAgain;
typedef enum {
- BspReqInterruptSpurious_Post_Result_FatalError,
- BspReqInterruptSpurious_Post_Result_Dispatch,
- BspReqInterruptSpurious_Post_Result_NA
-} BspReqInterruptSpurious_Post_Result;
+ BspReqInterruptHandlerDispatchUnchecked_Post_Result_FatalError,
+ BspReqInterruptHandlerDispatchUnchecked_Post_Result_Dispatch,
+ BspReqInterruptHandlerDispatchUnchecked_Post_Result_NA
+} BspReqInterruptHandlerDispatchUnchecked_Post_Result;
typedef enum {
- BspReqInterruptSpurious_Post_FatalSource_SpuriousInterrupt,
- BspReqInterruptSpurious_Post_FatalSource_NA
-} BspReqInterruptSpurious_Post_FatalSource;
+ BspReqInterruptHandlerDispatchUnchecked_Post_FatalSource_SpuriousInterrupt,
+ BspReqInterruptHandlerDispatchUnchecked_Post_FatalSource_NA
+} BspReqInterruptHandlerDispatchUnchecked_Post_FatalSource;
typedef enum {
- BspReqInterruptSpurious_Post_FatalCode_Vector,
- BspReqInterruptSpurious_Post_FatalCode_NA
-} BspReqInterruptSpurious_Post_FatalCode;
+ BspReqInterruptHandlerDispatchUnchecked_Post_FatalCode_Vector,
+ BspReqInterruptHandlerDispatchUnchecked_Post_FatalCode_NA
+} BspReqInterruptHandlerDispatchUnchecked_Post_FatalCode;
typedef struct {
uint8_t Skip : 1;
- uint8_t Pre_First_NA : 1;
- uint8_t Pre_FirstAgain_NA : 1;
+ uint8_t Pre_LoadFirst_NA : 1;
+ uint8_t Pre_LoadFirstAgain_NA : 1;
uint8_t Post_Result : 2;
uint8_t Post_FatalSource : 1;
uint8_t Post_FatalCode : 1;
-} BspReqInterruptSpurious_Entry;
+} BspReqInterruptHandlerDispatchUnchecked_Entry;
/**
- * @brief Test context for spec:/bsp/req/interrupt-spurious test case.
+ * @brief Test context for spec:/bsp/req/interrupt-handler-dispatch-unchecked
+ * test case.
*/
typedef struct {
/**
@@ -192,7
[PATCH rtems-libbsd] CONTRIBUTING: Sharpen priority development goals
This patch tries to make the most important goals of LibBSD development more clear based on the results of the discussion on the mailing list: https://lists.rtems.org/pipermail/devel/2023-January/074164.html --- CONTRIBUTING.rst | 39 ++- 1 file changed, 30 insertions(+), 9 deletions(-) diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst index 0b6fc7a0..31561f6a 100644 --- a/CONTRIBUTING.rst +++ b/CONTRIBUTING.rst @@ -21,15 +21,36 @@ RTEMS specific support files, general guidelines on what modifications to the FreeBSD source are permitted, and some other topics. For building the library, see the `README `_. -Goals of the LibBSD activity are - -* provide functionality from FreeBSD to RTEMS, -* ease updating to future FreeBSD versions, -* ease tracking changes in FreeBSD code, -* minimize manual changes in FreeBSD code. - -We will work to push our changes upstream to the FreeBSD Project and minimize -changes required at each update point. +Every change to LibBSD has to consider the following points in groups of +descending priority: + +#. Real-time Impacts + Maintainability Loss + * LibBSD itself doesn't make any real time claims because it is basically + FreeBSD and they don't make any real time claims either. But all + development in LibBSD must make sure that the real time ability of the + RTEMS core system or the application is not affected. + * It's utterly important that LibBSD is simple to maintain. One of the most + important points for that is that upgrades to newer FreeBSD versions have + to be easy. +#. Transparency Loss + Modularity Loss + Code/RAM Size Increase + * LibBSD code should be easy to read and easy to debug. Changes should be + integrated in a way that are easy to understand. Of course that's a + subjective goal. As a general rule: If it adds lot's of extra code or even + more layers than already exist in FreeBSD, it's harder to understand. + * There are a number of methods used in LibBSD to make it modular. If you + add new functionality, use one of the existing methods to allow enabling or + disabling your module. For example make sure that the linker can remove + unused modules. If that doesn't work for your feature, try to use the + buildsets to allow to switch a module on or off. + * A lot of different hardware uses LibBSD as network or USB stack or maybe in + the future even only for other subsystems. Some of the targets have + hundreds of megabytes memory. Others can only have a few megabytes (like + the ATSAMV71). Make sure that changes don't increase the RAM / Flash size + of the default build so that it can't be used on the small targets. +#. Performance Loss + * There are applications, that require (for example) a high network + throughput or a fast storage access. Make sure to take that into account + if adding changes. What is in the Git Repository = -- 2.35.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: libbsd development policy clarification needed?
Hello Karel, On 2023-02-02 12:43, Karel Gardas wrote: Guys, recently I needed to work with RTEMS/NFS. As this is provided by libbsd I took this and following two sentences below from master branch description provided in README I took as granted that master does have all the features which are currently available and provided by the project: "This branch must be used for libbsd development. Back ports to the 6-freebsd-12 are allowed." I was surprised to be proven wrong then by Fabrizio here: https://devel.rtems.org/ticket/4723 and by later investigation which shows that 6-freebsd-12 branch accumulated NFS work by Chris done in 2021 which is not presented on master. I've investigated just NFS as this was my focus here. So if 6-freebsd-12 became development branch of some sort, then it would be great to have that clarified in the project README file to prevent users confusion? Or if the policy is still the same, then perhaps some branch sync is needed here? That currently is an open issue. Basically there is a pending patch set that should fix that since several months. But there is a disagreement about some of the changes in that patch set (and about the patches checked in to 6-freebsd-12). Therefore, it still hasn't been merged. If you want to know some more about the problematic points, I recommend reading this (long) thread: https://lists.rtems.org/pipermail/devel/2023-January/074164.html The statement that development has to happen on the master branch is still true. The master is intended to track the FreeBSD upstream development. Only changes on that branch are guaranteed to live through an upgrade to a newer base version of FreeBSD. It's very unfortunate, that there are some patches on the 6-freebsd-12 branch only. On the long term, that issue has to be resolved. Best regards Christian I'm fine with either way, as a user I just need clear not confusing project message... Thanks! Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- embedded brains GmbH Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 mobile: +49-176-152 206 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-lwip 3/3] rtemslwip/xil_shims: Improve error messages
The error message produced in the case of MMU mapping failures was
insufficient to track down the cause. This improves the out to assist
the user in tracking down the issue.
---
rtemslwip/zynqmp/xil_shims.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/rtemslwip/zynqmp/xil_shims.c b/rtemslwip/zynqmp/xil_shims.c
index 5284ded..f0b1b9b 100644
--- a/rtemslwip/zynqmp/xil_shims.c
+++ b/rtemslwip/zynqmp/xil_shims.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#define TWO_MB (2*1024*1024)
#define ONE_GB (1024*1024*1024)
@@ -45,8 +46,12 @@ void Xil_SetTlbAttributes( UINTPTR Addr, u64 attrib )
Addr < 0x1 ? TWO_MB : ONE_GB,
attrib
);
- if ( sc != RTEMS_SUCCESSFUL ) {
-printf("Failed setting TLB attribs on ptr %p: 0x%lx\n", Addr, attrib);
+ if ( sc == RTEMS_NO_MEMORY ) {
+printf("Out of memory setting MMU attributes on ptr %p: 0x%lx\n",
(void*)Addr, attrib);
+ } else if ( sc == RTEMS_INVALID_ADDRESS ) {
+printf("Attempted to set MMU attributes on invalid ptr %p: 0x%lx\n",
(void*)Addr, attrib);
+ } else if ( sc != RTEMS_SUCCESSFUL ) {
+printf("Failed setting MMU attributes on ptr %p: 0x%lx\n", (void*)Addr,
attrib);
}
}
--
2.30.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-lwip 1/3] rtemslwip: Remove sleep.h since RTEMS provides it
This is a result of the inclusion of the Xilinx driver framework in RTEMS. A compatible sleep.h is now installed by RTEMS. Previously, it was not present. --- rtemslwip/xilinx/sleep.h | 34 -- 1 file changed, 34 deletions(-) delete mode 100644 rtemslwip/xilinx/sleep.h diff --git a/rtemslwip/xilinx/sleep.h b/rtemslwip/xilinx/sleep.h deleted file mode 100644 index 4a4fbdf..000 --- a/rtemslwip/xilinx/sleep.h +++ /dev/null @@ -1,34 +0,0 @@ -/* - * Copyright (C) 2022 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 must retain the above copyright - *notice, this list of conditions and the following disclaimer. - * 2. Redistributions in binary form must reproduce the above copyright - *notice, this list of conditions and the following disclaimer in the - *documentation and/or other materials provided with the distribution. - * - * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" - * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE - * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE - * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE - * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR - * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF - * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS - * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN - * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) - * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE - * POSSIBILITY OF SUCH DAMAGE. - */ - -#ifndef SLEEP_H -#define SLEEP_H - -int usleep( ULONG useconds ); - -unsigned int sleep( u32 seconds ); - -#endif -- 2.30.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-lwip 2/3] rtemslwip: Resolve conflicts involving xparameters
RTEMS recently imported drivers and their support code from Xilinx. This has created a conflict with xparameters.h since it is now provided in both RTEMS and RTEMS-lwIP. This moves the definitions provided by xparameters.h in RTEMS-lwIP to xparameters_ps.h and adjusts its accessibility to cover the same use cases. --- rtemslwip/zynqmp/xemacps_g.c| 1 + rtemslwip/zynqmp/xparameters.h | 113 rtemslwip/zynqmp/xparameters_ps.h | 75 +++- rtemslwip/zynqmp_cfc400x/lwipbspopts.h | 2 + rtemslwip/zynqmp_hardware/lwipbspopts.h | 2 +- rtemslwip/zynqmp_qemu/lwipbspopts.h | 2 +- 6 files changed, 78 insertions(+), 117 deletions(-) delete mode 100644 rtemslwip/zynqmp/xparameters.h diff --git a/rtemslwip/zynqmp/xemacps_g.c b/rtemslwip/zynqmp/xemacps_g.c index 3fc003b..471b080 100644 --- a/rtemslwip/zynqmp/xemacps_g.c +++ b/rtemslwip/zynqmp/xemacps_g.c @@ -25,6 +25,7 @@ */ #include "xparameters.h" +#include "xparameters_ps.h" #include "xemacps.h" /* diff --git a/rtemslwip/zynqmp/xparameters.h b/rtemslwip/zynqmp/xparameters.h deleted file mode 100644 index 053a154..000 --- a/rtemslwip/zynqmp/xparameters.h +++ /dev/null @@ -1,113 +0,0 @@ -/* - * Copyright (C) 2022 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 must retain the above copyright - *notice, this list of conditions and the following disclaimer. - * 2. Redistributions in binary form must reproduce the above copyright - *notice, this list of conditions and the following disclaimer in the - *documentation and/or other materials provided with the distribution. - * - * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" - * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE - * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE - * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE - * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR - * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF - * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS - * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN - * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) - * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE - * POSSIBILITY OF SUCH DAMAGE. - */ - -#ifndef XPARAMETERS_H -#define XPARAMETERS_H - -/* Platform specific definitions */ -#define PLATFORM_ZYNQMP - -/* Definitions for driver EMACPS */ -#define XPAR_XEMACPS_NUM_INSTANCES 4 - -/* Definitions for peripheral PSU_ETHERNET_0 */ -#define XPAR_PSU_ETHERNET_0_DEVICE_ID 0 -#define XPAR_PSU_ETHERNET_0_BASEADDR 0xFF0B -#define XPAR_PSU_ETHERNET_0_ENET_CLK_FREQ_HZ 124998749 -#define XPAR_PSU_ETHERNET_0_ENET_SLCR_1000MBPS_DIV0 12 -#define XPAR_PSU_ETHERNET_0_ENET_SLCR_1000MBPS_DIV1 1 -#define XPAR_PSU_ETHERNET_0_ENET_SLCR_100MBPS_DIV0 60 -#define XPAR_PSU_ETHERNET_0_ENET_SLCR_100MBPS_DIV1 1 -#define XPAR_PSU_ETHERNET_0_ENET_SLCR_10MBPS_DIV0 60 -#define XPAR_PSU_ETHERNET_0_ENET_SLCR_10MBPS_DIV1 10 - -/* Definitions for peripheral PSU_ETHERNET_1 */ -#define XPAR_PSU_ETHERNET_1_DEVICE_ID 1 -#define XPAR_PSU_ETHERNET_1_BASEADDR 0xFF0C -#define XPAR_PSU_ETHERNET_1_ENET_CLK_FREQ_HZ 124998749 -#define XPAR_PSU_ETHERNET_1_ENET_SLCR_1000MBPS_DIV0 12 -#define XPAR_PSU_ETHERNET_1_ENET_SLCR_1000MBPS_DIV1 1 -#define XPAR_PSU_ETHERNET_1_ENET_SLCR_100MBPS_DIV0 60 -#define XPAR_PSU_ETHERNET_1_ENET_SLCR_100MBPS_DIV1 1 -#define XPAR_PSU_ETHERNET_1_ENET_SLCR_10MBPS_DIV0 60 -#define XPAR_PSU_ETHERNET_1_ENET_SLCR_10MBPS_DIV1 10 - -/* Definitions for peripheral PSU_ETHERNET_2 */ -#define XPAR_PSU_ETHERNET_2_DEVICE_ID 1 -#define XPAR_PSU_ETHERNET_2_BASEADDR 0xFF0D -#define XPAR_PSU_ETHERNET_2_ENET_CLK_FREQ_HZ 124998749 -#define XPAR_PSU_ETHERNET_2_ENET_SLCR_1000MBPS_DIV0 12 -#define XPAR_PSU_ETHERNET_2_ENET_SLCR_1000MBPS_DIV1 1 -#define XPAR_PSU_ETHERNET_2_ENET_SLCR_100MBPS_DIV0 60 -#define XPAR_PSU_ETHERNET_2_ENET_SLCR_100MBPS_DIV1 1 -#define XPAR_PSU_ETHERNET_2_ENET_SLCR_10MBPS_DIV0 60 -#define XPAR_PSU_ETHERNET_2_ENET_SLCR_10MBPS_DIV1 10 - -/**/ -#define XPAR_PSU_ETHERNET_0_IS_CACHE_COHERENT 0 -#define XPAR_XEMACPS_0_IS_CACHE_COHERENT 0 -#define XPAR_PSU_ETHERNET_0_REF_CLK GEM0_REF -#define XPAR_PSU_ETHERNET_1_IS_CACHE_COHERENT 0 -#define XPAR_XEMACPS_1_IS_CACHE_COHERENT 0 -#define XPAR_PSU_ETHERNET_1_REF_CLK GEM1_REF -#define XPAR_PSU_ETHERNET_2_IS_CACHE_COHERENT 0 -#define XPAR_PSU_ETHERNET_2_REF_CLK GEM2_REF -#define XPAR_XEMACPS_0_ENET_CLK_FREQ_HZ 124998749 -#define XPAR_XEMACPS_0_ENET_SLCR_1000Mbps_DIV1 1 -#define
[PATCH 2/2] bsps/xil: Import full xil_exception.h
This imports the full xil_exception.h instead of an empty stub. This is
required for some Xilinx drivers. The imported files adhere to the
current VERSION file.
---
.../xil/arm/ARMv8/32bit/xil_exception.h | 408 ++
.../xil/arm/ARMv8/64bit/xil_exception.h | 408 ++
bsps/include/xil/arm/cortexa9/xil_exception.h | 408 ++
bsps/include/xil/arm/cortexr5/xil_exception.h | 408 ++
bsps/include/xil/microblaze/xil_exception.h | 112 +
bsps/include/xil/xil_exception.h | 1 -
spec/build/bsps/objxilinxsupport.yml | 1 -
spec/build/bsps/objxilinxsupporta9.yml| 1 +
spec/build/bsps/objxilinxsupportilp32.yml | 1 +
spec/build/bsps/objxilinxsupportlp64.yml | 1 +
spec/build/bsps/objxilinxsupportmb.yml| 1 +
spec/build/bsps/objxilinxsupportr5.yml| 1 +
12 files changed, 1749 insertions(+), 2 deletions(-)
create mode 100644 bsps/include/xil/arm/ARMv8/32bit/xil_exception.h
create mode 100644 bsps/include/xil/arm/ARMv8/64bit/xil_exception.h
create mode 100644 bsps/include/xil/arm/cortexa9/xil_exception.h
create mode 100644 bsps/include/xil/arm/cortexr5/xil_exception.h
create mode 100644 bsps/include/xil/microblaze/xil_exception.h
delete mode 100644 bsps/include/xil/xil_exception.h
diff --git a/bsps/include/xil/arm/ARMv8/32bit/xil_exception.h
b/bsps/include/xil/arm/ARMv8/32bit/xil_exception.h
new file mode 100644
index 00..144d8423df
--- /dev/null
+++ b/bsps/include/xil/arm/ARMv8/32bit/xil_exception.h
@@ -0,0 +1,408 @@
+/**
+* Copyright (c) 2015 - 2022 Xilinx, Inc. All rights reserved.
+* SPDX-License-Identifier: MIT
+**/
+
+/*/
+/**
+*
+* @file xil_exception.h
+*
+* This header file contains ARM Cortex A53,A9,R5 specific exception related
APIs.
+* For exception related functions that can be used across all Xilinx supported
+* processors, please use xil_exception.h.
+*
+* @addtogroup arm_exception_apis ARM Processor Exception Handling
+* @{
+* ARM processors specific exception related APIs for cortex A53,A9 and R5 can
+* utilized for enabling/disabling IRQ, registering/removing handler for
+* exceptions or initializing exception vector table with null handler.
+*
+*
+* MODIFICATION HISTORY:
+*
+* Ver Who Date Changes
+* - ---
+* 5.2 pkp 28/05/15 First release
+* 6.0 mus 27/07/16 Consolidated file for a53,a9 and r5 processors
+* 6.7 mna 26/04/18 Add API Xil_GetExceptionRegisterHandler.
+* 6.7 asa 18/05/18 Update signature of API
Xil_GetExceptionRegisterHandler.
+* 7.0 mus 01/03/19 Tweak Xil_ExceptionEnableMask and
+* Xil_ExceptionDisableMask macros to support legacy
+* examples for Cortexa72 EL3 exception level.
+* 7.3 mus 04/15/20 Added Xil_EnableNestedInterrupts and
+* Xil_DisableNestedInterrupts macros for ARMv8.
+* For Cortexa72, these macro's would not be supported
+* at EL3, as Cortexa72 is using GIC-500(GICv3), which
+* triggeres only FIQ at EL3. Fix for CR#1062506
+* 7.6 mus 09/17/21 Updated flag checking to fix warning reported with
+* -Wundef compiler option CR#1110261
+* 7.7 mus 01/31/22 Few of the #defines in xil_exception.h in are treated
+* in different way based on "versal" flag. In existing
+* flow, this flag is defined only in xparameters.h and
+* BSP compiler flags, it is not defined in application
+* compiler flags. So, including xil_exception.h in
+* application source file, without including
+* xparameters.h results in incorrect behavior.
+* Including xparameters.h in xil_exception.h to avoid
+* such issues. It fixes CR#1120498.
+* 7.7 sk 03/02/22 Define XExc_VectorTableEntry structure to fix
+*misra_c_2012_rule_5_6 violation.
+* 7.7 sk 03/02/22 Add XExc_VectorTable as extern to fix misra_c_2012_
+*rule_8_4 violation.
+*
+*
+**/
+
+/**
+ *@cond nocomments
+ */
+
+#ifndef XIL_EXCEPTION_H /* prevent circular inclusions */
+#define XIL_EXCEPTION_H /* by using protection macros */
+
+/* Include Files /
+
+#include "xil_types.h"
+#include "xpseudo_asm.h"
+#include "bspconfig.h"
+#include "xparameters.h"
+
+#ifdef __cplusplus
+extern "C" {
[PATCH 1/2] bsps/xil: Make sleep.h a stub
This makes xil/sleep.h a stub to prevent multiple differing definitions
of sleep functions from toolchain and local headers. The non-standard
sleep definitions were not in use and can be added later if needed.
---
bsps/include/xil/sleep.h | 100 +--
1 file changed, 1 insertion(+), 99 deletions(-)
diff --git a/bsps/include/xil/sleep.h b/bsps/include/xil/sleep.h
index 73b2ea026d..5cab0b5a1b 100644
--- a/bsps/include/xil/sleep.h
+++ b/bsps/include/xil/sleep.h
@@ -1,99 +1 @@
-/**
-* Copyright (c) 2014 - 2022 Xilinx, Inc. All rights reserved.
-* SPDX-License-Identifier: MIT
-**/
-
-
-/*/
-/**
-* @file sleep.h
-*
-* This header file contains ARM Cortex A53,A9,R5,Microblaze specific sleep
-* related APIs.
-*
-*
-* MODIFICATION HISTORY :
-*
-* Ver Who Date Changes
-* - ---
-* 6.6 srm 11/02/17 Added processor specific sleep routines
-* function
prototypes.
-* 7.7 sk 01/10/22 Typecast sleep declaration argument from unsigned int to
-*u32 to fix misra_c_2012_directive_4_6 violation.
-* 7.7 sk 01/10/22 Modify the return type of sleep_R5 and usleep_R5 from
-*unsigned to void to fix misra_c_2012_rule_17_7 violation.
-* 7.7 sk 03/02/22 Update usleep_R5 and usleep parameter types to fix misra_
-*c_2012_directive_4_6 violation.
-*
-*
-*
-**/
-
-#ifndef SLEEP_H
-#define SLEEP_H
-
-#include "xil_types.h"
-#include "xil_io.h"
-
-#ifdef __cplusplus
-extern "C" {
-#endif
-
-/*/
-/**
-*
-* This macro polls an address periodically until a condition is met or till the
-* timeout occurs.
-* The minimum timeout for calling this macro is 100us. If the timeout is less
-* than 100us, it still waits for 100us. Also the unit for the timeout is 100us.
-* If the timeout is not a multiple of 100us, it waits for a timeout of
-* the next usec value which is a multiple of 100us.
-*
-* @paramIO_func - accessor function to read the register contents.
-* Depends on the register width.
-* @paramADDR - Address to be polled
-* @paramVALUE - variable to read the value
-* @paramCOND - Condition to checked (usually involves VALUE)
-* @paramTIMEOUT_US - timeout in micro seconds
-*
-* @return 0 - when the condition is met
-* -1 - when the condition is not met till the timeout period
-*
-* @note none
-*
-*/
-#define Xil_poll_timeout(IO_func, ADDR, VALUE, COND, TIMEOUT_US) \
- ( { \
- u64 timeout = TIMEOUT_US/100;\
- if(TIMEOUT_US%100!=0) \
- timeout++; \
- for(;;) { \
- VALUE = IO_func(ADDR); \
- if(COND) \
- break; \
- else {\
- usleep(100); \
- timeout--; \
- if(timeout==0) \
- break; \
- } \
- }\
- (timeout>0) ? 0 : -1; \
- } )
-
-void usleep(ULONG useconds);
-void sleep(u32 seconds);
-void usleep_R5(ULONG useconds);
-void sleep_R5(u32 seconds);
-int usleep_MB(unsigned long useconds);
-unsigned sleep_MB(unsigned int seconds);
-int usleep_A53(unsigned long useconds);
-unsigned sleep_A53(unsigned int seconds);
-int usleep_A9(unsigned long useconds);
-unsigned sleep_A9(unsigned int seconds);
-
-#ifdef __cplusplus
-}
-#endif
-
-#endif
+#include
--
2.30.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
libbsd development policy clarification needed?
Guys, recently I needed to work with RTEMS/NFS. As this is provided by libbsd I took this and following two sentences below from master branch description provided in README I took as granted that master does have all the features which are currently available and provided by the project: "This branch must be used for libbsd development. Back ports to the 6-freebsd-12 are allowed." I was surprised to be proven wrong then by Fabrizio here: https://devel.rtems.org/ticket/4723 and by later investigation which shows that 6-freebsd-12 branch accumulated NFS work by Chris done in 2021 which is not presented on master. I've investigated just NFS as this was my focus here. So if 6-freebsd-12 became development branch of some sort, then it would be great to have that clarified in the project README file to prevent users confusion? Or if the policy is still the same, then perhaps some branch sync is needed here? I'm fine with either way, as a user I just need clear not confusing project message... Thanks! Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
