Re: LibBSD PowerPC motorola_shared BSP PCI Support
Hello, Chris, unfortunately it is not quite so simple. The Beatnik board uses for the Ethernet the Marvell Discovery II MV64360 (GT64360) and there two of the three built-in Ethernet controllers. Till Straumann has written a driver for it called "mve" and unfortunately it is not available in freebsd. Probably too rare or I did not search properly. Viele Grüße Heinz Junkes -- Experience directly varies with equipment ruined. > On 27. Oct 2020, at 05:06, Chris Johns wrote: > > On 26/10/20 7:32 pm, Heinz Junkes wrote: >> Good morning Chris, >> i will now try out libbsd on a MVME6100 (beatnik). >> Is the mentioned patch in git? > > The PCI patch is in rtems-libbsd.git on the master and 6-freebsd-12 branches. > >> Or do I have to prepare something special? > > Yes I think you may need to patch libbsd for the beatnik bvoard. I have not > looked at that board and the net drivers it needs. The current list is we have > in libbsd is: > > https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h?h=6-freebsd-12 > > The BSP support is handled here: > > https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/include/bsp/nexus-devices.h?h=6-freebsd-12 > > The define is based on the header guard for the BSP: > > https://git.rtems.org/rtems/tree/bsps/powerpc/beatnik/include/bsp.h#n25 > > I hope this helps. > > Chris smime.p7s Description: S/MIME cryptographic signature ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
EPICS and RTEMS BSPs
Hi Heinz posted about the Beatnik BSP and I started to include this in the response but thought it should be its own thread in the hope it would get the attention it really needs. There is a table in Chris and my EPICS meeting presentation that lists the boards we think the EPICS community is using, the NICS they have, and our current thoughts on the path to libbsd support. This is the link: https://indico.fhi-berlin.mpg.de/event/52/contributions/580/ Unfortunately, the site is down today. I hope that's not a permanent down since the presentations were hosted there. But it may be OK, since below I try to put forward what was in my head putting together slides 21 and 21 of the presentation. Chris and I hoped these two slides would spark a discussion which would lead to the RTEMS community knowing what boards the EPICS community wants to be supported. And defining a path forward so they are. This is the text from slide 21 outlining the EPICS BSP Network Roadmap that Chris and I identified: + Legacy Network Stack (e.g. libnetworking) will be obsoleted and removed - Will be placed in “purgatory” repo in case someone needs it and supports adding build system - No feature upgrades and limited support even if made to build again + Libbsd stack is more full-featured and has larger size + Impacts BSPs which do not yet have LibBSD drivers + Analysis required per BSP and NIC to determine solution path - In libbsd, current FreeBSD, or *BSD -- easier - Older NICs can possibly be resurrected from old *BSD - Custom drivers require conversion - Freeze on RTEMS 5.x and plan to eliminate hardware This means that the legacy stack will never go beyond NFSv2, have IPSEC, IPV6, etc. If someone cares, it may be buildable and usable but in another repository. The next slide has this table (hope it looks OK cut and pasted): RTEMS BSP Family NIC/Driver Libbsd Options Zynq On SoC, LibBSD Supported PC Various Supported Motorola Shared DEC NIC Support in process Beatnik em, gfe,mve (GT64260) FreeBSD em, old NetBSD gfe, custom mve mvme3100 tsec Custom, maybe FreeBSD tsec mvme5500 wm, GT64260 FreeBSD wm, custom like mve, same as Beatnik gen68360 on SoC, custom for RTEMS refactor, is it in use? uc5282 on SoC, custom for RTEMS refactor, is it in use? mvme162/167 i82596 old FreeBSD, is it in use? This left off the mvme2500 because honestly I didn't think of it. Does it eventually need a BSP alias name? It at least needs a users guide entry. That's likely true of many of these models. It would be nice to at least put them in the users guide and say "use this BSP with these options" and here's some board dependent information. A part of this analysis is ultimately deciding what to do about some of the older boards. Do EPICS users want the mvme162/167 to continue to be supported? Can we define a minimum set of libbsd that will work nicely and support EPICS on smaller/older boards? This would be the nicest long-term solution if they stay, Doing this analysis made me wonder if the mvme5500 BSP could be obsoleted and the beatnik used. We could add BSP variants for the mvme5500 and mvme6100 and tailor the CPU CFLAGS if need be. The question for those who know the BSPs whether they both have the same features and are effectively interchangeable on the mvme5500 I hope the projects can at least define a technical roadmap for all these boards and things like PowerPC support for libdebugger. Getting that roadmap implemented is another challenge. Things can be removed for free but adding support for something requires time, effort, and access to hardware. This is unlikely to to happen as volunteer time and is unlikely to happen in a timely manner if we can't define the requirements. --joel > Viele Grüße > Heinz Junkes > -- > Experience directly varies with equipment ruined. > > > > > On 27. Oct 2020, at 05:06, Chris Johns wrote ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: LibBSD PowerPC motorola_shared BSP PCI Support
On Wed, Nov 4, 2020 at 6:28 AM Heinz Junkes wrote: > Hello, Chris, > unfortunately it is not quite so simple. The Beatnik board uses > for the Ethernet the Marvell Discovery II MV64360 (GT64360) > and there two of the three built-in Ethernet controllers. > > Till Straumann has written a driver for it called "mve" and unfortunately > it > is not available in freebsd. Probably too rare or I did not search > properly. > Yep. That's right. It is a custom driver for RTEMS as best I can tell. This BSP and the mvme500 have the same challenge. I've started another thread on the broader topic of BSPs needed by the EPICS community and their path forward. I didn't want to hijack this one since it needs to stay focused on this one board and technical. --joel > > Viele Grüße > Heinz Junkes > -- > Experience directly varies with equipment ruined. > > > > > On 27. Oct 2020, at 05:06, Chris Johns wrote: > > > > On 26/10/20 7:32 pm, Heinz Junkes wrote: > >> Good morning Chris, > >> i will now try out libbsd on a MVME6100 (beatnik). > >> Is the mentioned patch in git? > > > > The PCI patch is in rtems-libbsd.git on the master and 6-freebsd-12 > branches. > > > >> Or do I have to prepare something special? > > > > Yes I think you may need to patch libbsd for the beatnik bvoard. I have > not > > looked at that board and the net drivers it needs. The current list is > we have > > in libbsd is: > > > > > https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h?h=6-freebsd-12 > > > > The BSP support is handled here: > > > > > https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/include/bsp/nexus-devices.h?h=6-freebsd-12 > > > > The define is based on the header guard for the BSP: > > > > https://git.rtems.org/rtems/tree/bsps/powerpc/beatnik/include/bsp.h#n25 > > > > I hope this helps. > > > > Chris > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: How does RTEMS decide which process to execute next on calling rtems_task_exit
Hi Mr. Huber, I see. Any information helps, and I would try to learn more about _Thread_Make_zombie(). Thanks again! On Tue, Nov 3, 2020 at 11:35 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello Richi, > > the task termination sequence is quite complicated. The last action of a > task is executing _Thread_Make_zombie(). > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v1 1/2] bsps/shared/ofw: Implement RTEMS OFW interface
On Mon, Nov 2, 2020 at 12:13 PM Christian Mauderer wrote: > > Hello Niteesh, > > On 02/11/2020 18:06, Niteesh G. S. wrote: > > ping. > > Yes, of course you are right that it would be time to integrate it. The > nasty part why I haven't started to do something into that direction is > that we currently still have the old build system and the new in > parallel. But I think we should start to integrate your code anyway. > > Please correct me if I'm wrong: Currently there are two parts: > > 1. Adding the OFW interface. > > 2. Using in in BBB. > > Is that correct? > > I think the first one should be not too hard. There are already some > parts that use only the new build system. Wouldn't be a problem to do > that with OFW too. So to all participating at the discussion: Is there > any blocker left why we wouldn't integrate an updated version of the > patches? > I think this is fine. Of course, we get less confident about the comparison between the two build systems. But, without someone actively engaged in verifying them, I think at some point we need to just start to move on. I currently lack time, hopefully in Dec I can revisit. I have a t2080rdb I want to get set up and may be able to test both old/new build systems. It will be good to keep bsps building with the old build system until we kill it off. Especially the BBB (and other common test targets). So your analysis is spot on. Gedare ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Fatal exceptions on context-switching for more than two isolated threads
On Sun, Nov 1, 2020 at 9:49 AM Utkarsh Rai wrote: > > > > > On Fri, Oct 23, 2020 at 10:28 PM Utkarsh Rai wrote: >> >> >> >> On Fri, Oct 23, 2020 at 9:57 PM Gedare Bloom wrote: >>> >>> On Fri, Oct 23, 2020 at 9:37 AM Utkarsh Rai wrote: >>> > >>> > >>> > >>> > On Thu, Oct 22, 2020 at 11:23 PM Sebastian Huber >>> > wrote: >>> >> >>> >> On 22/10/2020 02:40, Utkarsh Rai wrote: >>> >> >>> >> > Hello, this thread has gone a bit cold over the last few weeks, due to >>> >> > my engagement in the university tests. I have provided a debug trace >>> >> > for the issue. The reason for fatal exceptions is the fact that while >>> >> > iterating over the chain of user extensions we access a node whose >>> >> > memory location has been set to NO-ACCESS during the context switch. >>> >> > Is there any work-around to this? >>> >> >>> >> The option is to move the User_extensions_Iterator storage out of the >>> >> stack to Thread_Control and Per_CPU_Control. >>> >> >>> > >>> > Does this mean that I should add User_extensions_Iterator field in the >>> > Thread_Control structure for the case >>> > when we enable thread stack protection? >>> > >>> >>> You need to dig in a little bit more. From what I understand, there is >>> the last_user_extensions_iterator field of the TCB. That is probably >>> where you are running into some trouble. See >>> score/src/userextiterate.c :193 where this field gets assigned to a >>> stack-local variable. >> >> >> I get an exception just before this when _Chain_Iterator_initialize() is >> called, the reason though is the same, accessing >> a stack-local variable of a switched out thread. From what I could >> understand, the 'iter' variable(corresponding to the >> User_extensions_Iterator type) >> is the only stack-local variable of a switched out thread that is accessed >> from a different thread. >> >>> >>> Then, you can't walk this chain when the thread >>> is out of context. >>> >>> >> >>> >> -- >>> >> Sebastian Huber, embedded brains GmbH >>> >> >>> >> Address : Dornierstr. 4, D-82178 Puchheim, Germany >>> >> Phone : +49 89 189 47 41-16 >>> >> Fax : +49 89 189 47 41-09 >>> >> E-Mail : sebastian.hu...@embedded-brains.de >>> >> PGP : Public key available on request. >>> >> >>> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. >>> >> > > > > Based on the above suggestions I tried to move the User_extensions_Iterator > storage to the TCB by adding a new field to the structure, but that did not > compile(userextimpl.h is not included with thread.h because of cyclic > dependency). > This made me try out a naive hack, I defined a structure similar to the > User_extensions_Iterator and then added the field to the TCB. The next > problem that I faced was during the creation of the idle thread. Since an > idle thread is created during system > initialization, the 'executing' pointer pointing the TCB is null, and hence > referencing to the iterator placed in the TCB for the idle thread fails. This > was resolved by separating the cases for an idle thread and other threads. > After that I was able to successfully isolate more than two thread stacks. > Can you please suggest a more acceptable approach for resolving this issue? > At a high level the approach you took makes sense. You have moved the user extensions to the TCB, and then avoid accessing it in case the TCB is null (i.e., the initial context switch). I'd need to see the code to make any further critical analysis. But it sounds acceptable to me. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v4 0/1] Test for clock_nanosleep() with CLOCK_MONOTONIC option
i need to find time to look at this, and try it out. Does this compile? e.g., I don't see a definition of OPERATION_COUNT On Wed, Oct 28, 2020 at 7:34 AM Utkarsh Rai wrote: > > Ping. > > On Wed, Oct 21, 2020 at 8:58 AM Utkarsh Rai wrote: >> >> This patch has the tests for clock_nanosleep with the CLOCK_MONOTONIC option. >> The psxtests/psxclocknanosleep01/.. tests for valid timeout values as well as >> for the effect on timeout delay when REALTIME clock is modified(no effect). >> The timing tests are the similar to that for the REALTIME option(yielding and >> blocking). >> >> Utkarsh Rai (1): >> Test for clock_nanosleep() with CLOCK_MONOTONIC option >> >> .../psxtests/psxclocknanosleep01.yml | 19 +++ >> spec/build/testsuites/psxtmtests/grp.yml | 4 + >> .../psxtmtests/psxtmclocknanosleep04.yml | 19 +++ >> .../psxtmtests/psxtmclocknanosleep05.yml | 19 +++ >> .../psxtests/psxclocknanosleep01/init.c | 145 ++ >> .../psxclocknanosleep01.doc | 13 ++ >> .../psxclocknanosleep01.scn | 50 ++ >> .../psxtmtests/psxtmclocknanosleep04/init.c | 70 + >> .../psxtmtests/psxtmclocknanosleep05/init.c | 116 ++ >> 9 files changed, 455 insertions(+) >> create mode 100644 spec/build/testsuites/psxtests/psxclocknanosleep01.yml >> create mode 100644 >> spec/build/testsuites/psxtmtests/psxtmclocknanosleep04.yml >> create mode 100644 >> spec/build/testsuites/psxtmtests/psxtmclocknanosleep05.yml >> create mode 100644 testsuites/psxtests/psxclocknanosleep01/init.c >> create mode 100644 >> testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.doc >> create mode 100644 >> testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.scn >> create mode 100644 testsuites/psxtmtests/psxtmclocknanosleep04/init.c >> create mode 100644 testsuites/psxtmtests/psxtmclocknanosleep05/init.c >> >> -- >> 2.25.1 >> > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Fatal exceptions on context-switching for more than two isolated threads
On 04/11/2020 19:38, Gedare Bloom wrote: Based on the above suggestions I tried to move the User_extensions_Iterator storage to the TCB by adding a new field to the structure, but that did not compile(userextimpl.h is not included with thread.h because of cyclic dependency). This made me try out a naive hack, I defined a structure similar to the User_extensions_Iterator and then added the field to the TCB. The next problem that I faced was during the creation of the idle thread. Since an idle thread is created during system initialization, the 'executing' pointer pointing the TCB is null, and hence referencing to the iterator placed in the TCB for the idle thread fails. This was resolved by separating the cases for an idle thread and other threads. After that I was able to successfully isolate more than two thread stacks. Can you please suggest a more acceptable approach for resolving this issue? At a high level the approach you took makes sense. You have moved the user extensions to the TCB, and then avoid accessing it in case the TCB is null (i.e., the initial context switch). I'd need to see the code to make any further critical analysis. But it sounds acceptable to me. The executing thread pointer can be NULL and there is already a check for this in _User_extensions_Iterate(). In this case you can use a member in the _Per_CPU_Information[]. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [GCC PATCH] rtems: add __FIX_LEON3FT_TN0018 for affected targets
Hello Daniel,
could you please send this patch to the gcc-patches list. With a
ChangeLog entry in the commit message, for example:
gcc/
* config/sparch/rtemself.h (TARGET_OS_CPP_BUILTINS): Add built-in
define __FIX_LEON3FT_TN0018.
On 16/10/2020 16:55, Daniel Hellstrom wrote:
Enable a define FIX_LEON3FT_TN0018 for the LEON3FT targets affecdted
by the GRLIB-TN-0018 errata described here:
https://www.gaisler.com/notes
---
gcc/config/sparc/rtemself.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/config/sparc/rtemself.h b/gcc/config/sparc/rtemself.h
index 6570590..ddec98c 100644
--- a/gcc/config/sparc/rtemself.h
+++ b/gcc/config/sparc/rtemself.h
@@ -33,6 +33,8 @@
builtin_assert ("system=rtems"); \
if (sparc_fix_b2bst)\
builtin_define ("__FIX_LEON3FT_B2BST"); \
+ if (sparc_fix_gr712rc || sparc_fix_ut700 || sparc_fix_ut699) \
+ builtin_define ("__FIX_LEON3FT_TN0018"); \
} \
while (0)
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Certificate for docs.rtems.org expired?
Hello, The webmaster is probably aware, but just in case: Firefox and Edge don't let me connect to docs.rtems.org because of an invalid certificate. Probably, the certificate is expired. Connecting to www.rtems.org still works fine. Best regards, Jan Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR) German Aerospace Center Institute for Software Technology | Software for Space Systems and Interactive Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany Jan Sommer Telephone +49 531 295-2494 | Telefax 0531 295-2767 | jan.som...@dlr.de DLR.de/SC ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
