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

Joel Sherrill joel at rtems.org
Thu Jul 22 20:19:21 UTC 2021 

On Thu, Jul 22, 2021 at 12:25 PM Robin Müller <robin.mueller.m at gmail.com> wrote:
>
> Hello,
>
> I am still waiting on STM32 reply because of the licensing issue. Might still take weeks/months..

The Ultimate Liberty license is a bit of a misnomer. Quite a few
restrictions on liberty there.

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

I remember this long discussion. Is this something that might show up
again on other drivers?

I'm just wondering if this is really a one-off or something we need a
pattern for.

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

Very nice. Updating to waf should be a lot easier than writing the driver. :)

Vijay.. it's your call but if adding drivers with status of "compile
only" is OK with you, that at least lays the groundwork for someone
else to test later. I'm just thinking that compiles and untested makes
it easy for someone to push it across the goal line.

--joel

> 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/
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

More information about the devel mailing list