Using LwIP on the STM32H7

Tue Feb 2 11:28:18 UTC 2021

I might submit the patch today. I have not really found a clean way to
introduce the sections required for lwIP on the STM32H7 without editing the
linkcmds.base file unfortunately and I'm not a linker command expert.
If I add the linkmds.lwip after the linkcmds.base include, I get the
unexpected section error, if I place them before the include, the sections
are placed before the start section, invalidating the generated binary.

I like the solution provided by STM to use the SRAM3 exclusively for
networking (limits RX and TX buffers to roughly 16 kB though) and it has
worked nicely for my use case (simple small UDP datagrams),
but it is probably also possible to place the descriptors and RAM somewhere
else as long as the MPU is configured correctly.

Kind Regards
Robin

On Tue, 2 Feb 2021 at 00:36, Joel Sherrill <joel at rtems.org> wrote:

>
>
> 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
>>
>>
>> _______________________________________________
> 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/20210202/68b9495a/attachment.html>