<div dir="ltr"><div><div>I think the DMA descriptors need to be 32 byte (0x20) aligned. That's the reason the example application was set up like this.<br><br></div>Kind Regards<br></div>Robin<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 3 Feb 2021 at 15:32, Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 3, 2021, 8:26 AM Robin Müller <<a href="mailto:robin.mueller.m@gmail.com" target="_blank">robin.mueller.m@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>Also, Andrei Chichak provided a very good explanation:<br><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div></blockquote></div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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?</div><div dir="auto"><br></div><div dir="auto">I think the standard linkcmds setup allows for nocache areas already.</div><div dir="auto"><br></div><div dir="auto">--joel</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>
<br></div>Kind Regards<br></div>Robin Müller<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 3 Feb 2021 at 14:50, Robin Müller <<a href="mailto:robin.mueller.m@gmail.com" rel="noreferrer" target="_blank">robin.mueller.m@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>The following link contains more theoretical information about why these sections were placed at these addresses: <a href="https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices" rel="noreferrer" target="_blank">https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices</a><br><br></div>Kind Regards<br></div>Robin<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 3 Feb 2021 at 14:44, Robin Müller <<a href="mailto:robin.mueller.m@gmail.com" rel="noreferrer" target="_blank">robin.mueller.m@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>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 <br></div>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.<br>In the example provided by STM32, the first 256 bytes are configured by MPU Config.<br><br></div><div>Kind Regards<br></div><div>Robin<br></div><div><br></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 3 Feb 2021 at 13:43, Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de" rel="noreferrer" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 02/02/2021 20:10, Robin Mueller wrote:<br>
<br>
> + /* Not an ideal solution but required for lwIP on the STM32H7 BSP.<br>
> + This places the DMA descriptors for lwIP at the start of SRAM3.<br>
> + The MPU still needs to be configured for the DMA descriptor regions to be<br>
> + bufferable, non-cacheable, non-shareable (first 256 bytes) */<br>
> + .lwip_sec_stm32h7 (NOLOAD) : ALIGN_WITH_INPUT {<br>
> + . = ABSOLUTE(0x30040000);<br>
> + *(.RxDecripSection)<br>
> + . = ABSOLUTE(0x30040060);<br>
> + *(.TxDecripSection)<br>
> + . = ABSOLUTE(0x30040200);<br>
> + *(.RxArraySection)<br>
> + } >SRAM_3 AT> REGION_TEXT_LOAD<br>
> +<br>
<br>
This is the wrong linker command file. This stuff should be in<br>
<br>
spec/build/bsps/arm/stm32h7/linkcmdsmemory.yml<br>
<br>
with an output section name like ".stm32h7_sram_3" and corresponding <br>
input section names. Why do you need absolute addresses here?<br>
<br>
-- <br>
embedded brains GmbH<br>
Herr Sebastian HUBER<br>
Dornierstr. 4<br>
82178 Puchheim<br>
Germany<br>
email: <a href="mailto:sebastian.huber@embedded-brains.de" rel="noreferrer" target="_blank">sebastian.huber@embedded-brains.de</a><br>
phone: +49-89-18 94 741 - 16<br>
fax: +49-89-18 94 741 - 08<br>
<br>
Registergericht: Amtsgericht München<br>
Registernummer: HRB 157899<br>
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler<br>
Unsere Datenschutzerklärung finden Sie hier:<br>
<a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
<br>
</blockquote></div>
</blockquote></div>
</blockquote></div>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" rel="noreferrer" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div></div>
</blockquote></div>