LwIP for RTEMS state querry Was: [PATCH rtems-lwip v2] STM32 lwIP addition

Thu Jul 22 17:25:10 UTC 2021

Hello,

I am still waiting on STM32 reply because of the licensing issue. Might
still take weeks/months..

Another solution would be to write some scripts to copy the code from the
Cube sources..
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.

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
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.

The current version of the rtems-lwip support after I added STM32H7 can
still be found here:
https://github.com/rmspacefish/rtems-lwip/tree/mueller/master
and includes the TMS570 code as well.

There is also a LPC port here:
https://github.com/sacha23/lwip-rtems-support/tree/master/src/ports/driver/lpc_emac
But that one still appears to use Makefiles, and needs to be updated to waf
if it is integrated.

Kind Regards
Robin

On Thu, 22 Jul 2021 at 00:10, Vijay Kumar Banerjee <vijay at rtems.org> wrote:

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