Re: Fwd: [rtems-bsp-builder] 2020-12-11 12:57:21: Profile(s): everything
Hello Joel, On 14/12/2020 15:23, Joel Sherrill wrote: OK. I'll start another sweep when this goes in. I updated the RSB to fetch the latest tools today. Now, the failures should be fixed. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 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] tester: Add support for arm/fvp_cortex_r52 BSP
Update #4202.
---
.../rtems/testing/bsps/fvp_cortex_r52x1.ini | 38 +++
.../rtems/testing/bsps/fvp_cortex_r52x2.ini | 38 +++
.../rtems/testing/bsps/fvp_cortex_r52x4.ini | 38 +++
3 files changed, 114 insertions(+)
create mode 100644 tester/rtems/testing/bsps/fvp_cortex_r52x1.ini
create mode 100644 tester/rtems/testing/bsps/fvp_cortex_r52x2.ini
create mode 100644 tester/rtems/testing/bsps/fvp_cortex_r52x4.ini
diff --git a/tester/rtems/testing/bsps/fvp_cortex_r52x1.ini
b/tester/rtems/testing/bsps/fvp_cortex_r52x1.ini
new file mode 100644
index 000..d1e42c6
--- /dev/null
+++ b/tester/rtems/testing/bsps/fvp_cortex_r52x1.ini
@@ -0,0 +1,38 @@
+#
+# RTEMS Tools Project (http://www.rtems.org/)
+# Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+#
+# This file is part of the RTEMS Tools package in 'rtems-tools'.
+#
+# 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 HOLDER 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.
+#
+
+#
+# The arm/fvp_cortex_r52 BSP
+#
+[fvp_cortex_r52x1]
+bsp = fvp_cortex_r52
+arch = arm
+tester = %{_rtscripts}/run.cfg
+bsp_run_cmd = FVP_BaseR_Cortex-R52x1
+bsp_run_opts = -C bp.vis.disable_visualisation=1 -a
diff --git a/tester/rtems/testing/bsps/fvp_cortex_r52x2.ini
b/tester/rtems/testing/bsps/fvp_cortex_r52x2.ini
new file mode 100644
index 000..e8e8bf1
--- /dev/null
+++ b/tester/rtems/testing/bsps/fvp_cortex_r52x2.ini
@@ -0,0 +1,38 @@
+#
+# RTEMS Tools Project (http://www.rtems.org/)
+# Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+#
+# This file is part of the RTEMS Tools package in 'rtems-tools'.
+#
+# 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 HOLDER 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.
+#
+
+#
+# The arm/fvp_cortex_r52 BSP
+#
+[fvp_cortex_r52x2]
+bsp = fvp_cortex_r52
+arch = arm
+tester = %{_rtscripts}/run.cfg
+bsp_run_cmd = FVP_BaseR_Cortex-R52x2
+bsp_run_opts = -C bp.vis.disable_visualisation=1 -a
diff --git a/tester/rtems/testing/bsps/fvp_cortex_r52x4.ini
b/tester/rtems/testing/bsps/fvp_cortex_r52x4.ini
new file mode 100644
index 000..5b64a8b
--- /dev/null
+++ b/tester/rtems/testing/bsps/fvp_cortex_r52x4.ini
@@ -0,0 +1,38 @@
+#
+# RTEMS Tools Project (http://www.rtems.org/)
+# Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+#
+# This file is part of the RTEMS Tools package in 'rtems-tools'.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions are me
Planning for RTEMS 6 Branch
Hi It took a long time to get from 4.10 to 4.11 and then on to 5. I don't see any reason getting from 5 to 6 should be such a long period of time. It seems as if we focus on a few major changes and see what happens while those go in. Right now, I'd be prone to say 6 is ready to branch from a feature perspective if we get the following: + Waf switchover complete + NFSv4 + aarch64 on real hardware and SMP I would expect all of this to be available in early 2021. There are already new BSPs (stm, etc), tool updates, etc. that are a normal part of RTEMS moving forward. These don't really play into my thoughts. They show up when they show up and we can delay branching a very short time if something is on the cusp. But they don't drive release planning. In my opinion, the big question is addressing RTEMS for EPICS. Most of the BSPs I know that are used for EPICS are still only supported by the legacy stack. I'm ignoring some known BSP regressions that will get fixed as a normal part of moving forward. If RTEMS 5 + EPICS uses the legacy stack, that's OK. But I'd like to move the legacy stack to its own repository. Downgrading the legacy stack that way while BSPs used by EPICS users haven't been updated to libbsd is not a good thing. I expect motorola_powerpc and beatnik/mvme5500 to be on libbsd sometime in the near future but that leaves other EPICS BSPs. We need to include EPICS considerations in our roadmap. This means the legacy stack can't be moved out without considering them. And we need to figure out how to bring them up to date. This needs to be part of release planning. The other big work is the qualification effort. It would be nice for it to be complete but I don't see that as a blocker for RTEMS 6. It could be the driving factor for RTEMS 7 if the timeline doesn't work out. Basically, I'd like a quicker RTEMS 6 even if 7 comes out quickly to address the legacy stack. Each of these still has major user facing considerations. Let's just be quicker. Thoughts? --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Possible Bug in
Hi The context switch recorder code -- _Record_Thread_switch in record-userext.c has this code: items[ 0 ].event = RTEMS_RECORD_THREAD_SWITCH_OUT; items[ 0 ].data = executing->Object.id; items[ 1 ].event = RTEMS_RECORD_THREAD_STACK_CURRENT; items[ 1 ].data = #if defined(__GNUC__) (uintptr_t) __builtin_frame_address( 0 ) - (uintptr_t) executing->Start.Initial_stack.area; There isn't a comment about what items[1].data is supposed to be but I am assuming it is intended to be stack used. Unfortunately, it doesn't conditionalize on stack growing up or down. On the ARM, the stack grows down This means on the ARM, it is stack memory remaining. I think this needs a comment as to the intent and then some conditional logic on CPU_STACK_GROWS_UP like the stack checker has. Anyone know what the meaning of the value should be? I suppose remaining is good for quick monitoring if the size is captured on say create. Thanks. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
How to Get Predefined Capture Records
Hi First, we have successfully managed to get the user extension and IRQ trace records off a target and see them on the host. Now I'm wondering how more of the predefined ones get turned on. In recorddata.h, I see 100s of events defined for standard RTEMS operations but there don't appear to be calls which record those events. How do those get turned on? We haven't tried the GCC option -finstrument-functions but that seems more geared to user code and wouldn't generate the standard predefined events. How are the RTEMS_RECORD_xxx that are already defined enabled to be generated? Thanks. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Planning for RTEMS 6 Branch
Hi, joel Our team is developing a pcie card running rtems. The stability is very important for us. Currently we are using rtems 5.1. Are there plans for rtems 5.x ? Such as bug fixes, new features, etc. "aarch64 on real hardware and SMP" is what we really wanted. Does this feature will be supported by rtems 5.x ? small...@aliyun.com From: Joel Sherrill Date: 2020-12-17 03:39 To: rtems-de...@rtems.org; David Edelsohn Subject: Planning for RTEMS 6 Branch Hi It took a long time to get from 4.10 to 4.11 and then on to 5. I don't see any reason getting from 5 to 6 should be such a long period of time. It seems as if we focus on a few major changes and see what happens while those go in. Right now, I'd be prone to say 6 is ready to branch from a feature perspective if we get the following: + Waf switchover complete + NFSv4 + aarch64 on real hardware and SMP I would expect all of this to be available in early 2021. There are already new BSPs (stm, etc), tool updates, etc. that are a normal part of RTEMS moving forward. These don't really play into my thoughts. They show up when they show up and we can delay branching a very short time if something is on the cusp. But they don't drive release planning. In my opinion, the big question is addressing RTEMS for EPICS. Most of the BSPs I know that are used for EPICS are still only supported by the legacy stack. I'm ignoring some known BSP regressions that will get fixed as a normal part of moving forward. If RTEMS 5 + EPICS uses the legacy stack, that's OK. But I'd like to move the legacy stack to its own repository. Downgrading the legacy stack that way while BSPs used by EPICS users haven't been updated to libbsd is not a good thing. I expect motorola_powerpc and beatnik/mvme5500 to be on libbsd sometime in the near future but that leaves other EPICS BSPs. We need to include EPICS considerations in our roadmap. This means the legacy stack can't be moved out without considering them. And we need to figure out how to bring them up to date. This needs to be part of release planning. The other big work is the qualification effort. It would be nice for it to be complete but I don't see that as a blocker for RTEMS 6. It could be the driving factor for RTEMS 7 if the timeline doesn't work out. Basically, I'd like a quicker RTEMS 6 even if 7 comes out quickly to address the legacy stack. Each of these still has major user facing considerations. Let's just be quicker. Thoughts? --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Planning for RTEMS 6 Branch
On Wed, Dec 16, 2020, 6:38 PM small...@aliyun.com wrote: > Hi, joel > Our team is developing a pcie card running rtems. The stability is very > important for us. > Currently we are using rtems 5.1. Are there plans for rtems 5.x ? Such as > bug fixes, new features, etc. > "aarch64 on real hardware and SMP" is what we really wanted. Does this > feature will be supported by rtems 5.x ? > RTEMS release branches are considered feature complete and the focus is on bug fixes. Currently the master has aarch64 (64 bit ARM) support that is not on the 5 branch and won't be added. The only BSP at this time is for qemu. The libbsd networking support for aarch64 is being tested now. The next step is to verify it on a Xilinx reference board. After that SMP support for that architecture. I hope this helps. Bug fixes in release branches and features added on master working to the next release. > -- > small...@aliyun.com > > > *From:* Joel Sherrill > *Date:* 2020-12-17 03:39 > *To:* rtems-de...@rtems.org ; David Edelsohn > > *Subject:* Planning for RTEMS 6 Branch > Hi > > It took a long time to get from 4.10 to 4.11 and then on to 5. I don't see > any reason getting from 5 to 6 should be such a long period of time. It > seems as if we focus on a few major changes and see what happens while > those go in. Right now, I'd be prone to say 6 is ready to branch from a > feature perspective if we get the following: > > + Waf switchover complete > + NFSv4 > + aarch64 on real hardware and SMP > > I would expect all of this to be available in early 2021. > > There are already new BSPs (stm, etc), tool updates, etc. that are a > normal part of RTEMS moving forward. These don't really play into my > thoughts. They show up when they show up and we can delay branching a very > short time if something is on the cusp. But they don't drive release > planning. > > In my opinion, the big question is addressing RTEMS for EPICS. Most of the > BSPs I know that are used for EPICS are still only supported by the legacy > stack. I'm ignoring some known BSP regressions that will get fixed as a > normal part of moving forward. If RTEMS 5 + EPICS uses the legacy stack, > that's OK. But I'd like to move the legacy stack to its own repository. > Downgrading the legacy stack that way while BSPs used by EPICS users > haven't been updated to libbsd is not a good thing. I expect > motorola_powerpc and beatnik/mvme5500 to be on libbsd sometime in the near > future but that leaves other EPICS BSPs. We need to include EPICS > considerations in our roadmap. This means the legacy stack can't be moved > out without considering them. And we need to figure out how to bring them > up to date. This needs to be part of release planning. > > The other big work is the qualification effort. It would be nice for it to > be complete but I don't see that as a blocker for RTEMS 6. It could be the > driving factor for RTEMS 7 if the timeline doesn't work out. > > Basically, I'd like a quicker RTEMS 6 even if 7 comes out quickly to > address the legacy stack. Each of these still has major user facing > considerations. Let's just be quicker. > > Thoughts? > > --joel > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Re: Planning for RTEMS 6 Branch
Hi,joel Your reply is helpful and fast as usual. Thanks very much! small...@aliyun.com From: Joel Sherrill Date: 2020-12-17 08:44 To: smallphd CC: devel; David Edelsohn Subject: Re: Planning for RTEMS 6 Branch On Wed, Dec 16, 2020, 6:38 PM small...@aliyun.com wrote: Hi, joel Our team is developing a pcie card running rtems. The stability is very important for us. Currently we are using rtems 5.1. Are there plans for rtems 5.x ? Such as bug fixes, new features, etc. "aarch64 on real hardware and SMP" is what we really wanted. Does this feature will be supported by rtems 5.x ? RTEMS release branches are considered feature complete and the focus is on bug fixes. Currently the master has aarch64 (64 bit ARM) support that is not on the 5 branch and won't be added. The only BSP at this time is for qemu. The libbsd networking support for aarch64 is being tested now. The next step is to verify it on a Xilinx reference board. After that SMP support for that architecture. I hope this helps. Bug fixes in release branches and features added on master working to the next release. small...@aliyun.com From: Joel Sherrill Date: 2020-12-17 03:39 To: rtems-de...@rtems.org; David Edelsohn Subject: Planning for RTEMS 6 Branch Hi It took a long time to get from 4.10 to 4.11 and then on to 5. I don't see any reason getting from 5 to 6 should be such a long period of time. It seems as if we focus on a few major changes and see what happens while those go in. Right now, I'd be prone to say 6 is ready to branch from a feature perspective if we get the following: + Waf switchover complete + NFSv4 + aarch64 on real hardware and SMP I would expect all of this to be available in early 2021. There are already new BSPs (stm, etc), tool updates, etc. that are a normal part of RTEMS moving forward. These don't really play into my thoughts. They show up when they show up and we can delay branching a very short time if something is on the cusp. But they don't drive release planning. In my opinion, the big question is addressing RTEMS for EPICS. Most of the BSPs I know that are used for EPICS are still only supported by the legacy stack. I'm ignoring some known BSP regressions that will get fixed as a normal part of moving forward. If RTEMS 5 + EPICS uses the legacy stack, that's OK. But I'd like to move the legacy stack to its own repository. Downgrading the legacy stack that way while BSPs used by EPICS users haven't been updated to libbsd is not a good thing. I expect motorola_powerpc and beatnik/mvme5500 to be on libbsd sometime in the near future but that leaves other EPICS BSPs. We need to include EPICS considerations in our roadmap. This means the legacy stack can't be moved out without considering them. And we need to figure out how to bring them up to date. This needs to be part of release planning. The other big work is the qualification effort. It would be nice for it to be complete but I don't see that as a blocker for RTEMS 6. It could be the driving factor for RTEMS 7 if the timeline doesn't work out. Basically, I'd like a quicker RTEMS 6 even if 7 comes out quickly to address the legacy stack. Each of these still has major user facing considerations. Let's just be quicker. Thoughts? --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Possible Bug in
On 16/12/2020 21:01, Joel Sherrill wrote: Hi The context switch recorder code -- _Record_Thread_switch in record-userext.c has this code: items[ 0 ].event = RTEMS_RECORD_THREAD_SWITCH_OUT; items[ 0 ].data = executing->Object.id; items[ 1 ].event = RTEMS_RECORD_THREAD_STACK_CURRENT; items[ 1 ].data = #if defined(__GNUC__) (uintptr_t) __builtin_frame_address( 0 ) - (uintptr_t) executing->Start.Initial_stack.area; There isn't a comment about what items[1].data is supposed to be but I am assuming it is intended to be stack used. Unfortunately, it doesn't conditionalize on stack growing up or down. On the ARM, the stack grows down This means on the ARM, it is stack memory remaining. I think this needs a comment as to the intent and then some conditional logic on CPU_STACK_GROWS_UP like the stack checker has. Anyone know what the meaning of the value should be? I suppose remaining is good for quick monitoring if the size is captured on say create. Yes, this code is broken. Another issue is that the current stack pointer belongs to different tasks in SMP and non-SMP configurations. I am not sure if there is a LTTNG event for the thread stack. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 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
Re: How to Get Predefined Capture Records
Hello Joel, On 16/12/2020 22:59, Joel Sherrill wrote: Hi First, we have successfully managed to get the user extension and IRQ trace records off a target and see them on the host. Now I'm wondering how more of the predefined ones get turned on. In recorddata.h, I see 100s of events defined for standard RTEMS operations but there don't appear to be calls which record those events. How do those get turned on? the original plan was to add a wrapper library and then use the GNU ld --wrap feature: https://lists.rtems.org/pipermail/devel/2019-August/027574.html This could be used to map the record events to LTTNG user space events: https://archive.eclipse.org/tracecompass/doc/stable/org.eclipse.tracecompass.doc.user/LTTng-UST-Analyses.html We haven't tried the GCC option -finstrument-functions but that seems more geared to user code and wouldn't generate the standard predefined events. This works quite well. For custom instrumentation you can use the rtems_record_line* rtems_record_caller_* functions. How are the RTEMS_RECORD_xxx that are already defined enabled to be generated? There is no out of the box support for them. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 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
