Planning for RTEMS 6 Branch

[Joel Sherrill]

On Wed, Dec 16, 2020, 6:38 PM smallphd at aliyun.com <smallphd at 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.




> ------------------------------
> smallphd at aliyun.com
>
>
> *From:* Joel Sherrill <joel at rtems.org>
> *Date:* 2020-12-17 03:39
> *To:* rtems-devel at rtems.org <devel at rtems.org>; David Edelsohn
> <dje.gcc at gmail.com>
> *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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20201216/4a5c6528/attachment-0001.html>