On Wed, Feb 3, 2021, 8:26 AM Robin Müller <robin.muelle...@gmail.com> 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 <robin.muelle...@gmail.com> > 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 <robin.muelle...@gmail.com> >> 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(0x30040000); >>>> > + *(.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
