[PATCH] Basic lwIP for STM32H7 BSP

This patch updates the BSP to have basic lwIP support. This includes a new section in the linker base file in case lwIP is used for the STM32H7 BSP. This is not an ideal solution but I have not found a better one. Other adaptions include a new option to load lwIP and disabling some preprocessor gu

Re: [PATCH] Basic lwIP for STM32H7 BSP

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 Bl

Re: [PATCH] Basic lwIP for STM32H7 BSP

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

Re: [PATCH] Basic lwIP for STM32H7 BSP

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

Re: [PATCH] Basic lwIP for STM32H7 BSP

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_sr

Re: [PATCH] Basic lwIP for STM32H7 BSP

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 {    

Re: [PATCH] Basic lwIP for STM32H7 BSP

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_AL

Re: [PATCH] Basic lwIP for STM32H7 BSP

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-

Re: [PATCH] Basic lwIP for STM32H7 BSP

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 require

Re: [PATCH] Basic lwIP for STM32H7 BSP

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 pla

Re: [PATCH] Basic lwIP for STM32H7 BSP

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 cac

Re: [PATCH] Basic lwIP for STM32H7 BSP

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 of

Re: [PATCH] Basic lwIP for STM32H7 BSP

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

Re: [PATCH] Basic lwIP for STM32H7 BSP

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

Re: [PATCH] Basic lwIP for STM32H7 BSP

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

Re: [PATCH] Basic lwIP for STM32H7 BSP

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 <

Re: [PATCH] Basic lwIP for STM32H7 BSP

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 we

Re: [PATCH] Basic lwIP for STM32H7 BSP

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 impl

Re: [PATCH] Basic lwIP for STM32H7 BSP

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 pr