<div dir="ltr">Dear mentors,<div><br></div><div>Thank you for providing information regarding the project. I have started making the proposal for this ticket. I'll share it once I have a draft of it ready.</div><div><br></div><div>Thanks and regards,</div><div>Rajiv</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 22 Mar 2021 at 21:43, Joel Sherrill <<a href="mailto:joel@rtems.org">joel@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"><div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 22, 2021, 10:23 AM Christian Mauderer <<a href="mailto:contact@c-mauderer.de" target="_blank">contact@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">Hello Rajiv,<br>
<br>
Am 22.03.21 um 16:11 schrieb Rajiv Vaidyanathan:<br>
> Dear mentors,<br>
> <br>
> Thankyou for providing information about the project. I want to pursue <br>
> this as my GSoC project. From the above discussion, I understand that <br>
> 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 <br>
> choice of networking stacks for RTEMS.<br>
> 3. Write tests, examples and documentation<br>
> <br>
<br>
The main point will be to create a build repo for lwip similar to the<br>
repo for libbsd or the legacy stack (that is currently work in <br>
progress). That repo should contain maybe one or two drivers as an <br>
example how they should be integrated into the repo. You don't have to <br>
find all possible drivers for all BSPs.<br>
<br>
That repo should contain tests and there should be at least basic <br>
documentation how to use it. More documentation is better ;-)<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 <br>
> Raspberry Pi 3B+. Can I use it for hardware testing instead?<br>
<br>
Basically every BSP should work as long as you find a lwip driver that <br>
can work with it. I would suggest to look at the xilinx_zynq_a9_qemu and <br>
whether you can find a driver for that. It works well with libbsd and an <br>
emulated "cadence_gem" network interface. If you find a lwip driver for <br>
that, it would be easy to debug that.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I'm prone to say the first focus should be on drivers that we can test with simulators specifically qemu. That puts the Zynq, MPSoC, and PC high on the list. My second tier would be those we know have users now which is the STM H7 and whatever Alan Cudmore is using. For that tier, it should have just be helping merge and letting them test.</div><div dir="auto"><br></div><div dir="auto">Focusing on what can work on qemu and what users are actively using lwip on now should result in having a solid core of drivers to build from in the future. And it should avoid the pain of debugging a driver on real hardware while leaving the project with some that are easy to test.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If you want to use a Raspberry, that is OK too. But I'm not entirely <br>
sure whether RTEMS run well out of the box on Raspberry 3B+. So please <br>
test that before you focus too much on that platform. Also note that <br>
debugging on a Raspberry needs extra hardware (same is true for <br>
debugging on a Beagle). You most likely won't need too much debugging of <br>
applications but it's nice to have it as a fall back if something <br>
doesn't work.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I do not think anything newer than a raspberry 2 works without addressing some issues. This could easily turned into a time sucker that will have no benefit to having an lwip package.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> 2. I have cloned the rtems-lwip repository. Is there any open issue and <br>
> documentation I can look into to get more understanding about this repos <br>
> and the project in general?<br>
<br>
It's a personal repo of Vijay. So he might can give you some information <br>
about it. I don't think that there is much documentation.<br>
<br>
Best regards<br>
<br>
Christian<br>
<br>
> <br>
> Thanks and regards,<br>
> Rajiv<br>
> <br>
> On Mon, 22 Mar 2021 at 01:06, Christian Mauderer <<a href="mailto:oss@c-mauderer.de" rel="noreferrer" target="_blank">oss@c-mauderer.de</a> <br>
> <mailto:<a href="mailto:oss@c-mauderer.de" rel="noreferrer" target="_blank">oss@c-mauderer.de</a>>> wrote:<br>
> <br>
> <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<br>
> <<a href="mailto:vijay@rtems.org" rel="noreferrer" target="_blank">vijay@rtems.org</a> <mailto:<a href="mailto:vijay@rtems.org" rel="noreferrer" target="_blank">vijay@rtems.org</a>><br>
> > <mailto:<a href="mailto:vijay@rtems.org" rel="noreferrer" target="_blank">vijay@rtems.org</a> <mailto:<a href="mailto:vijay@rtems.org" rel="noreferrer" 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" rel="noreferrer" target="_blank">joel@rtems.org</a><br>
> <mailto:<a href="mailto:joel@rtems.org" rel="noreferrer" target="_blank">joel@rtems.org</a>><br>
> > <mailto:<a href="mailto:joel@rtems.org" rel="noreferrer" target="_blank">joel@rtems.org</a> <mailto:<a href="mailto:joel@rtems.org" rel="noreferrer" 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" rel="noreferrer" target="_blank">rajiv.vaidyanathan4@gmail.com</a><br>
> <mailto:<a href="mailto:rajiv.vaidyanathan4@gmail.com" rel="noreferrer" target="_blank">rajiv.vaidyanathan4@gmail.com</a>><br>
> > <mailto:<a href="mailto:rajiv.vaidyanathan4@gmail.com" rel="noreferrer" target="_blank">rajiv.vaidyanathan4@gmail.com</a><br>
> <mailto:<a href="mailto:rajiv.vaidyanathan4@gmail.com" rel="noreferrer" target="_blank">rajiv.vaidyanathan4@gmail.com</a>>>> wrote:<br>
> > >><br>
> > >> Hello RTEMS community,<br>
> > >><br>
> > >> I found the ticket: Modular Network Stacks interesting.<br>
> It would<br>
> > be great if someone can tell the current status of this<br>
> 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<br>
> 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<br>
> 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<br>
> in the<br>
> > main RTEMS repository. It was enabled or disabled via a<br>
> configure flag.<br>
> > ><br>
> > > There is now the libbsd repository which is a port of the<br>
> 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<br>
> 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<br>
> update<br>
> > the source using scripts. We currently track the FreeBSD 12<br>
> release<br>
> > branch and their development version.<br>
> > ><br>
> > > With two tcp/ip stacks, it becomes necessary to be able to<br>
> 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<br>
> can now<br>
> > build RTEMS without a tcpip stack at all. Then you download<br>
> 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<br>
> 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<br>
> 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<br>
> project does<br>
> > not do a good job of providing a central location for device<br>
> 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<br>
> from and<br>
> > maintaining Source transparency is key.<br>
> > ><br>
> > > This arrangement allows anyone to pick from the set of<br>
> 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.<br>
> 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 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 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 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 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<br>
> 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<br>
> 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<br>
> drivers,<br>
> > I propose an ini or yaml configuration file that can be used<br>
> 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.<br>
> Zynq and<br>
> > MPSoC have lwip drivers from xilinx and both run on qemu.<br>
> ><br>
> ><br>
> <a href="https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842366/Standalone+LWIP+library" rel="noreferrer 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 noreferrer" target="_blank">https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842366/Standalone+LWIP+library</a>><br>
> <br>
> ><br>
> <<a href="https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842366/Standalone+LWIP+library" rel="noreferrer 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 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<br>
> 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<br>
> 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<br>
> 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<br>
> identify<br>
> > a potential target and divide the driver work in two phases<br>
> as per<br>
> > GSoC schedule. This also involves collecting all the<br>
> 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<br>
> drivers. This<br>
> > is something I never wanted to happen with RTEMS. I think a big<br>
> 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<br>
> and add on.<br>
> > ><br>
> > >><br>
> > >> Thanks and regards,<br>
> > >> Rajiv<br>
> > >> _______________________________________________<br>
> > >> devel mailing list<br>
> > >> <a href="mailto:devel@rtems.org" rel="noreferrer" target="_blank">devel@rtems.org</a> <mailto:<a href="mailto:devel@rtems.org" rel="noreferrer" target="_blank">devel@rtems.org</a>><br>
> <mailto:<a href="mailto:devel@rtems.org" rel="noreferrer" target="_blank">devel@rtems.org</a> <mailto:<a href="mailto:devel@rtems.org" rel="noreferrer" target="_blank">devel@rtems.org</a>>><br>
> > >> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> <<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a>><br>
> > <<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> <<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a>>><br>
> > ><br>
> > > _______________________________________________<br>
> > > devel mailing list<br>
> > > <a href="mailto:devel@rtems.org" rel="noreferrer" target="_blank">devel@rtems.org</a> <mailto:<a href="mailto:devel@rtems.org" rel="noreferrer" target="_blank">devel@rtems.org</a>><br>
> <mailto:<a href="mailto:devel@rtems.org" rel="noreferrer" target="_blank">devel@rtems.org</a> <mailto:<a href="mailto:devel@rtems.org" rel="noreferrer" target="_blank">devel@rtems.org</a>>><br>
> > > <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> <<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a>><br>
> > <<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> <<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer 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" rel="noreferrer" target="_blank">devel@rtems.org</a> <mailto:<a href="mailto:devel@rtems.org" rel="noreferrer" target="_blank">devel@rtems.org</a>><br>
> > <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> <<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a>><br>
> ><br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" rel="noreferrer" target="_blank">devel@rtems.org</a> <mailto:<a href="mailto:devel@rtems.org" rel="noreferrer" target="_blank">devel@rtems.org</a>><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> <<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a>><br>
> <br>
</blockquote></div></div></div>
</blockquote></div>