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