<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 16, 2020, 6:38 PM <a href="mailto:smallphd@aliyun.com">smallphd@aliyun.com</a> <<a href="mailto:smallphd@aliyun.com">smallphd@aliyun.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<div><span></span>Hi, joel</div><div>Our team is developing a pcie card running rtems. The <span style="background-color:rgba(0,0,0,0);font-size:10.5pt;line-height:1.5">stability is very important for us.</span></div><div><span style="background-color:rgba(0,0,0,0);font-size:10.5pt;line-height:1.5">Currently we are using rtems 5.1. Are there plans for rtems 5.x ? Such as bug fixes, new features, etc.</span></div><div>"<span style="font-size:10.5pt;line-height:1.5;background-color:window">aarch64 on real hardware and SMP</span><span style="font-size:10.5pt;line-height:1.5;background-color:window">" is what we really wanted. Does this feature will be supported by rtems 5.x ?</span></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">RTEMS release branches are considered feature complete and the focus is on bug fixes.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">I hope this helps. Bug fixes in release branches and features added on master working to the next release.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<div><br></div><hr style="width:210px;height:1px" color="#b5c4df" size="1" align="left">
<div><span><div style="MARGIN:10px;FONT-FAMILY:verdana;FONT-SIZE:10pt"><div><a href="mailto:smallphd@aliyun.com" target="_blank" rel="noreferrer">smallphd@aliyun.com</a></div></div></span></div>
<blockquote style="margin-top:0px;margin-bottom:0px;margin-left:0.5em"><div> </div><div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm 0cm 0cm"><div style="PADDING-RIGHT:8px;PADDING-LEFT:8px;FONT-SIZE:12px;FONT-FAMILY:tahoma;COLOR:#000000;BACKGROUND:#efefef;PADDING-BOTTOM:8px;PADDING-TOP:8px"><div><b>From:</b> <a href="mailto:joel@rtems.org" target="_blank" rel="noreferrer">Joel Sherrill</a></div><div><b>Date:</b> 2020-12-17 03:39</div><div><b>To:</b> <a href="mailto:devel@rtems.org" target="_blank" rel="noreferrer">rtems-devel@rtems.org</a>; <a href="mailto:dje.gcc@gmail.com" target="_blank" rel="noreferrer">David Edelsohn</a></div><div><b>Subject:</b> Planning for RTEMS 6 Branch</div></div></div><div><div><div dir="ltr">Hi<div><br></div><div>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:</div><div><br></div><div>+ Waf switchover complete<br></div><div>+ NFSv4<br></div><div>+ aarch64 on real hardware and SMP<br></div><div><br></div><div>I would expect all of this to be available in early 2021.</div><div><br></div><div>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.</div><div><br></div><div>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.<br><br>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.</div><div><br></div><div>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.</div><div><br></div><div>Thoughts?</div><div><br></div><div>--joel</div></div>
</div></div></blockquote>
</div></blockquote></div></div></div>