<div dir="ltr"><div>Hello,</div><div><br></div><div>I am still waiting on STM32 reply because of the licensing issue. Might still take weeks/months..</div><div><br></div><div>Another solution would be to write some scripts to copy the code from the Cube sources.. <br></div><div>But I would prefer to avoid them, because I also had to merge some of the files provided by STM so that I could use/test all three APIs.</div><div><br></div><div>I was able to test and use all major APIs on a STM32H7 board with RTEMS, including the Socket API.. Although I disliked about the Socket API that it's <br></div><div>easy to forget the cache invalidation on the TX/RX buffers (forgot which one it was) if they are not protected via MPU but that's also a STM32H7 specific issue.</div><div><br></div><div>The current version of the rtems-lwip support after I added STM32H7 can still be found here: <a href="https://github.com/rmspacefish/rtems-lwip/tree/mueller/master">https://github.com/rmspacefish/rtems-lwip/tree/mueller/master</a></div><div>and includes the TMS570 code as well.</div><div><br></div><div>There is also a LPC port here: <a href="https://github.com/sacha23/lwip-rtems-support/tree/master/src/ports/driver/lpc_emac">https://github.com/sacha23/lwip-rtems-support/tree/master/src/ports/driver/lpc_emac</a></div><div>But that one still appears to use Makefiles, and needs to be updated to waf if it is integrated.</div><div><br></div><div>Kind Regards</div><div>Robin<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 22 Jul 2021 at 00:10, Vijay Kumar Banerjee <<a href="mailto:vijay@rtems.org">vijay@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
<br>
On Wed, Jul 21, 2021 at 2:25 AM Pavel Pisa <<a href="mailto:ppisa4lists@pikron.com" target="_blank">ppisa4lists@pikron.com</a>> wrote:<br>
><br>
> Hello Vijay,<br>
><br>
> thanks of the status.<br>
><br>
<br>
I added a note in the devel page: <a href="https://devel.rtems.org/wiki/Packages/LWIP" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/Packages/LWIP</a><br>
<br>
<br>
<br>
> On Wednesday 21 of July 2021 07:16:51 Vijay Kumar Banerjee wrote:<br>
> > Hi Pavel,<br>
> ><br>
> > On Tue, Jul 20, 2021 at 1:13 PM Pavel Pisa <<a href="mailto:ppisa4lists@pikron.com" target="_blank">ppisa4lists@pikron.com</a>> wrote:<br>
> > > Is it devel branch of  Vijay Kumar Banerjee's<br>
> > > repo<br>
> > ><br>
> > >   <a href="https://git.rtems.org/vijay/rtems-lwip.git/" rel="noreferrer" target="_blank">https://git.rtems.org/vijay/rtems-lwip.git/</a><br>
> ><br>
> > Right now yes. Once this is mature, it will probably be pushed to the<br>
> > top directory.<br>
> ><br>
> > > If so, it would worth to put that on the top<br>
> > > of LwIP RTEMS info page to guide people interested<br>
> > > to live work and not lose time in another<br>
> > > abandonned attempts<br>
> > ><br>
> > >   <a href="https://devel.rtems.org/wiki/Packages/LWIP" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/Packages/LWIP</a><br>
> ><br>
> > Thanks, I'll add a note there.<br>
> ><br>
> > > Addition of pointers to STM WIP to some<br>
> > > central place would worth too with<br>
> > > pointer to the instructions or instructions<br>
> > > included...<br>
> ><br>
> > I haven't tested it myself. Robin is working on this one and might be<br>
> > able to add the instructions. But this is supposed to be merged into<br>
> > the repo you mentioned above.<br>
><br>
> Great that there is the common merge place.<br>
><br>
><br>
> > > Generally I am curious what works and where<br>
> > > are problems. I do not expect to have time or<br>
> > > find students this summer but I try to offer<br>
> > > project as theses and next summer and there<br>
> > > chance (small) that I find some studnet<br>
> > > to participate.<br>
> ><br>
> > I am currently actively working on the lwip port to get it working<br>
> > with at least a few boards, along with a streamlined build system. I<br>
> > could only get the BBB running with a telnetd application that I added<br>
> > in the test/ directory in the rtems-lwip repository. I used the<br>
> > drivers from TI for BBB.<br>
><br>
> OK, I have some access to BBB so when my or some studnet<br>
> time allows we can test it on this target.<br>
Thanks. Any feedback would be really appreciated.<br>
<br>
> I am more personally interested to TMS570.<br>
> I think that I can find some time for testing on TMS570LS3137<br>
> if the instructions and code is declared to worth to test.<br>
> I hope that I have all tools for this setup.<br>
><br>
This has not been tested yet, I'm working on the build system to<br>
streamline the process further. It would be great to get this port<br>
tested. Please ping me if you have any build issues when testing (if<br>
you happen to test before the build system update :) ).<br>
<br>
<br>
> =============================================================<br>
> Side note to TMS570 FEE CTU code (if there is interest,<br>
> I it would worth to move to separate thread)<br>
><br>
> By the way, the way my former colleagues who left faculty<br>
> stopped blocking (after many years) TMS570 Rapid Prototyping<br>
> Platform code<br>
>   <a href="http://rtime.felk.cvut.cz/rpp-tms570/" rel="noreferrer" target="_blank">http://rtime.felk.cvut.cz/rpp-tms570/</a><br>
> and changed master branch license to MIT (The work has been<br>
> exploited to gain money from their industrial partners and has<br>
> little value for them now). Code was and is licensed under our<br>
> faculty name and I can legally show it to third parties now<br>
> and  try to find arrangement to share my and my students effort<br>
> with community.<br>
><br>
> There is XCP <a href="https://en.wikipedia.org/wiki/XCP_(protocol)" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/XCP_(protocol)</a><br>
> loader implemented on FreeRTOS base which allows to update<br>
> firmware over ETHERNET so it can be used as boot block for<br>
> RTEMS. It can make RTEMS support testing and even continuous<br>
> integration much easier. When RTEMS is run from SDRAM it<br>
> would prevent Flash wear-out, important for TMS570,<br>
> because guaranteed erase cycles are limited.<br>
><br>
> Then there is support for lot of the TMS570 peripherals<br>
> in the state twisted with HalCoGen, not directly usable,<br>
> but valuable as reference. Lot of Matlab/Simulink glue<br>
> which can be reused with minimal changes and  N2HET and<br>
> DMA based "HW" implementation of time triggered CAN<br>
> transfers with clock scaling and synchronization.<br>
><br>
> So if there is interest, I can provide more information<br>
> and collect it in RTEMS Wiki or on<br>
><br>
>   Open Technologies Research Education and Exchange Services<br>
>   <a href="https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home" rel="noreferrer" target="_blank">https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home</a><br>
><br>
> pages, which are intended primarily for cooperation with<br>
> our students.<br>
><br>
> As for original RTIME wiki and documentation (even documenting<br>
> RTEMS and GNU/Linux work shared from my company, done with studnets,<br>
> myself at home), I do not expect to contribute to it any more.<br>
> Even that substantial part is result of my 25 years of investent<br>
> to that group but its leaders took it with them to another<br>
> place with end expressed strong will/command to not contact<br>
> "their" people anymore. Most of them have left them anyway<br>
> so no problem to ask them for advises and help directly.<br>
> =============================================================<br>
> Back to LwIP<br>
><br>
> Extending loader and OpenOCD support for TMS570LC4357<br>
> is another target long-term on my list.<br>
><br>
I'm interested in TMS570LC4357 and would like to you join efforts on this one.<br>
<br>
> Back to LwIP, I see some your effort to implement<br>
> select  sowwakeup(so); and sorwakeup() based<br>
> on some code copied from BSD stack<br>
><br>
>   <a href="https://git.rtems.org/vijay/rtems-lwip.git/tree/netinet?h=devel" rel="noreferrer" target="_blank">https://git.rtems.org/vijay/rtems-lwip.git/tree/netinet?h=devel</a><br>
><br>
> I think that there would be problem to integrate<br>
> select cleanly when LwIP SOCK API is used.<br>
> If we limit select only on sockets, then the option<br>
> is to translate FD sets to LwIP struct *socket and<br>
> then use LwIP select implementation. But I do not like<br>
> this approach. I would prefer if the select mechanism<br>
> is part of RTEMS core, allows character devices (UART...)<br>
> support and stack provides only mechanism how to register<br>
> into this generic support.<br>
><br>
> I think that such arrangement would not be problem with LwIP<br>
> when NETCON API is used. But select support in RTEMS<br>
> core could be problem for BSD stack implementation<br>
> seamless plugin into core.... So I suggest some discussion<br>
> and ideas posted by others in this respect.<br>
><br>
Thank you for the feedback on the APIs, I'll look into the NETCONN API<br>
and start a discussion in a separate thread.<br>
<br>
Best regards,<br>
Vijay<br>
> Best wishes,<br>
><br>
>                 Pavel Pisa<br>
>     e-mail:     <a href="mailto:pisa@cmp.felk.cvut.cz" target="_blank">pisa@cmp.felk.cvut.cz</a><br>
>     Department of Control Engineering FEE CVUT<br>
>     Karlovo namesti 13, 121 35, Prague 2<br>
>     university: <a href="http://dce.fel.cvut.cz/" rel="noreferrer" target="_blank">http://dce.fel.cvut.cz/</a><br>
>     personal:   <a href="http://cmp.felk.cvut.cz/~pisa" rel="noreferrer" target="_blank">http://cmp.felk.cvut.cz/~pisa</a><br>
>     projects:   <a href="https://www.openhub.net/accounts/ppisa" rel="noreferrer" target="_blank">https://www.openhub.net/accounts/ppisa</a><br>
>     CAN related:<a href="http://canbus.pages.fel.cvut.cz/" rel="noreferrer" target="_blank">http://canbus.pages.fel.cvut.cz/</a><br>
</blockquote></div>