subject:"Re\: Using LwIP on the STM32H7"

On Mon, Feb 1, 2021 at 5:16 PM Mr. Andrei Chichak  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  wrote:
>
>
>
> On Mon, Feb 1, 2021 at 4:54 PM Mr. Andrei Chichak 
> 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  wrote:
>>
>>
>>
>> On Mon, Feb 1, 2021 at 4:25 PM Andrei Chichak  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  wrote:
>>>
>>>
>>>
>>> On Mon, Feb 1, 2021 at 4:03 PM Gedare Bloom  wrote:
>>>


 On Mon, Feb 1, 2021 at 2:42 PM Chris Johns  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.

Re: Using LwIP on the STM32H7

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

A

> On 2021-February-01, at 16:05, Joel Sherrill  wrote:
> 
> 
> 
> On Mon, Feb 1, 2021 at 4:54 PM Mr. Andrei Chichak  > 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 > > wrote:
>> 
>> 
>> 
>> On Mon, Feb 1, 2021 at 4:25 PM Andrei Chichak > > 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 >> > wrote:
>>> 
>>> 
>>> 
>>> On Mon, Feb 1, 2021 at 4:03 PM Gedare Bloom >> > wrote:
>>> 
>>> 
>>> On Mon, Feb 1, 2021 at 2:42 PM Chris Johns >> > 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@rtems.org 
>>> http://lists.rtems.org/mailman/listinfo/users 
>>>

Re: Using LwIP on the STM32H7

On Mon, Feb 1, 2021 at 4:54 PM Mr. Andrei Chichak  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  wrote:
>
>
>
> On Mon, Feb 1, 2021 at 4:25 PM Andrei Chichak  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  wrote:
>>
>>
>>
>> On Mon, Feb 1, 2021 at 4:03 PM Gedare Bloom  wrote:
>>
>>>
>>>
>>> On Mon, Feb 1, 2021 at 2:42 PM Chris Johns  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@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/users
>>
>> ___
>> users mailing list
>> users@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@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
>
>
>
>

Re: Using LwIP on the STM32H7

Oh, crap, I’m off by 3 orders of magnitude, I’ve got 512KB. 

Bother, I need a nap already.

A

> On 2021-February-01, at 15:35, Joel Sherrill  wrote:
> 
> 
> 
> On Mon, Feb 1, 2021 at 4:25 PM Andrei Chichak  > 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 > > wrote:
>> 
>> 
>> 
>> On Mon, Feb 1, 2021 at 4:03 PM Gedare Bloom > > wrote:
>> 
>> 
>> On Mon, Feb 1, 2021 at 2:42 PM Chris Johns > > 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@rtems.org 
>> http://lists.rtems.org/mailman/listinfo/users 
>> ___
>> users mailing list
>> users@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@rtems.org 
> http://lists.rtems.org/mailman/listinfo/users 
>

Re: Using LwIP on the STM32H7

On Mon, Feb 1, 2021 at 4:25 PM Andrei Chichak  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  wrote:
>
>
>
> On Mon, Feb 1, 2021 at 4:03 PM Gedare Bloom  wrote:
>
>>
>>
>> On Mon, Feb 1, 2021 at 2:42 PM Chris Johns  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@rtems.org
>> http://lists.rtems.org/mailman/listinfo/users
>
> ___
> users mailing list
> users@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@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Using LwIP on the STM32H7

any guidance choosing between “Legacy Stack” and libbsd?

I’ve got a 512MB of RAM processor, so I expect that I’ll have lots left over. 
But that is TBD.

A

> On 2021-February-01, at 15:21, Joel Sherrill  > wrote:
> 
> 
> 
> On Mon, Feb 1, 2021 at 4:03 PM Gedare Bloom  > wrote:
> 
> 
> On Mon, Feb 1, 2021 at 2:42 PM Chris Johns  > 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@rtems.org 
> http://lists.rtems.org/mailman/listinfo/users 
> ___
> users mailing list
> users@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@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Using LwIP on the STM32H7

On Mon, Feb 1, 2021 at 4:03 PM Gedare Bloom  wrote:

>
>
> On Mon, Feb 1, 2021 at 2:42 PM Chris Johns  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@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Using LwIP on the STM32H7

2021-02-01 Thread Gedare Bloom

On Mon, Feb 1, 2021 at 2:42 PM Chris Johns  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

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@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Using LwIP on the STM32H7

2021-02-01 Thread Chris Johns

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.

Chris
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Using LwIP on the STM32H7

Is there any advantage to using bsd networking over LWiP, or vice versa? 

With Robin’s BSP, if it gets released, I think I should be able to finish up my 
bsd networking BSP for STM32F7. I’ll also see what I can do about getting it 
going for F4 as well.

Andrei

> On 2021-January-29, at 12:21, Gedare Bloom  > wrote:
> 
> 
> 
> On Fri, Jan 29, 2021 at 9:57 AM Robin Müller  > wrote:
> The whole code base I'm using might go public soon so I will also send the 
> link here
> as soon as it is. I think this might also be useful for people who would like 
> to evaluate how to set up Eclipse and the CMake build system for 
> their application
> 
> Kind Regards
> Robin
> 
> This will be greatly appreciated, thank you. Glad you got it working, and in 
> relatively short order!
>  
> On Fri, 29 Jan 2021 at 17:47, Robin Müller  > wrote:
> Alright, I figured out the issue, that was an application level problem, the 
> UDP frames are received and sent without issues as far as I can see.
> I think I might submit a patch soon with some of initial improvements. But I 
> will summarize the changes I had to do here for now in case other people want 
> to 
> use lwIP, based on the example application provided by STM.
> 
> BSP Changes:
> 
> Inside bsps/arm/stm32h7/start/bspstart.c:
> 
> I changed the HAL_GetTick() function, which returned 0 previously to return 
> the tick count by default: 
> 
> uint32_t HAL_GetTick(void)
> {
>   return rtems_clock_get_ticks_since_boot();
> }
> 
> I'm not sure whether there was a specific reason to have it return 0 by 
> default, but that led to some issues because this function is generally 
> called by the 
> HAL or by example applications and it's a lot of hassle to replace every call 
> with  rtems_clock_get_ticks_since_boot() 
> 
> bsps/arm/shared/start/linkcmds.base:
> 
> I added following section to the linker file.
> This is a really ugly solution because this file is used by all ARM bsps. I 
> might look into how to make it stm32h7 specific, but it worked for me now 
> because
> I only have the STM32H7
> 
> /* Ugly solution for now */
> .lwip_sec (NOLOAD) : ALIGN_WITH_INPUT {
> . = ABSOLUTE(0x3004);
> *(.RxDecripSection)
> . = ABSOLUTE(0x30040060);
> *(.TxDecripSection)
> . = ABSOLUTE(0x30040200);
>*(.RxArraySection)
> } >SRAM_3 AT> REGION_TEXT_LOAD
> 
> bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c:
> 
> On line 364 in HAL_ETH_Init, comment out the preprocessor guards to set the 
> DSL to 64bit. I don't know what this line exactly does yet, but it was 
> necessary 
> to get lwIP to work properly.
> 
> #ifndef __rtems__
>/* SET DSL to 64 bit */
>MODIFY_REG(heth->Instance->DMACCR, ETH_DMACCR_DSL, ETH_DMACCR_DSL_64BIT);
> #endif /* __rtems__ */
> 
> On line 2648 in ETH_DMATxDescListInit comment the preprocessor guard so that 
> the function is executed. This is necessary
> so the DMA descriptors are set up properly.
> 
> Do the same for ETH_DMARxDescListInit starting at line 2687.
> 
> I think that was all. Hope it helps some people
> 
> Kind Regards
> Robin Müller
> 
> 
> 
> On Fri, 29 Jan 2021 at 15:45, Robin Müller  > wrote:
> I think I might have found one issue. In the HAL_ETH_Init(ETH_HandleTypeDef 
> *heth) function 
> 
> The following piece of code was excluded:
> 
> #ifndef __rtems__
>   /* SET DSL to 64 bit */
>   MODIFY_REG(heth->Instance->DMACCR, ETH_DMACCR_DSL, ETH_DMACCR_DSL_64BIT);
> #endif /* __rtems__ */
> 
> I reintroduced the line and now I have been able to receive UDP frames and 
> send some back. I am still missing some frames, but at least it's working now.
> I might look into how to put the lwIP section in a separate linkcmd file once 
> I have figured out why some frames are missing, but the way I see it, 
> it is driver specific (STM used SDRAM3 for the required lwIP memory. One way 
> would be to add an option in the config.ini like STM32H7_USE_LWIP and then
> load those additional sections for lwIP.
> 
> Kind Regards
> Robin
> 
> On Fri, 29 Jan 2021 at 14:18, Joel Sherrill  > wrote:
> 
> 
> On Fri, Jan 29, 2021, 5:52 AM Robin Müller  > wrote:
> Hi,
> 
> I am actually configuring the MPU with the following function, which was 
> taken over from the STM32 example project:
> 
> /*Configure the MPU attributes */
> void MPU_Config(void)
> {
> MPU_Region_InitTypeDef MPU_InitStruct;
> 
> /* Disable the MPU */
> HAL_MPU_Disable();
> 
> /* Configure the MPU attributes as Device not cacheable
>  for ETH DMA descriptors */
> MPU_InitStruct.Enable = MPU_REGION_ENABLE;
> MPU_InitStruct.BaseAddress = 0x3004;
> MPU_InitStruct.Size = MPU_REGION_SIZE_256B;
> MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
> MPU_InitStruct.IsBufferable = MPU_ACCESS_BUFFERABLE;
>

Re: Using LwIP on the STM32H7

2021-01-29 Thread Gedare Bloom

On Fri, Jan 29, 2021 at 9:57 AM Robin Müller 
wrote:

> The whole code base I'm using might go public soon so I will also send the
> link here
> as soon as it is. I think this might also be useful for people who would
> like to evaluate how to set up Eclipse and the CMake build system for
> their application
>
> Kind Regards
> Robin
>
> This will be greatly appreciated, thank you. Glad you got it working, and
in relatively short order!


> On Fri, 29 Jan 2021 at 17:47, Robin Müller 
> wrote:
>
>> Alright, I figured out the issue, that was an application level problem,
>> the UDP frames are received and sent without issues as far as I can see.
>> I think I might submit a patch soon with some of initial improvements.
>> But I will summarize the changes I had to do here for now in case other
>> people want to
>> use lwIP, based on the example application provided by STM.
>>
>> *BSP Changes:*
>>
>> *Inside bsps/arm/stm32h7/start/bspstart.c:*
>>
>> I changed the HAL_GetTick() function, which returned 0 previously to
>> return the tick count by default:
>>
>> uint32_t HAL_GetTick(void)
>> {
>>   return rtems_clock_get_ticks_since_boot();
>> }
>>
>> I'm not sure whether there was a specific reason to have it return 0 by
>> default, but that led to some issues because this function is generally
>> called by the
>> HAL or by example applications and it's a lot of hassle to replace every
>> call with  rtems_clock_get_ticks_since_boot()
>>
>> *bsps/arm/shared/start/linkcmds.base:*
>>
>> I added following section to the linker file.
>> This is a really ugly solution because this file is used by all ARM bsps.
>> I might look into how to make it stm32h7 specific, but it worked for me now
>> because
>> I only have the STM32H7
>>
>> /* Ugly solution for now */
>> .lwip_sec (NOLOAD) : ALIGN_WITH_INPUT {
>> . = ABSOLUTE(0x3004);
>> *(.RxDecripSection)
>> . = ABSOLUTE(0x30040060);
>> *(.TxDecripSection)
>> . = ABSOLUTE(0x30040200);
>>*(.RxArraySection)
>> } >SRAM_3 AT> REGION_TEXT_LOAD
>>
>>
>>
>> *bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c:*
>> On line 364 in *HAL_ETH_Init*, comment out the preprocessor guards to
>> set the DSL to 64bit. I don't know what this line exactly does yet, but it
>> was necessary
>> to get lwIP to work properly.
>>
>> #ifndef __rtems__
>>/* SET DSL to 64 bit */
>>MODIFY_REG(heth->Instance->DMACCR, ETH_DMACCR_DSL,
>> ETH_DMACCR_DSL_64BIT);
>> #endif /* __rtems__ */
>>
>> On line 2648 in *ETH_DMATxDescListInit *comment the preprocessor guard
>> so that the function is executed. This is necessary
>> so the DMA descriptors are set up properly.
>>
>> Do the same for *ETH_DMARxDescListInit* starting at line 2687.
>>
>> I think that was all. Hope it helps some people
>>
>> Kind Regards
>> Robin Müller
>>
>>
>>
>> On Fri, 29 Jan 2021 at 15:45, Robin Müller 
>> wrote:
>>
>>> I think I might have found one issue. In the
>>> HAL_ETH_Init(ETH_HandleTypeDef *heth) function
>>>
>>> The following piece of code was excluded:
>>>
>>> #ifndef __rtems__
>>>   /* SET DSL to 64 bit */
>>>   MODIFY_REG(heth->Instance->DMACCR, ETH_DMACCR_DSL,
>>> ETH_DMACCR_DSL_64BIT);
>>> #endif /* __rtems__ */
>>>
>>> I reintroduced the line and now I have been able to receive UDP frames
>>> and send some back. I am still missing some frames, but at least it's
>>> working now.
>>> I might look into how to put the lwIP section in a separate linkcmd file
>>> once I have figured out why some frames are missing, but the way I see it,
>>> it is driver specific (STM used SDRAM3 for the required lwIP memory. One
>>> way would be to add an option in the config.ini like STM32H7_USE_LWIP and
>>> then
>>> load those additional sections for lwIP.
>>>
>>> Kind Regards
>>> Robin
>>>
>>> On Fri, 29 Jan 2021 at 14:18, Joel Sherrill  wrote:
>>>


 On Fri, Jan 29, 2021, 5:52 AM Robin Müller 
 wrote:

> Hi,
>
> I am actually configuring the MPU with the following function, which
> was taken over from the STM32 example project:
>
> /*Configure the MPU attributes */
> void MPU_Config(void)
> {
> MPU_Region_InitTypeDef MPU_InitStruct;
>
> /* Disable the MPU */
> HAL_MPU_Disable();
>
> /* Configure the MPU attributes as Device not cacheable
>  for ETH DMA descriptors */
> MPU_InitStruct.Enable = MPU_REGION_ENABLE;
> MPU_InitStruct.BaseAddress = 0x3004;
> MPU_InitStruct.Size = MPU_REGION_SIZE_256B;
> MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
> MPU_InitStruct.IsBufferable = MPU_ACCESS_BUFFERABLE;
> MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;
> MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE;
> MPU_InitStruct.Number = MPU_REGION_NUMBER0;
> MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;
> MPU_InitStruct.SubRegionDisable = 0x00;
> MPU_InitStruct.DisableExec =

Re: Using LwIP on the STM32H7

The whole code base I'm using might go public soon so I will also send the
link here
as soon as it is. I think this might also be useful for people who would
like to evaluate how to set up Eclipse and the CMake build system for
their application

Kind Regards
Robin

On Fri, 29 Jan 2021 at 17:47, Robin Müller 
wrote:

> Alright, I figured out the issue, that was an application level problem,
> the UDP frames are received and sent without issues as far as I can see.
> I think I might submit a patch soon with some of initial improvements. But
> I will summarize the changes I had to do here for now in case other people
> want to
> use lwIP, based on the example application provided by STM.
>
> *BSP Changes:*
>
> *Inside bsps/arm/stm32h7/start/bspstart.c:*
>
> I changed the HAL_GetTick() function, which returned 0 previously to
> return the tick count by default:
>
> uint32_t HAL_GetTick(void)
> {
>   return rtems_clock_get_ticks_since_boot();
> }
>
> I'm not sure whether there was a specific reason to have it return 0 by
> default, but that led to some issues because this function is generally
> called by the
> HAL or by example applications and it's a lot of hassle to replace every
> call with  rtems_clock_get_ticks_since_boot()
>
> *bsps/arm/shared/start/linkcmds.base:*
>
> I added following section to the linker file.
> This is a really ugly solution because this file is used by all ARM bsps.
> I might look into how to make it stm32h7 specific, but it worked for me now
> because
> I only have the STM32H7
>
> /* Ugly solution for now */
> .lwip_sec (NOLOAD) : ALIGN_WITH_INPUT {
> . = ABSOLUTE(0x3004);
> *(.RxDecripSection)
> . = ABSOLUTE(0x30040060);
> *(.TxDecripSection)
> . = ABSOLUTE(0x30040200);
>*(.RxArraySection)
> } >SRAM_3 AT> REGION_TEXT_LOAD
>
>
>
> *bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c:*
> On line 364 in *HAL_ETH_Init*, comment out the preprocessor guards to set
> the DSL to 64bit. I don't know what this line exactly does yet, but it was
> necessary
> to get lwIP to work properly.
>
> #ifndef __rtems__
>/* SET DSL to 64 bit */
>MODIFY_REG(heth->Instance->DMACCR, ETH_DMACCR_DSL,
> ETH_DMACCR_DSL_64BIT);
> #endif /* __rtems__ */
>
> On line 2648 in *ETH_DMATxDescListInit *comment the preprocessor guard so
> that the function is executed. This is necessary
> so the DMA descriptors are set up properly.
>
> Do the same for *ETH_DMARxDescListInit* starting at line 2687.
>
> I think that was all. Hope it helps some people
>
> Kind Regards
> Robin Müller
>
>
>
> On Fri, 29 Jan 2021 at 15:45, Robin Müller 
> wrote:
>
>> I think I might have found one issue. In the
>> HAL_ETH_Init(ETH_HandleTypeDef *heth) function
>>
>> The following piece of code was excluded:
>>
>> #ifndef __rtems__
>>   /* SET DSL to 64 bit */
>>   MODIFY_REG(heth->Instance->DMACCR, ETH_DMACCR_DSL,
>> ETH_DMACCR_DSL_64BIT);
>> #endif /* __rtems__ */
>>
>> I reintroduced the line and now I have been able to receive UDP frames
>> and send some back. I am still missing some frames, but at least it's
>> working now.
>> I might look into how to put the lwIP section in a separate linkcmd file
>> once I have figured out why some frames are missing, but the way I see it,
>> it is driver specific (STM used SDRAM3 for the required lwIP memory. One
>> way would be to add an option in the config.ini like STM32H7_USE_LWIP and
>> then
>> load those additional sections for lwIP.
>>
>> Kind Regards
>> Robin
>>
>> On Fri, 29 Jan 2021 at 14:18, Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Fri, Jan 29, 2021, 5:52 AM Robin Müller 
>>> wrote:
>>>
 Hi,

 I am actually configuring the MPU with the following function, which
 was taken over from the STM32 example project:

 /*Configure the MPU attributes */
 void MPU_Config(void)
 {
 MPU_Region_InitTypeDef MPU_InitStruct;

 /* Disable the MPU */
 HAL_MPU_Disable();

 /* Configure the MPU attributes as Device not cacheable
  for ETH DMA descriptors */
 MPU_InitStruct.Enable = MPU_REGION_ENABLE;
 MPU_InitStruct.BaseAddress = 0x3004;
 MPU_InitStruct.Size = MPU_REGION_SIZE_256B;
 MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
 MPU_InitStruct.IsBufferable = MPU_ACCESS_BUFFERABLE;
 MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;
 MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE;
 MPU_InitStruct.Number = MPU_REGION_NUMBER0;
 MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;
 MPU_InitStruct.SubRegionDisable = 0x00;
 MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE;

 HAL_MPU_ConfigRegion(_InitStruct);

 /* Configure the MPU attributes as Cacheable write through
  for LwIP RAM heap which contains the Tx buffers */
 MPU_InitStruct.Enable = MPU_REGION_ENABLE;
 MPU_InitStruct.BaseAddress = 0x30044000;

Re: Using LwIP on the STM32H7

Alright, I figured out the issue, that was an application level problem,
the UDP frames are received and sent without issues as far as I can see.
I think I might submit a patch soon with some of initial improvements. But
I will summarize the changes I had to do here for now in case other people
want to
use lwIP, based on the example application provided by STM.

*BSP Changes:*

*Inside bsps/arm/stm32h7/start/bspstart.c:*

I changed the HAL_GetTick() function, which returned 0 previously to return
the tick count by default:

uint32_t HAL_GetTick(void)
{
  return rtems_clock_get_ticks_since_boot();
}

I'm not sure whether there was a specific reason to have it return 0 by
default, but that led to some issues because this function is generally
called by the
HAL or by example applications and it's a lot of hassle to replace every
call with  rtems_clock_get_ticks_since_boot()

*bsps/arm/shared/start/linkcmds.base:*

I added following section to the linker file.
This is a really ugly solution because this file is used by all ARM bsps. I
might look into how to make it stm32h7 specific, but it worked for me now
because
I only have the STM32H7

/* Ugly solution for now */
.lwip_sec (NOLOAD) : ALIGN_WITH_INPUT {
. = ABSOLUTE(0x3004);
*(.RxDecripSection)
. = ABSOLUTE(0x30040060);
*(.TxDecripSection)
. = ABSOLUTE(0x30040200);
   *(.RxArraySection)
} >SRAM_3 AT> REGION_TEXT_LOAD



*bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c:*
On line 364 in *HAL_ETH_Init*, comment out the preprocessor guards to set
the DSL to 64bit. I don't know what this line exactly does yet, but it was
necessary
to get lwIP to work properly.

#ifndef __rtems__
   /* SET DSL to 64 bit */
   MODIFY_REG(heth->Instance->DMACCR, ETH_DMACCR_DSL, ETH_DMACCR_DSL_64BIT);
#endif /* __rtems__ */

On line 2648 in *ETH_DMATxDescListInit *comment the preprocessor guard so
that the function is executed. This is necessary
so the DMA descriptors are set up properly.

Do the same for *ETH_DMARxDescListInit* starting at line 2687.

I think that was all. Hope it helps some people

Kind Regards
Robin Müller



On Fri, 29 Jan 2021 at 15:45, Robin Müller 
wrote:

> I think I might have found one issue. In the
> HAL_ETH_Init(ETH_HandleTypeDef *heth) function
>
> The following piece of code was excluded:
>
> #ifndef __rtems__
>   /* SET DSL to 64 bit */
>   MODIFY_REG(heth->Instance->DMACCR, ETH_DMACCR_DSL, ETH_DMACCR_DSL_64BIT);
> #endif /* __rtems__ */
>
> I reintroduced the line and now I have been able to receive UDP frames and
> send some back. I am still missing some frames, but at least it's working
> now.
> I might look into how to put the lwIP section in a separate linkcmd file
> once I have figured out why some frames are missing, but the way I see it,
> it is driver specific (STM used SDRAM3 for the required lwIP memory. One
> way would be to add an option in the config.ini like STM32H7_USE_LWIP and
> then
> load those additional sections for lwIP.
>
> Kind Regards
> Robin
>
> On Fri, 29 Jan 2021 at 14:18, Joel Sherrill  wrote:
>
>>
>>
>> On Fri, Jan 29, 2021, 5:52 AM Robin Müller 
>> wrote:
>>
>>> Hi,
>>>
>>> I am actually configuring the MPU with the following function, which was
>>> taken over from the STM32 example project:
>>>
>>> /*Configure the MPU attributes */
>>> void MPU_Config(void)
>>> {
>>> MPU_Region_InitTypeDef MPU_InitStruct;
>>>
>>> /* Disable the MPU */
>>> HAL_MPU_Disable();
>>>
>>> /* Configure the MPU attributes as Device not cacheable
>>>  for ETH DMA descriptors */
>>> MPU_InitStruct.Enable = MPU_REGION_ENABLE;
>>> MPU_InitStruct.BaseAddress = 0x3004;
>>> MPU_InitStruct.Size = MPU_REGION_SIZE_256B;
>>> MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
>>> MPU_InitStruct.IsBufferable = MPU_ACCESS_BUFFERABLE;
>>> MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;
>>> MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE;
>>> MPU_InitStruct.Number = MPU_REGION_NUMBER0;
>>> MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;
>>> MPU_InitStruct.SubRegionDisable = 0x00;
>>> MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE;
>>>
>>> HAL_MPU_ConfigRegion(_InitStruct);
>>>
>>> /* Configure the MPU attributes as Cacheable write through
>>>  for LwIP RAM heap which contains the Tx buffers */
>>> MPU_InitStruct.Enable = MPU_REGION_ENABLE;
>>> MPU_InitStruct.BaseAddress = 0x30044000;
>>> MPU_InitStruct.Size = MPU_REGION_SIZE_16KB;
>>> MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
>>> MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;
>>> MPU_InitStruct.IsCacheable = MPU_ACCESS_CACHEABLE;
>>> MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE;
>>> MPU_InitStruct.Number = MPU_REGION_NUMBER1;
>>> MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;
>>> MPU_InitStruct.SubRegionDisable = 0x00;
>>> MPU_InitStruct.DisableExec =

Re: Using LwIP on the STM32H7

I think I might have found one issue. In the HAL_ETH_Init(ETH_HandleTypeDef
*heth) function

The following piece of code was excluded:

#ifndef __rtems__
  /* SET DSL to 64 bit */
  MODIFY_REG(heth->Instance->DMACCR, ETH_DMACCR_DSL, ETH_DMACCR_DSL_64BIT);
#endif /* __rtems__ */

I reintroduced the line and now I have been able to receive UDP frames and
send some back. I am still missing some frames, but at least it's working
now.
I might look into how to put the lwIP section in a separate linkcmd file
once I have figured out why some frames are missing, but the way I see it,
it is driver specific (STM used SDRAM3 for the required lwIP memory. One
way would be to add an option in the config.ini like STM32H7_USE_LWIP and
then
load those additional sections for lwIP.

Kind Regards
Robin

On Fri, 29 Jan 2021 at 14:18, Joel Sherrill  wrote:

>
>
> On Fri, Jan 29, 2021, 5:52 AM Robin Müller 
> wrote:
>
>> Hi,
>>
>> I am actually configuring the MPU with the following function, which was
>> taken over from the STM32 example project:
>>
>> /*Configure the MPU attributes */
>> void MPU_Config(void)
>> {
>> MPU_Region_InitTypeDef MPU_InitStruct;
>>
>> /* Disable the MPU */
>> HAL_MPU_Disable();
>>
>> /* Configure the MPU attributes as Device not cacheable
>>  for ETH DMA descriptors */
>> MPU_InitStruct.Enable = MPU_REGION_ENABLE;
>> MPU_InitStruct.BaseAddress = 0x3004;
>> MPU_InitStruct.Size = MPU_REGION_SIZE_256B;
>> MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
>> MPU_InitStruct.IsBufferable = MPU_ACCESS_BUFFERABLE;
>> MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;
>> MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE;
>> MPU_InitStruct.Number = MPU_REGION_NUMBER0;
>> MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;
>> MPU_InitStruct.SubRegionDisable = 0x00;
>> MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE;
>>
>> HAL_MPU_ConfigRegion(_InitStruct);
>>
>> /* Configure the MPU attributes as Cacheable write through
>>  for LwIP RAM heap which contains the Tx buffers */
>> MPU_InitStruct.Enable = MPU_REGION_ENABLE;
>> MPU_InitStruct.BaseAddress = 0x30044000;
>> MPU_InitStruct.Size = MPU_REGION_SIZE_16KB;
>> MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
>> MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;
>> MPU_InitStruct.IsCacheable = MPU_ACCESS_CACHEABLE;
>> MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE;
>> MPU_InitStruct.Number = MPU_REGION_NUMBER1;
>> MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;
>> MPU_InitStruct.SubRegionDisable = 0x00;
>> MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE;
>>
>> HAL_MPU_ConfigRegion(_InitStruct);
>>
>> /* Enable the MPU */
>> HAL_MPU_Enable(MPU_PRIVILEGED_DEFAULT);
>> }
>>
>> If I read the function correctly, it configures the descriptor areas as
>> non-cacheable and the LwIP heap region
>> as non bufferable. I call this in hardware_init, which is the first
>> function called in my Init funnction
>>
>> void hardware_init() {
>> BSP_LED_Init(LED1);
>> BSP_LED_Init(LED2);
>> BSP_LED_Init(LED3);
>>
>> MPU_Config();
>>
>> /* Initialize the LwIP stack */
>> lwip_init();
>>
>> /* Configure the Network interface */
>> Netif_Config();
>>
>> }
>>
>> I checked everything again and basically the setup appears to be
>> identical to the example now.. I'm confused that it's not working.
>> I also supplied the following interrupt function in my C code:
>>
>> /**
>>   * @brief  This function handles Ethernet interrupt request.
>>   * @param  None
>>   * @retval None
>>   */
>> void ETH_IRQHandler(void)
>> {
>>   HAL_ETH_IRQHandler();
>> }
>>
>> But it appears not to be called..
>>
>
> Is the irq being registered via the RTEMS interrupt APIs? If not and you
> are getting an interrupt, I'd wonder why you aren't seeing a spurious
> interrupt flagged.
>
> It shouldn't be installed directly at the hardware level.
>
> --joel
>
>
>> Kind Regards
>> Robin
>>
>> On Fri, 29 Jan 2021 at 12:03, Sebastian Huber <
>> sebastian.hu...@embedded-brains.de> wrote:
>>
>>> On 29/01/2021 12:01, Robin Müller wrote:
>>>
>>> > The HAL_ETH_Transmit call just times out. If I set the timeout to 20
>>> > to HAL_MAX_DELAY, the function will just block indefinitely.
>>> > Does anyone have an idea why this might happen?
>>> I would check the memory settings in the MPU for this area. You probably
>>> need some sort of device memory (uncached).
>>>
>>> --
>>> embedded brains GmbH
>>> Herr Sebastian HUBER
>>> Dornierstr. 4
>>> 82178 Puchheim
>>> Germany
>>> email: sebastian.hu...@embedded-brains.de
>>> phone: +49-89-18 94 741 - 16
>>> fax:   +49-89-18 94 741 - 08
>>>
>>> Registergericht: Amtsgericht München
>>> Registernummer: HRB 157899
>>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>>> Unsere Datenschutzerklärung finden Sie hier:
>>>

Re: Using LwIP on the STM32H7

2021-01-29 Thread Joel Sherrill

On Fri, Jan 29, 2021, 5:52 AM Robin Müller 
wrote:

> Hi,
>
> I am actually configuring the MPU with the following function, which was
> taken over from the STM32 example project:
>
> /*Configure the MPU attributes */
> void MPU_Config(void)
> {
> MPU_Region_InitTypeDef MPU_InitStruct;
>
> /* Disable the MPU */
> HAL_MPU_Disable();
>
> /* Configure the MPU attributes as Device not cacheable
>  for ETH DMA descriptors */
> MPU_InitStruct.Enable = MPU_REGION_ENABLE;
> MPU_InitStruct.BaseAddress = 0x3004;
> MPU_InitStruct.Size = MPU_REGION_SIZE_256B;
> MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
> MPU_InitStruct.IsBufferable = MPU_ACCESS_BUFFERABLE;
> MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;
> MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE;
> MPU_InitStruct.Number = MPU_REGION_NUMBER0;
> MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;
> MPU_InitStruct.SubRegionDisable = 0x00;
> MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE;
>
> HAL_MPU_ConfigRegion(_InitStruct);
>
> /* Configure the MPU attributes as Cacheable write through
>  for LwIP RAM heap which contains the Tx buffers */
> MPU_InitStruct.Enable = MPU_REGION_ENABLE;
> MPU_InitStruct.BaseAddress = 0x30044000;
> MPU_InitStruct.Size = MPU_REGION_SIZE_16KB;
> MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
> MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;
> MPU_InitStruct.IsCacheable = MPU_ACCESS_CACHEABLE;
> MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE;
> MPU_InitStruct.Number = MPU_REGION_NUMBER1;
> MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;
> MPU_InitStruct.SubRegionDisable = 0x00;
> MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE;
>
> HAL_MPU_ConfigRegion(_InitStruct);
>
> /* Enable the MPU */
> HAL_MPU_Enable(MPU_PRIVILEGED_DEFAULT);
> }
>
> If I read the function correctly, it configures the descriptor areas as
> non-cacheable and the LwIP heap region
> as non bufferable. I call this in hardware_init, which is the first
> function called in my Init funnction
>
> void hardware_init() {
> BSP_LED_Init(LED1);
> BSP_LED_Init(LED2);
> BSP_LED_Init(LED3);
>
> MPU_Config();
>
> /* Initialize the LwIP stack */
> lwip_init();
>
> /* Configure the Network interface */
> Netif_Config();
>
> }
>
> I checked everything again and basically the setup appears to be identical
> to the example now.. I'm confused that it's not working.
> I also supplied the following interrupt function in my C code:
>
> /**
>   * @brief  This function handles Ethernet interrupt request.
>   * @param  None
>   * @retval None
>   */
> void ETH_IRQHandler(void)
> {
>   HAL_ETH_IRQHandler();
> }
>
> But it appears not to be called..
>

Is the irq being registered via the RTEMS interrupt APIs? If not and you
are getting an interrupt, I'd wonder why you aren't seeing a spurious
interrupt flagged.

It shouldn't be installed directly at the hardware level.

--joel


> Kind Regards
> Robin
>
> On Fri, 29 Jan 2021 at 12:03, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 29/01/2021 12:01, Robin Müller wrote:
>>
>> > The HAL_ETH_Transmit call just times out. If I set the timeout to 20
>> > to HAL_MAX_DELAY, the function will just block indefinitely.
>> > Does anyone have an idea why this might happen?
>> I would check the memory settings in the MPU for this area. You probably
>> need some sort of device memory (uncached).
>>
>> --
>> embedded brains GmbH
>> Herr Sebastian HUBER
>> Dornierstr. 4
>> 82178 Puchheim
>> Germany
>> email: sebastian.hu...@embedded-brains.de
>> phone: +49-89-18 94 741 - 16
>> fax:   +49-89-18 94 741 - 08
>>
>> Registergericht: Amtsgericht München
>> Registernummer: HRB 157899
>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>> Unsere Datenschutzerklärung finden Sie hier:
>> https://embedded-brains.de/datenschutzerklaerung/
>>
>> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Using LwIP on the STM32H7

Hi,

I am actually configuring the MPU with the following function, which was
taken over from the STM32 example project:

/*Configure the MPU attributes */
void MPU_Config(void)
{
MPU_Region_InitTypeDef MPU_InitStruct;

/* Disable the MPU */
HAL_MPU_Disable();

/* Configure the MPU attributes as Device not cacheable
 for ETH DMA descriptors */
MPU_InitStruct.Enable = MPU_REGION_ENABLE;
MPU_InitStruct.BaseAddress = 0x3004;
MPU_InitStruct.Size = MPU_REGION_SIZE_256B;
MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
MPU_InitStruct.IsBufferable = MPU_ACCESS_BUFFERABLE;
MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;
MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE;
MPU_InitStruct.Number = MPU_REGION_NUMBER0;
MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;
MPU_InitStruct.SubRegionDisable = 0x00;
MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE;

HAL_MPU_ConfigRegion(_InitStruct);

/* Configure the MPU attributes as Cacheable write through
 for LwIP RAM heap which contains the Tx buffers */
MPU_InitStruct.Enable = MPU_REGION_ENABLE;
MPU_InitStruct.BaseAddress = 0x30044000;
MPU_InitStruct.Size = MPU_REGION_SIZE_16KB;
MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;
MPU_InitStruct.IsCacheable = MPU_ACCESS_CACHEABLE;
MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE;
MPU_InitStruct.Number = MPU_REGION_NUMBER1;
MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;
MPU_InitStruct.SubRegionDisable = 0x00;
MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE;

HAL_MPU_ConfigRegion(_InitStruct);

/* Enable the MPU */
HAL_MPU_Enable(MPU_PRIVILEGED_DEFAULT);
}

If I read the function correctly, it configures the descriptor areas as
non-cacheable and the LwIP heap region
as non bufferable. I call this in hardware_init, which is the first
function called in my Init funnction

void hardware_init() {
BSP_LED_Init(LED1);
BSP_LED_Init(LED2);
BSP_LED_Init(LED3);

MPU_Config();

/* Initialize the LwIP stack */
lwip_init();

/* Configure the Network interface */
Netif_Config();

}

I checked everything again and basically the setup appears to be identical
to the example now.. I'm confused that it's not working.
I also supplied the following interrupt function in my C code:

/**
  * @brief  This function handles Ethernet interrupt request.
  * @param  None
  * @retval None
  */
void ETH_IRQHandler(void)
{
  HAL_ETH_IRQHandler();
}

But it appears not to be called..

Kind Regards
Robin

On Fri, 29 Jan 2021 at 12:03, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 29/01/2021 12:01, Robin Müller wrote:
>
> > The HAL_ETH_Transmit call just times out. If I set the timeout to 20
> > to HAL_MAX_DELAY, the function will just block indefinitely.
> > Does anyone have an idea why this might happen?
> I would check the memory settings in the MPU for this area. You probably
> need some sort of device memory (uncached).
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Using LwIP on the STM32H7

2021-01-29 Thread Sebastian Huber


On 29/01/2021 12:01, Robin Müller wrote:

The HAL_ETH_Transmit call just times out. If I set the timeout to 20 
to HAL_MAX_DELAY, the function will just block indefinitely.

Does anyone have an idea why this might happen?
I would check the memory settings in the MPU for this area. You probably 
need some sort of device memory (uncached).


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Using LwIP on the STM32H7

It probably adds the lwIP sources and builds them.

Right now I am trying to solve an issue with the DMA (hopefully the last
issue), because the following function used by lwIP is not working:

static err_t low_level_output(struct netif *netif, struct pbuf *p)
{
  uint32_t i=0, framelen = 0;
  struct pbuf *q;
  err_t errval = ERR_OK;
  ETH_BufferTypeDef Txbuffer[ETH_TX_DESC_CNT];

  for(q = p; q != NULL; q = q->next)
  {
if(i >= ETH_TX_DESC_CNT)
  return ERR_IF;

Txbuffer[i].buffer = q->payload;
Txbuffer[i].len = q->len;
framelen += q->len;

if(i>0)
{
  Txbuffer[i-1].next = [i];
}

if(q->next == NULL)
{
  Txbuffer[i].next = NULL;
}

i++;
  }

  TxConfig.Length = framelen;
  TxConfig.TxBuffer = Txbuffer;

  HAL_StatusTypeDef ret = HAL_ETH_Transmit(, , 20);

  if(ret != HAL_OK) {
 printf("low_level_output: Could not transmit ethernet packet, code
%d!\n\r", ret);
  }

  return errval;
}

The HAL_ETH_Transmit call just times out. If I set the timeout to 20 to
HAL_MAX_DELAY, the function will just block indefinitely.
Does anyone have an idea why this might happen?
Now I have also found  this
https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices
which also
explains some details about the STM32 DMA..

Kind Regards
Robin

On Fri, 29 Jan 2021 at 01:25, Chris Johns  wrote:

> On 29/1/21 12:35 am, Robin Müller wrote:
> > Are there any other thinks I need to take into account for making LwIP
> > work with RTEMS?
>
> I have not used LwIP but there is an RSB package ...
>
>
> https://git.rtems.org/rtems-source-builder/tree/rtems/config/net/lwip-1-1.cfg
>
> It has a patch. I have no idea about the state of the patch or what it
> does.
>
> Any updates to LwIP would be welcomed back into the project.
>
> Thanks
> Chris
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Using LwIP on the STM32H7

2021-01-28 Thread Chris Johns

On 29/1/21 12:35 am, Robin Müller wrote:
> Are there any other thinks I need to take into account for making LwIP
> work with RTEMS?

I have not used LwIP but there is an RSB package ...

https://git.rtems.org/rtems-source-builder/tree/rtems/config/net/lwip-1-1.cfg

It has a patch. I have no idea about the state of the patch or what it does.

Any updates to LwIP would be welcomed back into the project.

Thanks
Chris
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Using LwIP on the STM32H7

Thanks for the clarifications. Now I actually understand what the
MPU_Config call from the STM32 example does. I was not sure what that was
for. I reintroduced the lwip sections (from my first mail9
again with the values from the STM32 linker script and used the MPU_Config
call from the STM32 example.
It is now not crashing anymore. I still can't receive UDP packets, but at
least I am now able to run my polling loop.

Kind Regards
Robin Müller



On Thu, 28 Jan 2021 at 18:33, Mr. Andrei Chichak  wrote:

> Good morning,
>
> I’ve been trying to get ethernet on STM32F7 going using the bsd networking
> stack (not going that well, there is a LOT of undocumented knowledge to
> straighten out).
>
>
> The STM32x7 ethernet controllers need their descriptors and data areas to
> be located on 32-byte boundaries with a combination of cache being turned
> off and buffering being turned off. This is a side effect of the STM32x7
> DMA and data caching.
>
> The examples that ST have for LWiP under FreeRTOS have some issues with
> the linker file having overlapping sections and the stack (above the ETH
> data areas) being left with no cache and no buffering. The space above the
> rx/tx buffers is also less than the stack space minimum specified in the
> linker file as well.  Some rearranging of the ETH descriptors and data
> areas would be prudent. Like push them to the top of SRAM and locate the
> stack below.
>
> To get this all going, they set up the MPU for two overlapping sections,
> one being the top 16kB of SRAM and the other the 256B that contain the ETH
> descriptors. I believe the MPU regions can be set in increments of 32Bytes,
> so setting up the cache and buffering should be do-able without affecting
> the stack.
>
>
>
> In RTEMS it appears that I have to pull the data and lengths out of some
> mbufs (I had to look that up), and push it all into the data areas. Using
> LWiP, I think you do similar things, just pulling the data out of the pbuf
> chains.
>
> On the STM forums is an item about how to actually get a working ETH going
> on ST processors. There’s all sorts of issues including Cube generating
> code for ST’s dev boards that has the incorrect address for the PHY chip.
> Take a look at:
> https://community.st.com/s/question/0D50XBOtfhnSQB/how-to-make-ethernet-and-lwip-working-on-stm32
>
> More later,
>
> Andrei
>
>
>
> -
> Andrei Chichak
>
> Systems Developer
> CBF Systems Inc.
> 225 College Plaza
> 8215 112 Street.
> EDMONTON, ALBERTA
> T6G 2C8
> CANADA
>
> Phone: 780-628-2072
> Skype: andrei.chichak
>
>
>
>
>
>
>
>
>
>
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Using LwIP on the STM32H7

2021-01-28 Thread Mr. Andrei Chichak

Good morning,

I’ve been trying to get ethernet on STM32F7 going using the bsd networking
stack (not going that well, there is a LOT of undocumented knowledge to
straighten out).

The STM32x7 ethernet controllers need their descriptors and data areas to be
located on 32-byte boundaries with a combination of cache being turned off and
buffering being turned off. This is a side effect of the STM32x7 DMA and data
caching.

The examples that ST have for LWiP under FreeRTOS have some issues with the
linker file having overlapping sections and the stack (above the ETH data
areas) being left with no cache and no buffering. The space above the rx/tx
buffers is also less than the stack space minimum specified in the linker file
as well. Some rearranging of the ETH descriptors and data areas would be
prudent. Like push them to the top of SRAM and locate the stack below.

To get this all going, they set up the MPU for two overlapping sections, one
being the top 16kB of SRAM and the other the 256B that contain the ETH
descriptors. I believe the MPU regions can be set in increments of 32Bytes, so
setting up the cache and buffering should be do-able without affecting the
stack.

In RTEMS it appears that I have to pull the data and lengths out of some mbufs
(I had to look that up), and push it all into the data areas. Using LWiP, I
think you do similar things, just pulling the data out of the pbuf chains.

On the STM forums is an item about how to actually get a working ETH going on
ST processors. There’s all sorts of issues including Cube generating code for
ST’s dev boards that has the incorrect address for the PHY chip.
Take a look at:
https://community.st.com/s/question/0D50XBOtfhnSQB/how-to-make-ethernet-and-lwip-working-on-stm32

More later,

Andrei

-
Andrei Chichak

Systems Developer
CBF Systems Inc.
225 College Plaza
8215 112 Street.
EDMONTON, ALBERTA
T6G 2C8
CANADA

Phone: 780-628-2072
Skype: andrei.chichak

___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Using LwIP on the STM32H7

2021-01-28 Thread Joel Sherrill

On Thu, Jan 28, 2021 at 10:52 AM Robin Müller 
wrote:

> By the way, the lwipopts.h from the STM32 example application appears to
> use the SRAM3 as the LWIP heap memory as well:
>
> /* Relocate the LwIP RAM heap pointer */
> #define LWIP_RAM_HEAP_POINTER(0x30044000)
>
> Might this be an issue?
>

Does that address conflict with memory RTEMS is using for stacks, heap or
workspace?
If so, this is going to crash in an odd an unpredictable way.

Can LWIP work with malloc() optionally? Or can you malloc() (aligned?) the
memory before initializing LWIP and turn that RAM_HEAP_POINTER into a
void * variable access? I doubt it is referenced much.


> I'm also not sure whether any interrupts are configured .. but I think the
> Raw API is polling based..
>
> Kind Regards
> Robin Müller
>
> On Thu, 28 Jan 2021 at 17:40, Robin Müller 
> wrote:
>
>> Okay, I managed to achieve the initialization process by adapting the BSP
>> to perform the descriptor list initialization.
>> Unfortunately, the program now appears to crash in the following polling
>> function, which is called every 100 ms:
>>
>> void ethernetif_input(struct netif *netif)
>> {
>>   err_t err;
>>   struct pbuf *p;
>>
>>   /* move received packet into a new pbuf */
>>   p = low_level_input(netif);
>>
>>   /* no packet could be read, silently ignore this */
>>   if (p == NULL) return;
>>
>>   /* entry point to the LwIP stack */
>>   err = netif->input(p, netif);
>>
>>   if (err != ERR_OK)
>>   {
>> LWIP_DEBUGF(NETIF_DEBUG, ("ethernetif_input: IP input error\n"));
>> pbuf_free(p);
>> p = NULL;
>>   }
>>
>>   HAL_ETH_BuildRxDescriptors();
>> }
>>
>> More specifically, it appears to crash in netif->input.. Is there someone
>> who has managed to make LwIP work on the STM32 with the Raw API?
>>
>> Kind Regards
>> Robin Müller
>>
>> On Thu, 28 Jan 2021 at 17:15, Robin Müller 
>> wrote:
>>
>>> Alright, I think these descriptors were not initialized inside the
>>> functions:
>>> ETH_DMATxDescListInit
>>> ETH_DMARxDescListInit
>>>
>>> because they are wrapped in preprocessor guards:
>>>
>>> static void ETH_DMATxDescListInit(ETH_HandleTypeDef *heth)
>>> {
>>> #ifndef __rtems__
>>>   ETH_DMADescTypeDef *dmatxdesc;
>>>   uint32_t i;
>>>
>>>   /* Fill each DMATxDesc descriptor with the right values */
>>>   for(i=0; i < (uint32_t)ETH_TX_DESC_CNT; i++)
>>>   {
>>> dmatxdesc = heth->Init.TxDesc + i;
>>>
>>> WRITE_REG(dmatxdesc->DESC0, 0x0);
>>> WRITE_REG(dmatxdesc->DESC1, 0x0);
>>> WRITE_REG(dmatxdesc->DESC2, 0x0);
>>> WRITE_REG(dmatxdesc->DESC3, 0x0);
>>>
>>> WRITE_REG(heth->TxDescList.TxDesc[i], (uint32_t)dmatxdesc);
>>>   }
>>>
>>>   heth->TxDescList.CurTxDesc = 0;
>>>
>>>   /* Set Transmit Descriptor Ring Length */
>>>   WRITE_REG(heth->Instance->DMACTDRLR, (ETH_TX_DESC_CNT -1));
>>>
>>>   /* Set Transmit Descriptor List Address */
>>>   WRITE_REG(heth->Instance->DMACTDLAR, (uint32_t) heth->Init.TxDesc);
>>>
>>>   /* Set Transmit Descriptor Tail pointer */
>>>   WRITE_REG(heth->Instance->DMACTDTPR, (uint32_t) heth->Init.TxDesc);
>>> #endif /* __rtems__ */
>>> }
>>>
>>> Is there a specific reason the function was excluded?
>>>
>>> Kind Regards
>>> Robin
>>>
>>> On Thu, 28 Jan 2021 at 16:47, Sebastian Huber <
>>> sebastian.hu...@embedded-brains.de> wrote:
>>>
 On 28/01/2021 16:45, Robin Müller wrote:

 >  *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.bsp_nocache*)))
 >  .bsp_nocache   0x3000 0x18c0
 >
 CMakeFiles/fsfw_example.dir/bsp_stm32_rtems/boardconfig/ethernetif.c.obj
 > 0x3000DMARxDscrTab
 > 0x3060DMATxDscrTab
 > 0x30c0Rx_Buff
 > 0x300018c0  bsp_section_nocache_end = .
 > 0x18c0  bsp_section_nocache_size =
 > (bsp_section_nocache_end - bsp_section_nocache_begin)
 >
 > But in the debugger, the descriptor entries are still zeroed out
 > unfortunately..
 If you place them in BSP_NOCACHENOLOAD_SECTION or
 BSP_NOCACHENOLOAD_SUBSECTION(), they are not loaded (zero initialized).

 --
 embedded brains GmbH
 Herr Sebastian HUBER
 Dornierstr. 4
 82178 Puchheim
 Germany
 email: sebastian.hu...@embedded-brains.de
 phone: +49-89-18 94 741 - 16
 fax:   +49-89-18 94 741 - 08

 Registergericht: Amtsgericht München
 Registernummer: HRB 157899
 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
 Unsere Datenschutzerklärung finden Sie hier:
 https://embedded-brains.de/datenschutzerklaerung/

 ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Using LwIP on the STM32H7

By the way, the lwipopts.h from the STM32 example application appears to
use the SRAM3 as the LWIP heap memory as well:

/* Relocate the LwIP RAM heap pointer */
#define LWIP_RAM_HEAP_POINTER(0x30044000)

Might this be an issue? I'm also not sure whether any interrupts are
configured .. but I think the Raw API is polling based..

Kind Regards
Robin Müller

On Thu, 28 Jan 2021 at 17:40, Robin Müller 
wrote:

> Okay, I managed to achieve the initialization process by adapting the BSP
> to perform the descriptor list initialization.
> Unfortunately, the program now appears to crash in the following polling
> function, which is called every 100 ms:
>
> void ethernetif_input(struct netif *netif)
> {
>   err_t err;
>   struct pbuf *p;
>
>   /* move received packet into a new pbuf */
>   p = low_level_input(netif);
>
>   /* no packet could be read, silently ignore this */
>   if (p == NULL) return;
>
>   /* entry point to the LwIP stack */
>   err = netif->input(p, netif);
>
>   if (err != ERR_OK)
>   {
> LWIP_DEBUGF(NETIF_DEBUG, ("ethernetif_input: IP input error\n"));
> pbuf_free(p);
> p = NULL;
>   }
>
>   HAL_ETH_BuildRxDescriptors();
> }
>
> More specifically, it appears to crash in netif->input.. Is there someone
> who has managed to make LwIP work on the STM32 with the Raw API?
>
> Kind Regards
> Robin Müller
>
> On Thu, 28 Jan 2021 at 17:15, Robin Müller 
> wrote:
>
>> Alright, I think these descriptors were not initialized inside the
>> functions:
>> ETH_DMATxDescListInit
>> ETH_DMARxDescListInit
>>
>> because they are wrapped in preprocessor guards:
>>
>> static void ETH_DMATxDescListInit(ETH_HandleTypeDef *heth)
>> {
>> #ifndef __rtems__
>>   ETH_DMADescTypeDef *dmatxdesc;
>>   uint32_t i;
>>
>>   /* Fill each DMATxDesc descriptor with the right values */
>>   for(i=0; i < (uint32_t)ETH_TX_DESC_CNT; i++)
>>   {
>> dmatxdesc = heth->Init.TxDesc + i;
>>
>> WRITE_REG(dmatxdesc->DESC0, 0x0);
>> WRITE_REG(dmatxdesc->DESC1, 0x0);
>> WRITE_REG(dmatxdesc->DESC2, 0x0);
>> WRITE_REG(dmatxdesc->DESC3, 0x0);
>>
>> WRITE_REG(heth->TxDescList.TxDesc[i], (uint32_t)dmatxdesc);
>>   }
>>
>>   heth->TxDescList.CurTxDesc = 0;
>>
>>   /* Set Transmit Descriptor Ring Length */
>>   WRITE_REG(heth->Instance->DMACTDRLR, (ETH_TX_DESC_CNT -1));
>>
>>   /* Set Transmit Descriptor List Address */
>>   WRITE_REG(heth->Instance->DMACTDLAR, (uint32_t) heth->Init.TxDesc);
>>
>>   /* Set Transmit Descriptor Tail pointer */
>>   WRITE_REG(heth->Instance->DMACTDTPR, (uint32_t) heth->Init.TxDesc);
>> #endif /* __rtems__ */
>> }
>>
>> Is there a specific reason the function was excluded?
>>
>> Kind Regards
>> Robin
>>
>> On Thu, 28 Jan 2021 at 16:47, Sebastian Huber <
>> sebastian.hu...@embedded-brains.de> wrote:
>>
>>> On 28/01/2021 16:45, Robin Müller wrote:
>>>
>>> >  *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.bsp_nocache*)))
>>> >  .bsp_nocache   0x3000 0x18c0
>>> >
>>> CMakeFiles/fsfw_example.dir/bsp_stm32_rtems/boardconfig/ethernetif.c.obj
>>> > 0x3000DMARxDscrTab
>>> > 0x3060DMATxDscrTab
>>> > 0x30c0Rx_Buff
>>> > 0x300018c0  bsp_section_nocache_end = .
>>> > 0x18c0  bsp_section_nocache_size =
>>> > (bsp_section_nocache_end - bsp_section_nocache_begin)
>>> >
>>> > But in the debugger, the descriptor entries are still zeroed out
>>> > unfortunately..
>>> If you place them in BSP_NOCACHENOLOAD_SECTION or
>>> BSP_NOCACHENOLOAD_SUBSECTION(), they are not loaded (zero initialized).
>>>
>>> --
>>> embedded brains GmbH
>>> Herr Sebastian HUBER
>>> Dornierstr. 4
>>> 82178 Puchheim
>>> Germany
>>> email: sebastian.hu...@embedded-brains.de
>>> phone: +49-89-18 94 741 - 16
>>> fax:   +49-89-18 94 741 - 08
>>>
>>> Registergericht: Amtsgericht München
>>> Registernummer: HRB 157899
>>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>>> Unsere Datenschutzerklärung finden Sie hier:
>>> https://embedded-brains.de/datenschutzerklaerung/
>>>
>>>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Using LwIP on the STM32H7

Okay, I managed to achieve the initialization process by adapting the BSP
to perform the descriptor list initialization.
Unfortunately, the program now appears to crash in the following polling
function, which is called every 100 ms:

void ethernetif_input(struct netif *netif)
{
  err_t err;
  struct pbuf *p;

  /* move received packet into a new pbuf */
  p = low_level_input(netif);

  /* no packet could be read, silently ignore this */
  if (p == NULL) return;

  /* entry point to the LwIP stack */
  err = netif->input(p, netif);

  if (err != ERR_OK)
  {
LWIP_DEBUGF(NETIF_DEBUG, ("ethernetif_input: IP input error\n"));
pbuf_free(p);
p = NULL;
  }

  HAL_ETH_BuildRxDescriptors();
}

More specifically, it appears to crash in netif->input.. Is there someone
who has managed to make LwIP work on the STM32 with the Raw API?

Kind Regards
Robin Müller

On Thu, 28 Jan 2021 at 17:15, Robin Müller 
wrote:

> Alright, I think these descriptors were not initialized inside the
> functions:
> ETH_DMATxDescListInit
> ETH_DMARxDescListInit
>
> because they are wrapped in preprocessor guards:
>
> static void ETH_DMATxDescListInit(ETH_HandleTypeDef *heth)
> {
> #ifndef __rtems__
>   ETH_DMADescTypeDef *dmatxdesc;
>   uint32_t i;
>
>   /* Fill each DMATxDesc descriptor with the right values */
>   for(i=0; i < (uint32_t)ETH_TX_DESC_CNT; i++)
>   {
> dmatxdesc = heth->Init.TxDesc + i;
>
> WRITE_REG(dmatxdesc->DESC0, 0x0);
> WRITE_REG(dmatxdesc->DESC1, 0x0);
> WRITE_REG(dmatxdesc->DESC2, 0x0);
> WRITE_REG(dmatxdesc->DESC3, 0x0);
>
> WRITE_REG(heth->TxDescList.TxDesc[i], (uint32_t)dmatxdesc);
>   }
>
>   heth->TxDescList.CurTxDesc = 0;
>
>   /* Set Transmit Descriptor Ring Length */
>   WRITE_REG(heth->Instance->DMACTDRLR, (ETH_TX_DESC_CNT -1));
>
>   /* Set Transmit Descriptor List Address */
>   WRITE_REG(heth->Instance->DMACTDLAR, (uint32_t) heth->Init.TxDesc);
>
>   /* Set Transmit Descriptor Tail pointer */
>   WRITE_REG(heth->Instance->DMACTDTPR, (uint32_t) heth->Init.TxDesc);
> #endif /* __rtems__ */
> }
>
> Is there a specific reason the function was excluded?
>
> Kind Regards
> Robin
>
> On Thu, 28 Jan 2021 at 16:47, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 28/01/2021 16:45, Robin Müller wrote:
>>
>> >  *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.bsp_nocache*)))
>> >  .bsp_nocache   0x3000 0x18c0
>> > CMakeFiles/fsfw_example.dir/bsp_stm32_rtems/boardconfig/ethernetif.c.obj
>> > 0x3000DMARxDscrTab
>> > 0x3060DMATxDscrTab
>> > 0x30c0Rx_Buff
>> > 0x300018c0  bsp_section_nocache_end = .
>> > 0x18c0  bsp_section_nocache_size =
>> > (bsp_section_nocache_end - bsp_section_nocache_begin)
>> >
>> > But in the debugger, the descriptor entries are still zeroed out
>> > unfortunately..
>> If you place them in BSP_NOCACHENOLOAD_SECTION or
>> BSP_NOCACHENOLOAD_SUBSECTION(), they are not loaded (zero initialized).
>>
>> --
>> embedded brains GmbH
>> Herr Sebastian HUBER
>> Dornierstr. 4
>> 82178 Puchheim
>> Germany
>> email: sebastian.hu...@embedded-brains.de
>> phone: +49-89-18 94 741 - 16
>> fax:   +49-89-18 94 741 - 08
>>
>> Registergericht: Amtsgericht München
>> Registernummer: HRB 157899
>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>> Unsere Datenschutzerklärung finden Sie hier:
>> https://embedded-brains.de/datenschutzerklaerung/
>>
>>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Using LwIP on the STM32H7

Alright, I think these descriptors were not initialized inside the
functions:
ETH_DMATxDescListInit
ETH_DMARxDescListInit

because they are wrapped in preprocessor guards:

static void ETH_DMATxDescListInit(ETH_HandleTypeDef *heth)
{
#ifndef __rtems__
  ETH_DMADescTypeDef *dmatxdesc;
  uint32_t i;

  /* Fill each DMATxDesc descriptor with the right values */
  for(i=0; i < (uint32_t)ETH_TX_DESC_CNT; i++)
  {
dmatxdesc = heth->Init.TxDesc + i;

WRITE_REG(dmatxdesc->DESC0, 0x0);
WRITE_REG(dmatxdesc->DESC1, 0x0);
WRITE_REG(dmatxdesc->DESC2, 0x0);
WRITE_REG(dmatxdesc->DESC3, 0x0);

WRITE_REG(heth->TxDescList.TxDesc[i], (uint32_t)dmatxdesc);
  }

  heth->TxDescList.CurTxDesc = 0;

  /* Set Transmit Descriptor Ring Length */
  WRITE_REG(heth->Instance->DMACTDRLR, (ETH_TX_DESC_CNT -1));

  /* Set Transmit Descriptor List Address */
  WRITE_REG(heth->Instance->DMACTDLAR, (uint32_t) heth->Init.TxDesc);

  /* Set Transmit Descriptor Tail pointer */
  WRITE_REG(heth->Instance->DMACTDTPR, (uint32_t) heth->Init.TxDesc);
#endif /* __rtems__ */
}

Is there a specific reason the function was excluded?

Kind Regards
Robin

On Thu, 28 Jan 2021 at 16:47, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 28/01/2021 16:45, Robin Müller wrote:
>
> >  *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.bsp_nocache*)))
> >  .bsp_nocache   0x3000 0x18c0
> > CMakeFiles/fsfw_example.dir/bsp_stm32_rtems/boardconfig/ethernetif.c.obj
> > 0x3000DMARxDscrTab
> > 0x3060DMATxDscrTab
> > 0x30c0Rx_Buff
> > 0x300018c0  bsp_section_nocache_end = .
> > 0x18c0  bsp_section_nocache_size =
> > (bsp_section_nocache_end - bsp_section_nocache_begin)
> >
> > But in the debugger, the descriptor entries are still zeroed out
> > unfortunately..
> If you place them in BSP_NOCACHENOLOAD_SECTION or
> BSP_NOCACHENOLOAD_SUBSECTION(), they are not loaded (zero initialized).
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Using LwIP on the STM32H7

2021-01-28 Thread Sebastian Huber


On 28/01/2021 16:45, Robin Müller wrote:


 *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.bsp_nocache*)))
 .bsp_nocache   0x3000     0x18c0 
CMakeFiles/fsfw_example.dir/bsp_stm32_rtems/boardconfig/ethernetif.c.obj

                0x3000                DMARxDscrTab
                0x3060                DMATxDscrTab
                0x30c0                Rx_Buff
                0x300018c0  bsp_section_nocache_end = .
                0x18c0  bsp_section_nocache_size = 
(bsp_section_nocache_end - bsp_section_nocache_begin)


But in the debugger, the descriptor entries are still zeroed out 
unfortunately..
If you place them in BSP_NOCACHENOLOAD_SECTION or 
BSP_NOCACHENOLOAD_SUBSECTION(), they are not loaded (zero initialized).


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Using LwIP on the STM32H7

Thanks Sebastian.

The descriptors now appear to have addresses inside the RAM according to
the map file

 *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.bsp_nocache*)))
 .bsp_nocache   0x3000 0x18c0
CMakeFiles/fsfw_example.dir/bsp_stm32_rtems/boardconfig/ethernetif.c.obj
0x3000DMARxDscrTab
0x3060DMATxDscrTab
0x30c0Rx_Buff
0x300018c0bsp_section_nocache_end =
.
0x18c0bsp_section_nocache_size
= (bsp_section_nocache_end - bsp_section_nocache_begin)

But in the debugger, the descriptor entries are still zeroed out
unfortunately..

Kind Regards
Robin Müller

On Thu, 28 Jan 2021 at 16:39, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 28/01/2021 14:35, Robin Müller wrote:
>
> > So far, transferring the code has worked, but there are some specific
> > sections in the code used for our FreeRTOS example which put the
> > ethernet DMA descriptors in specific sections:
> >
> > ETH_DMADescTypeDef DMARxDscrTab[ETH_RX_DESC_CNT]
> > __attribute__((section(".RxDecripSection"))); /* Ethernet Rx DMA
> > Descriptors */
> > ETH_DMADescTypeDef DMATxDscrTab[ETH_TX_DESC_CNT]
> > __attribute__((section(".TxDecripSection")));   /* Ethernet Tx DMA
> > Descriptors */
> > uint8_t Rx_Buff[ETH_RX_DESC_CNT][ETH_RX_BUFFER_SIZE]
> > __attribute__((section(".RxArraySection"))); /* Ethernet Receive
> > Buffers */
>
> The BSP has a nocache section, see
>
> bsps/arm/include/bsp/linker-symbols.h
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Using LwIP on the STM32H7

2021-01-28 Thread Sebastian Huber


On 28/01/2021 14:35, Robin Müller wrote:

So far, transferring the code has worked, but there are some specific 
sections in the code used for our FreeRTOS example which put the 
ethernet DMA descriptors in specific sections:


ETH_DMADescTypeDef DMARxDscrTab[ETH_RX_DESC_CNT] 
__attribute__((section(".RxDecripSection"))); /* Ethernet Rx DMA 
Descriptors */
ETH_DMADescTypeDef DMATxDscrTab[ETH_TX_DESC_CNT] 
__attribute__((section(".TxDecripSection")));   /* Ethernet Tx DMA 
Descriptors */
uint8_t Rx_Buff[ETH_RX_DESC_CNT][ETH_RX_BUFFER_SIZE] 
__attribute__((section(".RxArraySection"))); /* Ethernet Receive 
Buffers */


The BSP has a nocache section, see

bsps/arm/include/bsp/linker-symbols.h

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Using LwIP on the STM32H7

2021-01-28 Thread Joel Sherrill

Specific addresses shouldn't be in the shared linkcmds.base.

You could define new macro names like the other memory types and addresses
and add those to the generic linkcmds. Then the linkcmds.base would
generically know those sections and your BSP could set the right macros to
place it.

One thought is to add linkcmds.lwip which have those special sections (if
they are common in LWIP -- not driver specific), and then have the BSP
define the right things and then include linkcmds.lwip and linkcmds.base.
That way BSPs which want to potentially use lwip could include the lwip
linkcmds fragment and get the sections.

But if those section names are driver specific, this isn't a good
organization and we will have to think more.

Hope that makes sense.

--joel

On Thu, Jan 28, 2021 at 7:37 AM Robin Müller 
wrote:

> Some clarification: The linker script used for RTEMS is of course the
> default RTEMS linker script, the FreeRTOS example used the linker file
> taken from the STM32CubeH7 repository.
>
> Kind Regards
> Robin Müller
>
> On Thu, 28 Jan 2021 at 14:35, Robin Müller 
> wrote:
>
>> Hi,
>>
>> I am trying to get LwIP working on the STM32H7 because it has a low RAM
>> usage (at least that's what I heard). We already did this for FreeRTOS, but
>> we used the LwIP Raw API to not be bound specifically to the OS. I am now
>> trying to adapt LwIP to RTEMS , but I'm not really a LwIP expert and most
>> did copy & paste up until now.
>>
>> So far, transferring the code has worked, but there are some specific
>> sections in the code used for our FreeRTOS example which put the ethernet
>> DMA descriptors in specific sections:
>>
>> ETH_DMADescTypeDef DMARxDscrTab[ETH_RX_DESC_CNT]
>> __attribute__((section(".RxDecripSection"))); /* Ethernet Rx DMA
>> Descriptors */
>> ETH_DMADescTypeDef DMATxDscrTab[ETH_TX_DESC_CNT]
>> __attribute__((section(".TxDecripSection")));   /* Ethernet Tx DMA
>> Descriptors */
>> uint8_t Rx_Buff[ETH_RX_DESC_CNT][ETH_RX_BUFFER_SIZE]
>> __attribute__((section(".RxArraySection"))); /* Ethernet Receive Buffers */
>>
>> /* For RTEMS can we put this in the text section? */
>> //ETH_DMADescTypeDef DMARxDscrTab[ETH_RX_DESC_CNT]; /* Ethernet Rx DMA
>> Descriptors */
>> //ETH_DMADescTypeDef DMATxDscrTab[ETH_TX_DESC_CNT];   /* Ethernet Tx DMA
>> Descriptors */
>> //uint8_t Rx_Buff[ETH_RX_DESC_CNT][ETH_RX_BUFFER_SIZE]; /* Ethernet
>> Receive Buffers */
>>
>> I got an "section `.unexpected_sections' will not fit in region
>> *   `UNEXPECTED_SECTIONS'" error because of this. I checked the linker
>> script used, which was taken from the STM32CubeH7 repository and found this
>> LwIP specific section:
>>
>>   .lwip_sec (NOLOAD) : {
>> . = ABSOLUTE(0x3004);
>> *(.RxDecripSection)
>>
>> . = ABSOLUTE(0x30040060);
>> *(.TxDecripSection)
>>
>> . = ABSOLUTE(0x30040200);
>> *(.RxArraySection)
>>   } >RAM_D2 AT> FLASH
>>
>> So the descriptors are placed at RAM_D2 (or SRAM_3 in RTEMS). I've placed
>> the following
>> section in linkcmds.base now:
>>
>> .lwip_sec (NOLOAD) : ALIGN_WITH_INPUT {
>> . = ABSOLUTE(0x3004);
>> *(.RxDecripSection)
>>
>> . = ABSOLUTE(0x30040060);
>> *(.TxDecripSection)
>>
>> . = ABSOLUTE(0x30040200);
>>*(.RxArraySection)
>>   } >SRAM_3 AT> REGION_TEXT_LOAD
>>
>> Are any STM32 or LwIP experts here that see a problem with this adaption?
>> I still need to do some other stuff to integrate LwIP properly so I haven't
>> tested it yet. Are there any other thinks I need to take into account for
>> making LwIP work with RTEMS?
>>
>> Kind Regards
>> Robin
>>
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Using LwIP on the STM32H7