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>> wrote:
Hi Rajiv and Joel,
On Sun, Mar 21, 2021 at 9:06 AM Joel Sherrill <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>> 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/>
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>
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>
>> 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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
