<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 9, 2021, 4:01 AM Sanskar Khandelwal <<a href="mailto:kdsanskar07@gmail.com">kdsanskar07@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello there,<br><br>I am interested in contributing to a few topics but I don't know what is the current status and future enhancements you are looking for so if you can guide me it would be a big help.<br><br> 1. Tracing<br>           1. #3028 :  Run-Time Tracing</div><div dir="ltr"></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">This works for getting a snapshot of tracing information from the target system, converting it to the Eclipse input format, and displaying it. We have a utility in rtems tools which listens to the target from the network and writes a file </div><div dir="auto"><br></div><div dir="auto">What's missing now is live tracing. Look that up for Linux Trace Toolkit. They have a utility which listens to the target and writes the live stream for Eclipse. For RTEMS, our utility or another one derived from it would have to listen to the target and write the stream. The target code to send the data may need tinkering to do it continuously.</div><div dir="auto"><br></div><div dir="auto">Live streaming should be a matter of assembling pieces and filling in gaps. You would want to start by using Eclipse to see streams from RTEMS as it does them today and live stream from Linux.</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 dir="ltr"><br>           2 .#3326 : Eclipse Target Communication Framework Support</div><div dir="ltr"></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I worked some on TCF this past year and what is going to need work isn't worth the payoff. We would need to rework libdebugger to integrate with the gdb command processor it provides.</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 dir="ltr"><br> 2.  #4162 : SiFive RISC-V HiFive Unleashed BSP (Qemu)<br></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I don't know how much can be reused from other BSPs. Would need to verify how much of the board is simulated by qemu and what peripherals are porting versus new </div><div dir="auto"><br></div><div dir="auto">We do not have a RISC-V BSP with networking so this is nice. We need to assess whether this is doable or how much in GSoC timeframe</div><div dir="auto"><br></div><div dir="auto">Good project though</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 dir="ltr"> 3.  #3302 : Build System conversion of BSP Config (.cfg) files to pkg-config (.pc) files<br></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I don't know the status of this. I thought we had these working. At least I don't know what's broken.</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 dir="ltr"><br></div>
</blockquote></div></div></div>