[PATCH] Basic lwIP for STM32H7 BSP

[Joel Sherrill]

On Wed, Feb 3, 2021, 8:26 AM Robin Müller <robin.mueller.m at 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.mueller.m at 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.mueller.m at 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.huber at 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.huber at 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 at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210203/776ec7b5/attachment-0001.html>