Using LwIP on the STM32H7

Mon Feb 1 23:36:30 UTC 2021

On Mon, Feb 1, 2021 at 5:16 PM Mr. Andrei Chichak <groups at chichak.ca> wrote:

> Can you point me at Sebastian’s driver? I haven’t been able to find it in
> the repo.
>

Here's the trick. Look in rtemsbsd/include/bsp/nexus-devices.h and search
for the
header guard from your BSP.  It references an stmac driver which find tells
me is
./rtemsbsd/sys/dev/stmac/if_stmac.c. I am sure the directory has other
files.

That's the magic path. Takes some getting used to.

--joel

>
> A
>
> On 2021-February-01, at 16:05, Joel Sherrill <joel at rtems.org> wrote:
>
>
>
> On Mon, Feb 1, 2021 at 4:54 PM Mr. Andrei Chichak <groups at chichak.ca>
> wrote:
>
>> Oh, crap, I’m off by 3 orders of magnitude, I’ve got 512KB.
>>
>
> That's an LWIP candidate. :)
>
> But Sebastian did a driver for libbsd for the H7 series. If you have more
> memory
> or can attach external RAM, that's an option.
>
>
>> Bother, I need a nap already.
>>
>> A
>>
>> On 2021-February-01, at 15:35, Joel Sherrill <joel at rtems.org> wrote:
>>
>>
>>
>> On Mon, Feb 1, 2021 at 4:25 PM Andrei Chichak <andrei at chichak.ca> wrote:
>>
>>> any guidance choosing between “Legacy Stack” and libbsd?
>>>
>>
>> This one is easy. Please please please please do NOT choose the legacy
>> stack. :)
>>
>> The legacy stack should only be used on projects that are using it and
>> those
>> are encouraged to move along to libbsd or lwip or new hardware.  We have
>> no
>> plans to eliminate the legacy stack from the world. But as Gedare said,
>> we want
>> to move it to a separate repository. If someone cares, then it gets a
>> build system
>> and can be used with a strong discouragement.
>>
>> It is 20+ years old now and IPV4 only. Do the math. :)
>>
>>
>>>
>>> I’ve got a 512MB of RAM processor, so I expect that I’ll have lots left
>>> over. But that is TBD.
>>>
>>
>> 512MB is still huge in RTEMS terms. That won't be a problem for libbsd at
>> all.  It is when you
>> start considering targets with < 16MB that we have concerns. I suspect
>> that number is <4MB
>> but the original BSP for the legacy stack only had 1MB for code and data
>> space. It is clear
>> some boards that could run the legacy stack will not be capable of
>> running libbsd but we
>> don't have a hard cutoff yet.
>>
>> --joel
>>
>>>
>>> A
>>>
>>> On 2021-February-01, at 15:21, Joel Sherrill <joel at rtems.org> wrote:
>>>
>>>
>>>
>>> On Mon, Feb 1, 2021 at 4:03 PM Gedare Bloom <gedare at rtems.org> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Feb 1, 2021 at 2:42 PM Chris Johns <chrisj at rtems.org> wrote:
>>>>
>>>>> On 2/2/21 8:32 am, Mr. Andrei Chichak wrote:
>>>>> > Is there any advantage to using bsd networking over LWiP, or vice
>>>>> versa?
>>>>>
>>>>> They are different stacks with different feature sets and different
>>>>> hardware
>>>>> resource demands. I am not familiar with the features of LwIP so I am
>>>>> not the
>>>>> best person to compare them.
>>>>>
>>>>> The BSD stack has most of the features you get with FreeBSD. It has
>>>>> IPv4, IPv6,
>>>>> IPsec, VLAN, bridging, dhcp, openssl, lots of routing alternatives,
>>>>> packet
>>>>> filtering and more. It has a range of useful commands including
>>>>> tcpdump.
>>>>>
>>>>> The BSD based system provides a solid base to solve a range of
>>>>> networking issues
>>>>> your RTEMS device may encounter at the system level and not at the low
>>>>> level
>>>>> programming level.
>>>>>
>>>>> The BSD stack uses a lot more resources to do all this and LwIP may be
>>>>> a prefect
>>>>> fit. I welcome RTEMS being able to support a range of networking
>>>>> solutions.
>>>>>
>>>>>
>>>> I have a student (Vijay) working on refactoring libnetworking out of
>>>> RTEMS, and will be testing ability to compile legacy vs libbsd. If the lwip
>>>> build is demonstrated and clear, I can have him also look at bringing that
>>>> into the fold. This is in line with https://devel.rtems.org/ticket/3850
>>>>
>>>
>>> One thing to be aware of is that all the POSIX networking header files
>>> for RTEMS are in newlib and always present. I had to address this and lwip
>>> when we did Deos+RTEMS. Deos uses lwip as their native stack running in a
>>> partition and other partitions use a client to get to it. The lwip
>>> constants had values that were not the same as the RTEMS BSD headers for
>>> POSIX defines. There were also some places where the structure definitions
>>> did not align. I had to write a bit of mapping in the client. When lwip
>>> works at all, it would be awesome to have a way for it to ignore their own
>>> minimal POSIX API files and build against ours.
>>>
>>> This would be similar to how the newlib headers define a very complete
>>> POSIX API set but each target OS may only support a subset of it.
>>>
>>> As it is, I wonder if there is a conflict between the RTEMS newlib
>>> network .h files and those provided by lwip which could cause issues.
>>>
>>>
>>>>
>>>> We have no certain timeline yet, but it is now work-in-progress. We
>>>> will bring to devel when progress is made. If we do lwIP too, we will aim
>>>> to do a performance analysis with real hardware, so that we can hopefully
>>>> provide evidence to help these kind of questions.
>>>>
>>>> -Gedare
>>>>
>>>> Chris
>>>>>
>>>> _______________________________________________
>>>> users mailing list
>>>> users at rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/users
>>>
>>> _______________________________________________
>>> users mailing list
>>> users at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/users
>>>
>>>
>>> ---------------------
>>> Andrei Chichak
>>> 4024-120 STREET
>>> EDMONTON, ALBERTA
>>> T6J 1X8
>>> CANADA
>>>
>>>
>>> Phone: 780-434-6266
>>> Skype: andrei.chichak
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>> users mailing list
>> users at rtems.org
>> http://lists.rtems.org/mailman/listinfo/users
>>
>>
>>
>> _______________________________________________
>> users mailing list
>> users at rtems.org
>> http://lists.rtems.org/mailman/listinfo/users
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20210201/660bb927/attachment.html>