<div dir="ltr">Dear mentors,<br><br>Thankyou for providing information about the project. I want to pursue this as my GSoC project. From the above discussion, I understand that the following has to be done:<br>1. Collecting existing lwip drivers for BSPs and writing new ones.<br>2. Adding config files for driver management and also add lwip to the choice of networking stacks for RTEMS.<br>3. Write tests, examples and documentation<br><br>Please let me know if I am missing anything.<br><br>I have the following queries:<br>1. Should I buy a Beaglebone or can I do everything with QEMU? I have a Raspberry Pi 3B+. Can I use it for hardware testing instead?<br>2. I have cloned the rtems-lwip repository. Is there any open issue and documentation I can look into to get more understanding about this repos and the project in general?<br><br>Thanks and regards,<br>Rajiv<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 22 Mar 2021 at 01:06, Christian Mauderer <<a href="mailto:oss@c-mauderer.de">oss@c-mauderer.de</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"><br>
<br>
On 21/03/2021 18:53, Joel Sherrill wrote:<br>
> <br>
> <br>
> On Sun, Mar 21, 2021, 12:47 PM Vijay Kumar Banerjee <<a href="mailto:vijay@rtems.org" target="_blank">vijay@rtems.org</a> <br>
> <mailto:<a href="mailto:vijay@rtems.org" target="_blank">vijay@rtems.org</a>>> wrote:<br>
> <br>
> Hi Rajiv and Joel,<br>
> <br>
> On Sun, Mar 21, 2021 at 9:06 AM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a><br>
> <mailto:<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>>> wrote:<br>
> ><br>
> ><br>
> ><br>
> > On Sun, Mar 21, 2021, 9:20 AM Rajiv Vaidyanathan<br>
> <<a href="mailto:rajiv.vaidyanathan4@gmail.com" target="_blank">rajiv.vaidyanathan4@gmail.com</a><br>
> <mailto:<a href="mailto:rajiv.vaidyanathan4@gmail.com" target="_blank">rajiv.vaidyanathan4@gmail.com</a>>> wrote:<br>
> >><br>
> >> Hello RTEMS community,<br>
> >><br>
> >> I found the ticket: Modular Network Stacks interesting. It would<br>
> be great if someone can tell the current status of this ticket and<br>
> what contributions can be done as a GSoC project.<br>
> >><br>
> >> In the prerequisites list given, I have experience in UNIX<br>
> socket programming (in C and python), OSI model, basic Wireshark but<br>
> I don't have much experience in assembly (I can read assembly but<br>
> haven't written assembly code) and device drivers. It would be great<br>
> if someone can guide me if I can take up this project.<br>
> ><br>
> ><br>
> > Vijay is the primary mentor for this but I can give you an<br>
> outline of what there is to do.<br>
> ><br>
> > RTEMS historically had a 20 to 25 year old port of the FreeBSD<br>
> tcpip stack. This was ipv4 only and the source was included in the<br>
> main RTEMS repository. It was enabled or disabled via a configure flag.<br>
> ><br>
> > There is now the libbsd repository which is a port of the current<br>
> FreeBSD with many features and drivers. It has a focus on what we<br>
> call source transparency which means that we do not make changes to<br>
> it unless I absolutely necessary and try to preserve the original<br>
> source as much as possible. This makes it possible to largely update<br>
> the source using scripts. We currently track the FreeBSD 12 release<br>
> branch and their development version.<br>
> ><br>
> > With two tcp/ip stacks, it becomes necessary to be able to switch<br>
> between them. This project had a first step which was to move the<br>
> legacy stack into its own repository. Thanks to Vijay, you can now<br>
> build RTEMS without a tcpip stack at all. Then you download and add<br>
> on the tcp/ip stack of your choice - legacy or libbsd.<br>
> ><br>
> > But there's a third tcp/ip stack we are interested in. The lwip<br>
> stack is targeted at lower memory profiles and is not as full<br>
> featured as libbsd. We need an lwip RTEMS repository which includes<br>
> lwip, drivers for a variety of BSPs, its own build system, tests,<br>
> examples, and any services specific to lwip. Lwip as a project does<br>
> not do a good job of providing a central location for device drivers<br>
> so the RTEMS lwip repo will be a collection point. providing a<br>
> robust set of drivers and keeping track of where they came from and<br>
> maintaining Source transparency is key.<br>
> ><br>
> > This arrangement allows anyone to pick from the set of stacks we<br>
> support as long as they deal with the device driver.<br>
> ><br>
> > The GSoC project you would be proposing is the lwip part. We have<br>
> a build of it from a user's application to go by for a working<br>
> example of the stack. Probably completely ignore the default lwip<br>
> build system and uae a waf build system (Python).<br>
> ><br>
> The prototype for this repository is ready!<br>
> rtems-lwip: <a href="https://git.rtems.org/vijay/rtems-lwip.git/" rel="noreferrer" target="_blank">https://git.rtems.org/vijay/rtems-lwip.git/</a><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>
> This build follows a similar approach to rtems-libbsd and I have<br>
> also added a testcase to it, by modifying the networking01.exe from<br>
> the legacy repo.<br>
> <br>
> > I think this is very doable as GSoC project. Vijay already did<br>
> separate the legacy stack into its own repository, we have a test<br>
> case BSP, and there is a defined patter to follow.<br>
> ><br>
> I think the first step would be identify a target that we can run on<br>
> qemu as well as hardware and focus on that target. Porting that<br>
> target to LWIP would involve adding a driver to rtems-lwip, along<br>
> with a set up to manage the drivers. For managing different drivers,<br>
> I propose an ini or yaml configuration file that can be used by waf<br>
> scripts to decide which driver to build for a particular bsp.<br>
> <br>
> <br>
> I think Gedare and I chatted about this so I had some in mind. Zynq and <br>
> MPSoC have lwip drivers from xilinx and both run on qemu.<br>
> <br>
> <a href="https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842366/Standalone+LWIP+library" rel="noreferrer" target="_blank">https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842366/Standalone+LWIP+library</a> <br>
> <<a href="https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842366/Standalone+LWIP+library" rel="noreferrer" target="_blank">https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842366/Standalone+LWIP+library</a>><br>
<br>
If it works with the zynq qemu BSP, I think that would be great for that <br>
kind of stuff. That BSP is always great for debugging (although most <br>
likely there will be few C-Code-Work in this repo) because you don't <br>
need extra hardware.<br>
<br>
> <br>
> The other top alternative is the PC.<br>
<br>
PC is hard for debugging. I never searched but I think you most likely <br>
don't find many with JTAG connectors ;-)<br>
<br>
Beagle could be an alternative for real hardware. I found at least one <br>
lwip driver for that.<br>
<br>
> <br>
> I can't remember what Alan Cudmore was using but it would be good to at <br>
> least include it so he can possibly provide feedback on his target.<br>
> <br>
> I would expect STM boards also have l whip drivers from the vendor in <br>
> their device driver kit.<br>
<br>
If there is a driver for one of the supported boards, that would be a <br>
nice target too. Most of the STM boards have debuggers already on board.<br>
<br>
Best regards<br>
<br>
Christian<br>
<br>
> <br>
> <br>
> So, roughly the todos for the application phase would be to identify<br>
> a potential target and divide the driver work in two phases as per<br>
> GSoC schedule. This also involves collecting all the old/previously<br>
> ported drivers in one place inside lwip, this will also act as a<br>
> reference on how to proceed with the driver for a new target.<br>
> <br>
> <br>
> Lwip is particularly bad at providing a unified place for drivers. This <br>
> is something I never wanted to happen with RTEMS. I think a big value of <br>
> this effort will be collecting drivers that can work with RTEMS bsps.<br>
> <br>
> <br>
> <br>
> <br>
> Best regards,<br>
> Vijay<br>
> <br>
> > That's the project in a nutshell. Vijay should speak up and add on.<br>
> ><br>
> >><br>
> >> Thanks and regards,<br>
> >> Rajiv<br>
> >> _______________________________________________<br>
> >> devel mailing list<br>
> >> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a> <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a>><br>
> >> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> <<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a>><br>
> ><br>
> > _______________________________________________<br>
> > devel mailing list<br>
> > <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a> <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a>><br>
> > <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> <<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a>><br>
> <br>
> <br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> <br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div>