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 <chr...@rtems.org> wrote
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
