EPICS and RTEMS BSPs

[Joel Sherrill]

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 <chrisj at rtems.org> wrote
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20201104/9b6ff6fa/attachment-0001.html>