Re: [PATCH] Basic lwIP for STM32H7 BSP

[Robin Müller]

I solved it like you mentioned now by putting the descriptors in the
.bsp_no_cache section and with the correct alignment.

/* Put into special RTEMS section and align correctly */
ETH_DMADescTypeDef DMARxDscrTab[ETH_RX_DESC_CNT]
__attribute__((section(".bsp_nocache"),
__aligned__(DMA_DESCRIPTOR_ALIGNMENT)));
/* Put into special RTEMS section and align correctly */
ETH_DMADescTypeDef DMATxDscrTab[ETH_TX_DESC_CNT]
 __attribute__((section(".bsp_nocache"),
__aligned__(DMA_DESCRIPTOR_ALIGNMENT)));
uint8_t Rx_Buff[ETH_RX_DESC_CNT][ETH_RX_BUFFER_SIZE];

I will update the patch I sent with the sections removed from linccmd.base
. Maybe it still would be a better idea to have a separate BSP for the
STm32H743ZIT6-Nucleo but I would have to look into how to do this again.

Kind Regards
Robin

On Fri, 26 Mar 2021 at 15:24, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
> On 26/03/2021 11:34, Robin Müller wrote:
> > How would you define a generic linker section? I tried to put the
> > following section into the
> > linkcmdsmemory file like you suggested (at
> > spec/build/bsps/arm/stm32h7/linkcmdsmemory.yml):
> >
> >   SECTIONS {
> > .stm32h7_sram_3 (NOLOAD) : ALIGN_WITH_INPUT {
> >   bsp_stm32h7_sram_3_start = stm32h7_memory_sram_3_begin;
> >   bsp_stm32h7_sram_3_end = stm32h7_memory_sram_3_end;
> > } > SRAM_3 AT > FLASH
> >   }
>
> This should work. You need also input sections for this output section.
> I still don't know why you can't use the already existing:
>
>  .nocache : ALIGN_WITH_INPUT {
>  bsp_section_nocache_begin = .;
>  *(SORT_BY_ALIGNMENT (SORT_BY_NAME (.bsp_nocache*)))
>  bsp_section_nocache_end = .;
>  } > REGION_NOCACHE AT > REGION_NOCACHE_LOAD
>  bsp_section_nocache_size = bsp_section_nocache_end -
> bsp_section_nocache_begin;
>  bsp_section_nocache_load_begin = LOADADDR (.nocache);
>  bsp_section_nocache_load_end = bsp_section_nocache_load_begin +
> bsp_section_nocache_size;
>
>  .nocachenoload (NOLOAD) : ALIGN_WITH_INPUT {
>  bsp_section_nocachenoload_begin = .;
>  *(SORT_BY_ALIGNMENT (SORT_BY_NAME (.bsp_noload_nocache*)))
>  bsp_section_nocacheheap_begin = .;
>  . += ORIGIN (REGION_NOCACHE) + LENGTH (REGION_NOCACHE) -
> ABSOLUTE (.);
>  bsp_section_nocacheheap_end = .;
>  bsp_section_nocachenoload_end = .;
>  } > REGION_NOCACHE AT > REGION_NOCACHE
>  bsp_section_nocacheheap_size = bsp_section_nocacheheap_end -
> bsp_section_nocacheheap_begin;
>  bsp_section_nocachenoload_size = bsp_section_nocachenoload_end -
> bsp_section_nocachenoload_begin;
>
> For the stm32h7 these regions are used:
>
>REGION_ALIAS ("REGION_NOCACHE", SRAM_1);
>REGION_ALIAS ("REGION_NOCACHE_LOAD", SDRAM_1);
>
> >
> > But the waf build fails with  a syntax error:
> >
> > [1610/1611] Linking build/arm/stm32h7/testsuites/samples/ticker.exe
> > [1611/1611] Linking build/arm/stm32h7/testsuites/samples/unlimited.exe
> >
> c:/users/robin/rtems/rtems-tools/rtems/6/bin/../lib/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/ld.exe:linkcmds.memory:84:
>
> > syntax error
> > collect2.exe: error: ld returned 1 exit status
> >
> >
> c:/users/robin/rtems/rtems-tools/rtems/6/bin/../lib/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/ld.exe:linkcmds.memory:84:
>
> > syntax error
> > collect2.exe: error: ld returned 1 exit status
> What is around line 84?
>
> --
> 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/
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Basic lwIP for STM32H7 BSP

[Sebastian Huber]

On 26/03/2021 11:34, Robin Müller wrote:
How would you define a generic linker section? I tried to put the 
following section into the
linkcmdsmemory file like you suggested (at 
spec/build/bsps/arm/stm32h7/linkcmdsmemory.yml):


  SECTIONS {
    .stm32h7_sram_3 (NOLOAD) : ALIGN_WITH_INPUT {
      bsp_stm32h7_sram_3_start = stm32h7_memory_sram_3_begin;
      bsp_stm32h7_sram_3_end = stm32h7_memory_sram_3_end;
    } > SRAM_3 AT > FLASH
  }


This should work. You need also input sections for this output section. 
I still don't know why you can't use the already existing:


    .nocache : ALIGN_WITH_INPUT {
        bsp_section_nocache_begin = .;
        *(SORT_BY_ALIGNMENT (SORT_BY_NAME (.bsp_nocache*)))
        bsp_section_nocache_end = .;
    } > REGION_NOCACHE AT > REGION_NOCACHE_LOAD
    bsp_section_nocache_size = bsp_section_nocache_end - 
bsp_section_nocache_begin;

    bsp_section_nocache_load_begin = LOADADDR (.nocache);
    bsp_section_nocache_load_end = bsp_section_nocache_load_begin + 
bsp_section_nocache_size;


    .nocachenoload (NOLOAD) : ALIGN_WITH_INPUT {
        bsp_section_nocachenoload_begin = .;
        *(SORT_BY_ALIGNMENT (SORT_BY_NAME (.bsp_noload_nocache*)))
        bsp_section_nocacheheap_begin = .;
        . += ORIGIN (REGION_NOCACHE) + LENGTH (REGION_NOCACHE) - 
ABSOLUTE (.);

        bsp_section_nocacheheap_end = .;
        bsp_section_nocachenoload_end = .;
    } > REGION_NOCACHE AT > REGION_NOCACHE
    bsp_section_nocacheheap_size = bsp_section_nocacheheap_end - 
bsp_section_nocacheheap_begin;
    bsp_section_nocachenoload_size = bsp_section_nocachenoload_end - 
bsp_section_nocachenoload_begin;


For the stm32h7 these regions are used:

  REGION_ALIAS ("REGION_NOCACHE", SRAM_1);
  REGION_ALIAS ("REGION_NOCACHE_LOAD", SDRAM_1);



But the waf build fails with  a syntax error:

[1610/1611] Linking build/arm/stm32h7/testsuites/samples/ticker.exe
[1611/1611] Linking build/arm/stm32h7/testsuites/samples/unlimited.exe
c:/users/robin/rtems/rtems-tools/rtems/6/bin/../lib/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/ld.exe:linkcmds.memory:84: 
syntax error

collect2.exe: error: ld returned 1 exit status

c:/users/robin/rtems/rtems-tools/rtems/6/bin/../lib/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/ld.exe:linkcmds.memory:84: 
syntax error

collect2.exe: error: ld returned 1 exit status

What is around line 84?

--
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/

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

Re: [PATCH] Basic lwIP for STM32H7 BSP

[Robin Müller]

How would you define a generic linker section? I tried to put the following
section into the
linkcmdsmemory file like you suggested (at
spec/build/bsps/arm/stm32h7/linkcmdsmemory.yml):

  SECTIONS {
.stm32h7_sram_3 (NOLOAD) : ALIGN_WITH_INPUT {
  bsp_stm32h7_sram_3_start = stm32h7_memory_sram_3_begin;
  bsp_stm32h7_sram_3_end = stm32h7_memory_sram_3_end;
} > SRAM_3 AT > FLASH
  }

But the waf build fails with  a syntax error:

[1610/1611] Linking build/arm/stm32h7/testsuites/samples/ticker.exe
[1611/1611] Linking build/arm/stm32h7/testsuites/samples/unlimited.exe
c:/users/robin/rtems/rtems-tools/rtems/6/bin/../lib/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/ld.exe:linkcmds.memory:84:
syntax error
collect2.exe: error: ld returned 1 exit status

c:/users/robin/rtems/rtems-tools/rtems/6/bin/../lib/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/ld.exe:linkcmds.memory:84:
syntax error
collect2.exe: error: ld returned 1 exit status

Kind Regards
Robin

On Thu, 25 Mar 2021 at 13:15, Robin Müller 
wrote:

> That is how it was done in the lwIP demo provided by STM, I simply adopted
> that. The SRAM3 is small, but big enough for lwIP, so all of it is used
> completely by lwIP.
> How would you place the descriptors in code so that these linker script
> sections are not necessary? You mentioned RTEMS_SECTIONs. Are those used in
> the source code?
>
> Kind Regards
> Robin Müller
>
> On Mon, 22 Mar 2021 at 11:43, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 03/02/2021 14:50, Robin Müller wrote:
>>
>> > The following link contains more theoretical information about why
>> > these sections were placed at these addresses:
>> >
>> https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices
>> > <
>> https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices
>> >
>> >
>> > Kind Regards
>> > Robin
>> >
>> > On Wed, 3 Feb 2021 at 14:44, Robin Müller > > > wrote:
>> >
>> > The DMA descriptors need to be placed at the start of the SRAM3
>> > and need to be aligned in a certain way. The RX buffer will take
>> > up the first (slightly less than) 16 kB of SRAM3 but needs to be
>> > placed
>> > behind the DMA descriptors. It also needs to be placed in a way
>> > that the MPU configuration required for the DMA descriptors will
>> > not do something with the RX buffers.
>> > In the example provided by STM32, the first 256 bytes are
>> > configured by MPU Config.
>> >
>> I had a look at the FAQ and the manual. Currently, we use the SRAM1 for
>> the .nocache area. This is in the D2 domain. The Ethernet module is in
>> the D2 domain. I am not sure why you have to change this to the smaller
>> SRAM3? The libbsd driver works well with the current setting.
>>
>> --
>> 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/
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Basic lwIP for STM32H7 BSP

[Robin Müller]

That is how it was done in the lwIP demo provided by STM, I simply adopted
that. The SRAM3 is small, but big enough for lwIP, so all of it is used
completely by lwIP.
How would you place the descriptors in code so that these linker script
sections are not necessary? You mentioned RTEMS_SECTIONs. Are those used in
the source code?

Kind Regards
Robin Müller

On Mon, 22 Mar 2021 at 11:43, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 03/02/2021 14:50, Robin Müller wrote:
>
> > The following link contains more theoretical information about why
> > these sections were placed at these addresses:
> >
> https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices
> > <
> https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices
> >
> >
> > Kind Regards
> > Robin
> >
> > On Wed, 3 Feb 2021 at 14:44, Robin Müller  > > wrote:
> >
> > The DMA descriptors need to be placed at the start of the SRAM3
> > and need to be aligned in a certain way. The RX buffer will take
> > up the first (slightly less than) 16 kB of SRAM3 but needs to be
> > placed
> > behind the DMA descriptors. It also needs to be placed in a way
> > that the MPU configuration required for the DMA descriptors will
> > not do something with the RX buffers.
> > In the example provided by STM32, the first 256 bytes are
> > configured by MPU Config.
> >
> I had a look at the FAQ and the manual. Currently, we use the SRAM1 for
> the .nocache area. This is in the D2 domain. The Ethernet module is in
> the D2 domain. I am not sure why you have to change this to the smaller
> SRAM3? The libbsd driver works well with the current setting.
>
> --
> 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/
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Basic lwIP for STM32H7 BSP

[Sebastian Huber]

On 03/02/2021 14:50, Robin Müller wrote:

The following link contains more theoretical information about why 
these sections were placed at these addresses: 
https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices 



Kind Regards
Robin

On Wed, 3 Feb 2021 at 14:44, Robin Müller > wrote:


The DMA descriptors need to be placed at the start of the SRAM3
and need to be aligned in a certain way. The RX buffer will take
up the first (slightly less than) 16 kB of SRAM3 but needs to be
placed
behind the DMA descriptors. It also needs to be placed in a way
that the MPU configuration required for the DMA descriptors will
not do something with the RX buffers.
In the example provided by STM32, the first 256 bytes are
configured by MPU Config.

I had a look at the FAQ and the manual. Currently, we use the SRAM1 for 
the .nocache area. This is in the D2 domain. The Ethernet module is in 
the D2 domain. I am not sure why you have to change this to the smaller 
SRAM3? The libbsd driver works well with the current setting.


--
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/

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

Re: [PATCH] Basic lwIP for STM32H7 BSP

[Robin Müller]

Any progress on this issue?
I am currently trying to compile the BBB BSP and the adaptations I did to
the linkcmds.base file are definitely problematic..

Kind Regards
Robin

On Fri, 19 Feb 2021 at 08:08, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 18/02/2021 20:55, Gedare Bloom wrote:
>
> > On Thu, Feb 4, 2021 at 10:58 AM Sebastian Huber
> >   wrote:
> >> On 04/02/2021 18:45, Robin Müller wrote:
> >>
> >>> Could you look into this, based on the existing patch? I don't really
> >>> have the time to look (deeply) into it in the next few weeks,
> >>> and the changes are probably easier  for you to implement. I can offer
> >>> to test it though :-)
> >> Ok, please remind me in a week. I am currently quite busy.
> >>
> > It's been a week.
> I am sorry. What makes things even worse is that I am not in the office
> next week.
> >
> --
> 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/
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Basic lwIP for STM32H7 BSP

[Sebastian Huber]

On 18/02/2021 20:55, Gedare Bloom wrote:


On Thu, Feb 4, 2021 at 10:58 AM Sebastian Huber
  wrote:

On 04/02/2021 18:45, Robin Müller wrote:


Could you look into this, based on the existing patch? I don't really
have the time to look (deeply) into it in the next few weeks,
and the changes are probably easier  for you to implement. I can offer
to test it though :-)

Ok, please remind me in a week. I am currently quite busy.


It's been a week.
I am sorry. What makes things even worse is that I am not in the office 
next week.



--
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/

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

Re: [PATCH] Basic lwIP for STM32H7 BSP

[Gedare Bloom]

On Thu, Feb 4, 2021 at 10:58 AM Sebastian Huber
 wrote:
>
> On 04/02/2021 18:45, Robin Müller wrote:
>
> > Could you look into this, based on the existing patch? I don't really
> > have the time to look (deeply) into it in the next few weeks,
> > and the changes are probably easier  for you to implement. I can offer
> > to test it though :-)
> Ok, please remind me in a week. I am currently quite busy.
>
It's been a week.

> --
> 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/
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Basic lwIP for STM32H7 BSP

[Sebastian Huber]

On 04/02/2021 18:45, Robin Müller wrote:

Could you look into this, based on the existing patch? I don't really 
have the time to look (deeply) into it in the next few weeks,
and the changes are probably easier  for you to implement. I can offer 
to test it though :-)

Ok, please remind me in a week. I am currently quite busy.

--
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/

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

Re: [PATCH] Basic lwIP for STM32H7 BSP

[Robin Müller]

Could you look into this, based on the existing patch? I don't really have
the time to look (deeply) into it in the next few weeks,
and the changes are probably easier  for you to implement. I can offer to
test it though :-)

Kind Regards
Robin Müller

On Thu, 4 Feb 2021 at 14:41, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 04/02/2021 14:39, Joel Sherrill wrote:
>
> > On Thu, Feb 4, 2021, 6:18 AM Robin Müller  > > wrote:
> >
> > I think the DMA descriptors need to be 32 byte (0x20) aligned.
> > That's the reason the example application was set up like this.
> >
> >
> > But you can just as easily turn them into pointers which point to 32
> > byte aligned areas in a nocache region.
> >
> > Just wondering if that's possible with the code because I think it
> > would be easier with the existing linkcmds to assign a nocache area as
> > you need and then split it by hand.
> >
> > Sebastian... ?
> I would prefer to use a generic linker section definition and then
> simply define global data structures in the right section with the right
> alignment (see RTEMS_ALIGN()).
>
> --
> 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/
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Basic lwIP for STM32H7 BSP

[Sebastian Huber]

On 04/02/2021 14:39, Joel Sherrill wrote:

On Thu, Feb 4, 2021, 6:18 AM Robin Müller > wrote:


I think the DMA descriptors need to be 32 byte (0x20) aligned.
That's the reason the example application was set up like this.


But you can just as easily turn them into pointers which point to 32 
byte aligned areas in a nocache region.


Just wondering if that's possible with the code because I think it 
would be easier with the existing linkcmds to assign a nocache area as 
you need and then split it by hand.


Sebastian... ?
I would prefer to use a generic linker section definition and then 
simply define global data structures in the right section with the right 
alignment (see RTEMS_ALIGN()).


--
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/

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

Re: [PATCH] Basic lwIP for STM32H7 BSP

[Joel Sherrill]

On Thu, Feb 4, 2021, 6:18 AM Robin Müller  wrote:

> I think the DMA descriptors need to be 32 byte (0x20) aligned. That's the
> reason the example application was set up like this.
>

But you can just as easily turn them into pointers which point to 32 byte
aligned areas in a nocache region.

Just wondering if that's possible with the code because I think it would be
easier with the existing linkcmds to assign a nocache area as you need and
then split it by hand.

Sebastian... ?

>
> Kind Regards
> Robin
>
> On Wed, 3 Feb 2021 at 15:32, Joel Sherrill  wrote:
>
>>
>>
>> On Wed, Feb 3, 2021, 8:26 AM Robin Müller 
>> wrote:
>>
>>> Also, Andrei Chichak provided a very good explanation:
>>>
>>> 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.

>>>
>> Just asking. Can this be a non-cacheable region and the variables not in
>> special sections? I wonder if changing them to normal pointers to special
>> memory would ripple. Do they just use the variables for initialization or
>> reference them a lot?
>>
>> I think the standard linkcmds setup allows for nocache areas already.
>>
>> --joel
>>
>>
>>> Kind Regards
>>> Robin Müller
>>>
>>> On Wed, 3 Feb 2021 at 14:50, Robin Müller 
>>> wrote:
>>>
 The following link contains more theoretical information about why
 these sections were placed at these addresses:
 https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices

 Kind Regards
 Robin

 On Wed, 3 Feb 2021 at 14:44, Robin Müller 
 wrote:

> The DMA descriptors need to be placed at the start of the SRAM3 and
> need to be aligned in a certain way. The RX buffer will take up the first
> (slightly less than) 16 kB of SRAM3 but needs to be placed
> behind the DMA descriptors. It also needs to be placed in a way that
> the MPU configuration required for the DMA descriptors will not do
> something with the RX buffers.
> In the example provided by STM32, the first 256 bytes are configured
> by MPU Config.
>
> Kind Regards
> Robin
>
>
>
> On Wed, 3 Feb 2021 at 13:43, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 02/02/2021 20:10, Robin Mueller wrote:
>>
>> > + /* Not an ideal solution but required for lwIP on the STM32H7
>> BSP.
>> > + This places the DMA descriptors for lwIP at the start of
>> SRAM3.
>> > + The MPU still needs to be configured for the DMA descriptor
>> regions to be
>> > + bufferable, non-cacheable, non-shareable (first 256 bytes) */
>> > + .lwip_sec_stm32h7 (NOLOAD) : ALIGN_WITH_INPUT {
>> > + . = ABSOLUTE(0x3004);
>> > + *(.RxDecripSection)
>> > + . = ABSOLUTE(0x30040060);
>> > + *(.TxDecripSection)
>> > + . = ABSOLUTE(0x30040200);
>> > + *(.RxArraySection)
>> > + } >SRAM_3 AT> REGION_TEXT_LOAD
>> > +
>>
>> This is the wrong linker command file. This stuff should be in
>>
>> spec/build/bsps/arm/stm32h7/linkcmdsmemory.yml
>>
>> with an output section name like ".stm32h7_sram_3" and corresponding
>> input section names. Why do you need absolute addresses here?
>>
>> --
>> 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/
>>
>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>

Re: [PATCH] Basic lwIP for STM32H7 BSP

[Robin Müller]

I think the DMA descriptors need to be 32 byte (0x20) aligned. That's the
reason the example application was set up like this.

Kind Regards
Robin

On Wed, 3 Feb 2021 at 15:32, Joel Sherrill  wrote:

>
>
> On Wed, Feb 3, 2021, 8:26 AM Robin Müller 
> wrote:
>
>> Also, Andrei Chichak provided a very good explanation:
>>
>> 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.
>>>
>>
> Just asking. Can this be a non-cacheable region and the variables not in
> special sections? I wonder if changing them to normal pointers to special
> memory would ripple. Do they just use the variables for initialization or
> reference them a lot?
>
> I think the standard linkcmds setup allows for nocache areas already.
>
> --joel
>
>
>> Kind Regards
>> Robin Müller
>>
>> On Wed, 3 Feb 2021 at 14:50, Robin Müller 
>> wrote:
>>
>>> The following link contains more theoretical information about why these
>>> sections were placed at these addresses:
>>> https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices
>>>
>>> Kind Regards
>>> Robin
>>>
>>> On Wed, 3 Feb 2021 at 14:44, Robin Müller 
>>> wrote:
>>>
 The DMA descriptors need to be placed at the start of the SRAM3 and
 need to be aligned in a certain way. The RX buffer will take up the first
 (slightly less than) 16 kB of SRAM3 but needs to be placed
 behind the DMA descriptors. It also needs to be placed in a way that
 the MPU configuration required for the DMA descriptors will not do
 something with the RX buffers.
 In the example provided by STM32, the first 256 bytes are configured by
 MPU Config.

 Kind Regards
 Robin



 On Wed, 3 Feb 2021 at 13:43, Sebastian Huber <
 sebastian.hu...@embedded-brains.de> wrote:

> On 02/02/2021 20:10, Robin Mueller wrote:
>
> > + /* Not an ideal solution but required for lwIP on the STM32H7
> BSP.
> > + This places the DMA descriptors for lwIP at the start of SRAM3.
> > + The MPU still needs to be configured for the DMA descriptor
> regions to be
> > + bufferable, non-cacheable, non-shareable (first 256 bytes) */
> > + .lwip_sec_stm32h7 (NOLOAD) : ALIGN_WITH_INPUT {
> > + . = ABSOLUTE(0x3004);
> > + *(.RxDecripSection)
> > + . = ABSOLUTE(0x30040060);
> > + *(.TxDecripSection)
> > + . = ABSOLUTE(0x30040200);
> > + *(.RxArraySection)
> > + } >SRAM_3 AT> REGION_TEXT_LOAD
> > +
>
> This is the wrong linker command file. This stuff should be in
>
> spec/build/bsps/arm/stm32h7/linkcmdsmemory.yml
>
> with an output section name like ".stm32h7_sram_3" and corresponding
> input section names. Why do you need absolute addresses here?
>
> --
> 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/
>
> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Basic lwIP for STM32H7 BSP

[Joel Sherrill]

On Wed, Feb 3, 2021, 8:26 AM Robin Müller  wrote:

> Also, Andrei Chichak provided a very good explanation:
>
> 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.
>>
>
Just asking. Can this be a non-cacheable region and the variables not in
special sections? I wonder if changing them to normal pointers to special
memory would ripple. Do they just use the variables for initialization or
reference them a lot?

I think the standard linkcmds setup allows for nocache areas already.

--joel


> Kind Regards
> Robin Müller
>
> On Wed, 3 Feb 2021 at 14:50, Robin Müller 
> wrote:
>
>> The following link contains more theoretical information about why these
>> sections were placed at these addresses:
>> https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices
>>
>> Kind Regards
>> Robin
>>
>> On Wed, 3 Feb 2021 at 14:44, Robin Müller 
>> wrote:
>>
>>> The DMA descriptors need to be placed at the start of the SRAM3 and need
>>> to be aligned in a certain way. The RX buffer will take up the first
>>> (slightly less than) 16 kB of SRAM3 but needs to be placed
>>> behind the DMA descriptors. It also needs to be placed in a way that the
>>> MPU configuration required for the DMA descriptors will not do something
>>> with the RX buffers.
>>> In the example provided by STM32, the first 256 bytes are configured by
>>> MPU Config.
>>>
>>> Kind Regards
>>> Robin
>>>
>>>
>>>
>>> On Wed, 3 Feb 2021 at 13:43, Sebastian Huber <
>>> sebastian.hu...@embedded-brains.de> wrote:
>>>
 On 02/02/2021 20:10, Robin Mueller wrote:

 > + /* Not an ideal solution but required for lwIP on the STM32H7
 BSP.
 > + This places the DMA descriptors for lwIP at the start of SRAM3.
 > + The MPU still needs to be configured for the DMA descriptor
 regions to be
 > + bufferable, non-cacheable, non-shareable (first 256 bytes) */
 > + .lwip_sec_stm32h7 (NOLOAD) : ALIGN_WITH_INPUT {
 > + . = ABSOLUTE(0x3004);
 > + *(.RxDecripSection)
 > + . = ABSOLUTE(0x30040060);
 > + *(.TxDecripSection)
 > + . = ABSOLUTE(0x30040200);
 > + *(.RxArraySection)
 > + } >SRAM_3 AT> REGION_TEXT_LOAD
 > +

 This is the wrong linker command file. This stuff should be in

 spec/build/bsps/arm/stm32h7/linkcmdsmemory.yml

 with an output section name like ".stm32h7_sram_3" and corresponding
 input section names. Why do you need absolute addresses here?

 --
 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/

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

Re: [PATCH] Basic lwIP for STM32H7 BSP

[Robin Müller]

Also, Andrei Chichak provided a very good explanation:

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.
>

Kind Regards
Robin Müller

On Wed, 3 Feb 2021 at 14:50, Robin Müller  wrote:

> The following link contains more theoretical information about why these
> sections were placed at these addresses:
> https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices
>
> Kind Regards
> Robin
>
> On Wed, 3 Feb 2021 at 14:44, Robin Müller 
> wrote:
>
>> The DMA descriptors need to be placed at the start of the SRAM3 and need
>> to be aligned in a certain way. The RX buffer will take up the first
>> (slightly less than) 16 kB of SRAM3 but needs to be placed
>> behind the DMA descriptors. It also needs to be placed in a way that the
>> MPU configuration required for the DMA descriptors will not do something
>> with the RX buffers.
>> In the example provided by STM32, the first 256 bytes are configured by
>> MPU Config.
>>
>> Kind Regards
>> Robin
>>
>>
>>
>> On Wed, 3 Feb 2021 at 13:43, Sebastian Huber <
>> sebastian.hu...@embedded-brains.de> wrote:
>>
>>> On 02/02/2021 20:10, Robin Mueller wrote:
>>>
>>> > + /* Not an ideal solution but required for lwIP on the STM32H7
>>> BSP.
>>> > + This places the DMA descriptors for lwIP at the start of SRAM3.
>>> > + The MPU still needs to be configured for the DMA descriptor
>>> regions to be
>>> > + bufferable, non-cacheable, non-shareable (first 256 bytes) */
>>> > + .lwip_sec_stm32h7 (NOLOAD) : ALIGN_WITH_INPUT {
>>> > + . = ABSOLUTE(0x3004);
>>> > + *(.RxDecripSection)
>>> > + . = ABSOLUTE(0x30040060);
>>> > + *(.TxDecripSection)
>>> > + . = ABSOLUTE(0x30040200);
>>> > + *(.RxArraySection)
>>> > + } >SRAM_3 AT> REGION_TEXT_LOAD
>>> > +
>>>
>>> This is the wrong linker command file. This stuff should be in
>>>
>>> spec/build/bsps/arm/stm32h7/linkcmdsmemory.yml
>>>
>>> with an output section name like ".stm32h7_sram_3" and corresponding
>>> input section names. Why do you need absolute addresses here?
>>>
>>> --
>>> 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/
>>>
>>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Basic lwIP for STM32H7 BSP

[Robin Müller]

The following link contains more theoretical information about why these
sections were placed at these addresses:
https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices

Kind Regards
Robin

On Wed, 3 Feb 2021 at 14:44, Robin Müller  wrote:

> The DMA descriptors need to be placed at the start of the SRAM3 and need
> to be aligned in a certain way. The RX buffer will take up the first
> (slightly less than) 16 kB of SRAM3 but needs to be placed
> behind the DMA descriptors. It also needs to be placed in a way that the
> MPU configuration required for the DMA descriptors will not do something
> with the RX buffers.
> In the example provided by STM32, the first 256 bytes are configured by
> MPU Config.
>
> Kind Regards
> Robin
>
>
>
> On Wed, 3 Feb 2021 at 13:43, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 02/02/2021 20:10, Robin Mueller wrote:
>>
>> > + /* Not an ideal solution but required for lwIP on the STM32H7 BSP.
>> > + This places the DMA descriptors for lwIP at the start of SRAM3.
>> > + The MPU still needs to be configured for the DMA descriptor
>> regions to be
>> > + bufferable, non-cacheable, non-shareable (first 256 bytes) */
>> > + .lwip_sec_stm32h7 (NOLOAD) : ALIGN_WITH_INPUT {
>> > + . = ABSOLUTE(0x3004);
>> > + *(.RxDecripSection)
>> > + . = ABSOLUTE(0x30040060);
>> > + *(.TxDecripSection)
>> > + . = ABSOLUTE(0x30040200);
>> > + *(.RxArraySection)
>> > + } >SRAM_3 AT> REGION_TEXT_LOAD
>> > +
>>
>> This is the wrong linker command file. This stuff should be in
>>
>> spec/build/bsps/arm/stm32h7/linkcmdsmemory.yml
>>
>> with an output section name like ".stm32h7_sram_3" and corresponding
>> input section names. Why do you need absolute addresses here?
>>
>> --
>> 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/
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Basic lwIP for STM32H7 BSP

[Robin Müller]

The DMA descriptors need to be placed at the start of the SRAM3 and need to
be aligned in a certain way. The RX buffer will take up the first (slightly
less than) 16 kB of SRAM3 but needs to be placed
behind the DMA descriptors. It also needs to be placed in a way that the
MPU configuration required for the DMA descriptors will not do something
with the RX buffers.
In the example provided by STM32, the first 256 bytes are configured by MPU
Config.

Kind Regards
Robin



On Wed, 3 Feb 2021 at 13:43, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 02/02/2021 20:10, Robin Mueller wrote:
>
> > + /* Not an ideal solution but required for lwIP on the STM32H7 BSP.
> > + This places the DMA descriptors for lwIP at the start of SRAM3.
> > + The MPU still needs to be configured for the DMA descriptor
> regions to be
> > + bufferable, non-cacheable, non-shareable (first 256 bytes) */
> > + .lwip_sec_stm32h7 (NOLOAD) : ALIGN_WITH_INPUT {
> > + . = ABSOLUTE(0x3004);
> > + *(.RxDecripSection)
> > + . = ABSOLUTE(0x30040060);
> > + *(.TxDecripSection)
> > + . = ABSOLUTE(0x30040200);
> > + *(.RxArraySection)
> > + } >SRAM_3 AT> REGION_TEXT_LOAD
> > +
>
> This is the wrong linker command file. This stuff should be in
>
> spec/build/bsps/arm/stm32h7/linkcmdsmemory.yml
>
> with an output section name like ".stm32h7_sram_3" and corresponding
> input section names. Why do you need absolute addresses here?
>
> --
> 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/
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Basic lwIP for STM32H7 BSP

[Sebastian Huber]

On 02/02/2021 20:10, Robin Mueller wrote:


+   /* Not an ideal solution but required for lwIP on the STM32H7 BSP.
+   This places the DMA descriptors for lwIP at the start of SRAM3.
+   The MPU still needs to be configured for the DMA descriptor regions to 
be
+   bufferable, non-cacheable, non-shareable (first 256 bytes) */
+   .lwip_sec_stm32h7 (NOLOAD) : ALIGN_WITH_INPUT {
+   . = ABSOLUTE(0x3004);
+   *(.RxDecripSection)
+   . = ABSOLUTE(0x30040060);
+   *(.TxDecripSection)
+   . = ABSOLUTE(0x30040200);
+   *(.RxArraySection)
+   } >SRAM_3 AT> REGION_TEXT_LOAD
+


This is the wrong linker command file. This stuff should be in

spec/build/bsps/arm/stm32h7/linkcmdsmemory.yml

with an output section name like ".stm32h7_sram_3" and corresponding 
input section names. Why do you need absolute addresses here?


--
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/

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