date:20210128

Re: Using LwIP on the STM32H7

2021-01-28 Thread Chris Johns

On 29/1/21 12:35 am, Robin Müller wrote:
> Are there any other thinks I need to take into account for making LwIP
> work with RTEMS?

I have not used LwIP but there is an RSB package ...

https://git.rtems.org/rtems-source-builder/tree/rtems/config/net/lwip-1-1.cfg

It has a patch. I have no idea about the state of the patch or what it does.

Any updates to LwIP would be welcomed back into the project.

Thanks
Chris
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Using LwIP on the STM32H7

2021-01-28 Thread Robin Müller

Thanks for the clarifications. Now I actually understand what the
MPU_Config call from the STM32 example does. I was not sure what that was
for. I reintroduced the lwip sections (from my first mail9
again with the values from the STM32 linker script and used the MPU_Config
call from the STM32 example.
It is now not crashing anymore. I still can't receive UDP packets, but at
least I am now able to run my polling loop.

Kind Regards
Robin Müller



On Thu, 28 Jan 2021 at 18:33, Mr. Andrei Chichak  wrote:

> Good morning,
>
> I’ve been trying to get ethernet on STM32F7 going using the bsd networking
> stack (not going that well, there is a LOT of undocumented knowledge to
> straighten out).
>
>
> 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.
>
>
>
> In RTEMS it appears that I have to pull the data and lengths out of some
> mbufs (I had to look that up), and push it all into the data areas. Using
> LWiP, I think you do similar things, just pulling the data out of the pbuf
> chains.
>
> On the STM forums is an item about how to actually get a working ETH going
> on ST processors. There’s all sorts of issues including Cube generating
> code for ST’s dev boards that has the incorrect address for the PHY chip.
> Take a look at:
> https://community.st.com/s/question/0D50XBOtfhnSQB/how-to-make-ethernet-and-lwip-working-on-stm32
>
> More later,
>
> Andrei
>
>
>
> -
> Andrei Chichak
>
> Systems Developer
> CBF Systems Inc.
> 225 College Plaza
> 8215 112 Street.
> EDMONTON, ALBERTA
> T6G 2C8
> CANADA
>
> Phone: 780-628-2072
> Skype: andrei.chichak
>
>
>
>
>
>
>
>
>
>
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Using LwIP on the STM32H7

2021-01-28 Thread Mr. Andrei Chichak

Good morning,

I’ve been trying to get ethernet on STM32F7 going using the bsd networking
stack (not going that well, there is a LOT of undocumented knowledge to
straighten out).

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.

In RTEMS it appears that I have to pull the data and lengths out of some mbufs
(I had to look that up), and push it all into the data areas. Using LWiP, I
think you do similar things, just pulling the data out of the pbuf chains.

On the STM forums is an item about how to actually get a working ETH going on
ST processors. There’s all sorts of issues including Cube generating code for
ST’s dev boards that has the incorrect address for the PHY chip.
Take a look at:
https://community.st.com/s/question/0D50XBOtfhnSQB/how-to-make-ethernet-and-lwip-working-on-stm32

More later,

Andrei

-
Andrei Chichak

Systems Developer
CBF Systems Inc.
225 College Plaza
8215 112 Street.
EDMONTON, ALBERTA
T6G 2C8
CANADA

Phone: 780-628-2072
Skype: andrei.chichak

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

Re: Using LwIP on the STM32H7

2021-01-28 Thread Joel Sherrill

On Thu, Jan 28, 2021 at 10:52 AM Robin Müller 
wrote:

> By the way, the lwipopts.h from the STM32 example application appears to
> use the SRAM3 as the LWIP heap memory as well:
>
> /* Relocate the LwIP RAM heap pointer */
> #define LWIP_RAM_HEAP_POINTER(0x30044000)
>
> Might this be an issue?
>

Does that address conflict with memory RTEMS is using for stacks, heap or
workspace?
If so, this is going to crash in an odd an unpredictable way.

Can LWIP work with malloc() optionally? Or can you malloc() (aligned?) the
memory before initializing LWIP and turn that RAM_HEAP_POINTER into a
void * variable access? I doubt it is referenced much.


> I'm also not sure whether any interrupts are configured .. but I think the
> Raw API is polling based..
>
> Kind Regards
> Robin Müller
>
> On Thu, 28 Jan 2021 at 17:40, Robin Müller 
> wrote:
>
>> Okay, I managed to achieve the initialization process by adapting the BSP
>> to perform the descriptor list initialization.
>> Unfortunately, the program now appears to crash in the following polling
>> function, which is called every 100 ms:
>>
>> void ethernetif_input(struct netif *netif)
>> {
>>   err_t err;
>>   struct pbuf *p;
>>
>>   /* move received packet into a new pbuf */
>>   p = low_level_input(netif);
>>
>>   /* no packet could be read, silently ignore this */
>>   if (p == NULL) return;
>>
>>   /* entry point to the LwIP stack */
>>   err = netif->input(p, netif);
>>
>>   if (err != ERR_OK)
>>   {
>> LWIP_DEBUGF(NETIF_DEBUG, ("ethernetif_input: IP input error\n"));
>> pbuf_free(p);
>> p = NULL;
>>   }
>>
>>   HAL_ETH_BuildRxDescriptors();
>> }
>>
>> More specifically, it appears to crash in netif->input.. Is there someone
>> who has managed to make LwIP work on the STM32 with the Raw API?
>>
>> Kind Regards
>> Robin Müller
>>
>> On Thu, 28 Jan 2021 at 17:15, Robin Müller 
>> wrote:
>>
>>> Alright, I think these descriptors were not initialized inside the
>>> functions:
>>> ETH_DMATxDescListInit
>>> ETH_DMARxDescListInit
>>>
>>> because they are wrapped in preprocessor guards:
>>>
>>> static void ETH_DMATxDescListInit(ETH_HandleTypeDef *heth)
>>> {
>>> #ifndef __rtems__
>>>   ETH_DMADescTypeDef *dmatxdesc;
>>>   uint32_t i;
>>>
>>>   /* Fill each DMATxDesc descriptor with the right values */
>>>   for(i=0; i < (uint32_t)ETH_TX_DESC_CNT; i++)
>>>   {
>>> dmatxdesc = heth->Init.TxDesc + i;
>>>
>>> WRITE_REG(dmatxdesc->DESC0, 0x0);
>>> WRITE_REG(dmatxdesc->DESC1, 0x0);
>>> WRITE_REG(dmatxdesc->DESC2, 0x0);
>>> WRITE_REG(dmatxdesc->DESC3, 0x0);
>>>
>>> WRITE_REG(heth->TxDescList.TxDesc[i], (uint32_t)dmatxdesc);
>>>   }
>>>
>>>   heth->TxDescList.CurTxDesc = 0;
>>>
>>>   /* Set Transmit Descriptor Ring Length */
>>>   WRITE_REG(heth->Instance->DMACTDRLR, (ETH_TX_DESC_CNT -1));
>>>
>>>   /* Set Transmit Descriptor List Address */
>>>   WRITE_REG(heth->Instance->DMACTDLAR, (uint32_t) heth->Init.TxDesc);
>>>
>>>   /* Set Transmit Descriptor Tail pointer */
>>>   WRITE_REG(heth->Instance->DMACTDTPR, (uint32_t) heth->Init.TxDesc);
>>> #endif /* __rtems__ */
>>> }
>>>
>>> Is there a specific reason the function was excluded?
>>>
>>> Kind Regards
>>> Robin
>>>
>>> On Thu, 28 Jan 2021 at 16:47, Sebastian Huber <
>>> sebastian.hu...@embedded-brains.de> wrote:
>>>
 On 28/01/2021 16:45, Robin Müller wrote:

 >  *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.bsp_nocache*)))
 >  .bsp_nocache   0x3000 0x18c0
 >
 CMakeFiles/fsfw_example.dir/bsp_stm32_rtems/boardconfig/ethernetif.c.obj
 > 0x3000DMARxDscrTab
 > 0x3060DMATxDscrTab
 > 0x30c0Rx_Buff
 > 0x300018c0  bsp_section_nocache_end = .
 > 0x18c0  bsp_section_nocache_size =
 > (bsp_section_nocache_end - bsp_section_nocache_begin)
 >
 > But in the debugger, the descriptor entries are still zeroed out
 > unfortunately..
 If you place them in BSP_NOCACHENOLOAD_SECTION or
 BSP_NOCACHENOLOAD_SUBSECTION(), they are not loaded (zero initialized).

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

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

Re: Using LwIP on the STM32H7

2021-01-28 Thread Robin Müller

By the way, the lwipopts.h from the STM32 example application appears to
use the SRAM3 as the LWIP heap memory as well:

/* Relocate the LwIP RAM heap pointer */
#define LWIP_RAM_HEAP_POINTER(0x30044000)

Might this be an issue? I'm also not sure whether any interrupts are
configured .. but I think the Raw API is polling based..

Kind Regards
Robin Müller

On Thu, 28 Jan 2021 at 17:40, Robin Müller 
wrote:

> Okay, I managed to achieve the initialization process by adapting the BSP
> to perform the descriptor list initialization.
> Unfortunately, the program now appears to crash in the following polling
> function, which is called every 100 ms:
>
> void ethernetif_input(struct netif *netif)
> {
>   err_t err;
>   struct pbuf *p;
>
>   /* move received packet into a new pbuf */
>   p = low_level_input(netif);
>
>   /* no packet could be read, silently ignore this */
>   if (p == NULL) return;
>
>   /* entry point to the LwIP stack */
>   err = netif->input(p, netif);
>
>   if (err != ERR_OK)
>   {
> LWIP_DEBUGF(NETIF_DEBUG, ("ethernetif_input: IP input error\n"));
> pbuf_free(p);
> p = NULL;
>   }
>
>   HAL_ETH_BuildRxDescriptors();
> }
>
> More specifically, it appears to crash in netif->input.. Is there someone
> who has managed to make LwIP work on the STM32 with the Raw API?
>
> Kind Regards
> Robin Müller
>
> On Thu, 28 Jan 2021 at 17:15, Robin Müller 
> wrote:
>
>> Alright, I think these descriptors were not initialized inside the
>> functions:
>> ETH_DMATxDescListInit
>> ETH_DMARxDescListInit
>>
>> because they are wrapped in preprocessor guards:
>>
>> static void ETH_DMATxDescListInit(ETH_HandleTypeDef *heth)
>> {
>> #ifndef __rtems__
>>   ETH_DMADescTypeDef *dmatxdesc;
>>   uint32_t i;
>>
>>   /* Fill each DMATxDesc descriptor with the right values */
>>   for(i=0; i < (uint32_t)ETH_TX_DESC_CNT; i++)
>>   {
>> dmatxdesc = heth->Init.TxDesc + i;
>>
>> WRITE_REG(dmatxdesc->DESC0, 0x0);
>> WRITE_REG(dmatxdesc->DESC1, 0x0);
>> WRITE_REG(dmatxdesc->DESC2, 0x0);
>> WRITE_REG(dmatxdesc->DESC3, 0x0);
>>
>> WRITE_REG(heth->TxDescList.TxDesc[i], (uint32_t)dmatxdesc);
>>   }
>>
>>   heth->TxDescList.CurTxDesc = 0;
>>
>>   /* Set Transmit Descriptor Ring Length */
>>   WRITE_REG(heth->Instance->DMACTDRLR, (ETH_TX_DESC_CNT -1));
>>
>>   /* Set Transmit Descriptor List Address */
>>   WRITE_REG(heth->Instance->DMACTDLAR, (uint32_t) heth->Init.TxDesc);
>>
>>   /* Set Transmit Descriptor Tail pointer */
>>   WRITE_REG(heth->Instance->DMACTDTPR, (uint32_t) heth->Init.TxDesc);
>> #endif /* __rtems__ */
>> }
>>
>> Is there a specific reason the function was excluded?
>>
>> Kind Regards
>> Robin
>>
>> On Thu, 28 Jan 2021 at 16:47, Sebastian Huber <
>> sebastian.hu...@embedded-brains.de> wrote:
>>
>>> On 28/01/2021 16:45, Robin Müller wrote:
>>>
>>> >  *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.bsp_nocache*)))
>>> >  .bsp_nocache   0x3000 0x18c0
>>> >
>>> CMakeFiles/fsfw_example.dir/bsp_stm32_rtems/boardconfig/ethernetif.c.obj
>>> > 0x3000DMARxDscrTab
>>> > 0x3060DMATxDscrTab
>>> > 0x30c0Rx_Buff
>>> > 0x300018c0  bsp_section_nocache_end = .
>>> > 0x18c0  bsp_section_nocache_size =
>>> > (bsp_section_nocache_end - bsp_section_nocache_begin)
>>> >
>>> > But in the debugger, the descriptor entries are still zeroed out
>>> > unfortunately..
>>> If you place them in BSP_NOCACHENOLOAD_SECTION or
>>> BSP_NOCACHENOLOAD_SUBSECTION(), they are not loaded (zero initialized).
>>>
>>> --
>>> 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/
>>>
>>>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Using LwIP on the STM32H7

2021-01-28 Thread Robin Müller

Okay, I managed to achieve the initialization process by adapting the BSP
to perform the descriptor list initialization.
Unfortunately, the program now appears to crash in the following polling
function, which is called every 100 ms:

void ethernetif_input(struct netif *netif)
{
  err_t err;
  struct pbuf *p;

  /* move received packet into a new pbuf */
  p = low_level_input(netif);

  /* no packet could be read, silently ignore this */
  if (p == NULL) return;

  /* entry point to the LwIP stack */
  err = netif->input(p, netif);

  if (err != ERR_OK)
  {
LWIP_DEBUGF(NETIF_DEBUG, ("ethernetif_input: IP input error\n"));
pbuf_free(p);
p = NULL;
  }

  HAL_ETH_BuildRxDescriptors();
}

More specifically, it appears to crash in netif->input.. Is there someone
who has managed to make LwIP work on the STM32 with the Raw API?

Kind Regards
Robin Müller

On Thu, 28 Jan 2021 at 17:15, Robin Müller 
wrote:

> Alright, I think these descriptors were not initialized inside the
> functions:
> ETH_DMATxDescListInit
> ETH_DMARxDescListInit
>
> because they are wrapped in preprocessor guards:
>
> static void ETH_DMATxDescListInit(ETH_HandleTypeDef *heth)
> {
> #ifndef __rtems__
>   ETH_DMADescTypeDef *dmatxdesc;
>   uint32_t i;
>
>   /* Fill each DMATxDesc descriptor with the right values */
>   for(i=0; i < (uint32_t)ETH_TX_DESC_CNT; i++)
>   {
> dmatxdesc = heth->Init.TxDesc + i;
>
> WRITE_REG(dmatxdesc->DESC0, 0x0);
> WRITE_REG(dmatxdesc->DESC1, 0x0);
> WRITE_REG(dmatxdesc->DESC2, 0x0);
> WRITE_REG(dmatxdesc->DESC3, 0x0);
>
> WRITE_REG(heth->TxDescList.TxDesc[i], (uint32_t)dmatxdesc);
>   }
>
>   heth->TxDescList.CurTxDesc = 0;
>
>   /* Set Transmit Descriptor Ring Length */
>   WRITE_REG(heth->Instance->DMACTDRLR, (ETH_TX_DESC_CNT -1));
>
>   /* Set Transmit Descriptor List Address */
>   WRITE_REG(heth->Instance->DMACTDLAR, (uint32_t) heth->Init.TxDesc);
>
>   /* Set Transmit Descriptor Tail pointer */
>   WRITE_REG(heth->Instance->DMACTDTPR, (uint32_t) heth->Init.TxDesc);
> #endif /* __rtems__ */
> }
>
> Is there a specific reason the function was excluded?
>
> Kind Regards
> Robin
>
> On Thu, 28 Jan 2021 at 16:47, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 28/01/2021 16:45, Robin Müller wrote:
>>
>> >  *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.bsp_nocache*)))
>> >  .bsp_nocache   0x3000 0x18c0
>> > CMakeFiles/fsfw_example.dir/bsp_stm32_rtems/boardconfig/ethernetif.c.obj
>> > 0x3000DMARxDscrTab
>> > 0x3060DMATxDscrTab
>> > 0x30c0Rx_Buff
>> > 0x300018c0  bsp_section_nocache_end = .
>> > 0x18c0  bsp_section_nocache_size =
>> > (bsp_section_nocache_end - bsp_section_nocache_begin)
>> >
>> > But in the debugger, the descriptor entries are still zeroed out
>> > unfortunately..
>> If you place them in BSP_NOCACHENOLOAD_SECTION or
>> BSP_NOCACHENOLOAD_SUBSECTION(), they are not loaded (zero initialized).
>>
>> --
>> 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/
>>
>>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Using LwIP on the STM32H7

2021-01-28 Thread Robin Müller

Alright, I think these descriptors were not initialized inside the
functions:
ETH_DMATxDescListInit
ETH_DMARxDescListInit

because they are wrapped in preprocessor guards:

static void ETH_DMATxDescListInit(ETH_HandleTypeDef *heth)
{
#ifndef __rtems__
  ETH_DMADescTypeDef *dmatxdesc;
  uint32_t i;

  /* Fill each DMATxDesc descriptor with the right values */
  for(i=0; i < (uint32_t)ETH_TX_DESC_CNT; i++)
  {
dmatxdesc = heth->Init.TxDesc + i;

WRITE_REG(dmatxdesc->DESC0, 0x0);
WRITE_REG(dmatxdesc->DESC1, 0x0);
WRITE_REG(dmatxdesc->DESC2, 0x0);
WRITE_REG(dmatxdesc->DESC3, 0x0);

WRITE_REG(heth->TxDescList.TxDesc[i], (uint32_t)dmatxdesc);
  }

  heth->TxDescList.CurTxDesc = 0;

  /* Set Transmit Descriptor Ring Length */
  WRITE_REG(heth->Instance->DMACTDRLR, (ETH_TX_DESC_CNT -1));

  /* Set Transmit Descriptor List Address */
  WRITE_REG(heth->Instance->DMACTDLAR, (uint32_t) heth->Init.TxDesc);

  /* Set Transmit Descriptor Tail pointer */
  WRITE_REG(heth->Instance->DMACTDTPR, (uint32_t) heth->Init.TxDesc);
#endif /* __rtems__ */
}

Is there a specific reason the function was excluded?

Kind Regards
Robin

On Thu, 28 Jan 2021 at 16:47, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 28/01/2021 16:45, Robin Müller wrote:
>
> >  *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.bsp_nocache*)))
> >  .bsp_nocache   0x3000 0x18c0
> > CMakeFiles/fsfw_example.dir/bsp_stm32_rtems/boardconfig/ethernetif.c.obj
> > 0x3000DMARxDscrTab
> > 0x3060DMATxDscrTab
> > 0x30c0Rx_Buff
> > 0x300018c0  bsp_section_nocache_end = .
> > 0x18c0  bsp_section_nocache_size =
> > (bsp_section_nocache_end - bsp_section_nocache_begin)
> >
> > But in the debugger, the descriptor entries are still zeroed out
> > unfortunately..
> If you place them in BSP_NOCACHENOLOAD_SECTION or
> BSP_NOCACHENOLOAD_SUBSECTION(), they are not loaded (zero initialized).
>
> --
> 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/
>
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Using LwIP on the STM32H7

2021-01-28 Thread Sebastian Huber


On 28/01/2021 16:45, Robin Müller wrote:


 *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.bsp_nocache*)))
 .bsp_nocache   0x3000     0x18c0 
CMakeFiles/fsfw_example.dir/bsp_stm32_rtems/boardconfig/ethernetif.c.obj

                0x3000                DMARxDscrTab
                0x3060                DMATxDscrTab
                0x30c0                Rx_Buff
                0x300018c0  bsp_section_nocache_end = .
                0x18c0  bsp_section_nocache_size = 
(bsp_section_nocache_end - bsp_section_nocache_begin)


But in the debugger, the descriptor entries are still zeroed out 
unfortunately..
If you place them in BSP_NOCACHENOLOAD_SECTION or 
BSP_NOCACHENOLOAD_SUBSECTION(), they are not loaded (zero initialized).


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

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

Re: Using LwIP on the STM32H7

2021-01-28 Thread Robin Müller

Thanks Sebastian.

The descriptors now appear to have addresses inside the RAM according to
the map file

 *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.bsp_nocache*)))
 .bsp_nocache   0x3000 0x18c0
CMakeFiles/fsfw_example.dir/bsp_stm32_rtems/boardconfig/ethernetif.c.obj
0x3000DMARxDscrTab
0x3060DMATxDscrTab
0x30c0Rx_Buff
0x300018c0bsp_section_nocache_end =
.
0x18c0bsp_section_nocache_size
= (bsp_section_nocache_end - bsp_section_nocache_begin)

But in the debugger, the descriptor entries are still zeroed out
unfortunately..

Kind Regards
Robin Müller

On Thu, 28 Jan 2021 at 16:39, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 28/01/2021 14:35, Robin Müller wrote:
>
> > So far, transferring the code has worked, but there are some specific
> > sections in the code used for our FreeRTOS example which put the
> > ethernet DMA descriptors in specific sections:
> >
> > ETH_DMADescTypeDef DMARxDscrTab[ETH_RX_DESC_CNT]
> > __attribute__((section(".RxDecripSection"))); /* Ethernet Rx DMA
> > Descriptors */
> > ETH_DMADescTypeDef DMATxDscrTab[ETH_TX_DESC_CNT]
> > __attribute__((section(".TxDecripSection")));   /* Ethernet Tx DMA
> > Descriptors */
> > uint8_t Rx_Buff[ETH_RX_DESC_CNT][ETH_RX_BUFFER_SIZE]
> > __attribute__((section(".RxArraySection"))); /* Ethernet Receive
> > Buffers */
>
> The BSP has a nocache section, see
>
> bsps/arm/include/bsp/linker-symbols.h
>
> --
> 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/
>
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Using LwIP on the STM32H7

2021-01-28 Thread Sebastian Huber


On 28/01/2021 14:35, Robin Müller wrote:

So far, transferring the code has worked, but there are some specific 
sections in the code used for our FreeRTOS example which put the 
ethernet DMA descriptors in specific sections:


ETH_DMADescTypeDef DMARxDscrTab[ETH_RX_DESC_CNT] 
__attribute__((section(".RxDecripSection"))); /* Ethernet Rx DMA 
Descriptors */
ETH_DMADescTypeDef DMATxDscrTab[ETH_TX_DESC_CNT] 
__attribute__((section(".TxDecripSection")));   /* Ethernet Tx DMA 
Descriptors */
uint8_t Rx_Buff[ETH_RX_DESC_CNT][ETH_RX_BUFFER_SIZE] 
__attribute__((section(".RxArraySection"))); /* Ethernet Receive 
Buffers */


The BSP has a nocache section, see

bsps/arm/include/bsp/linker-symbols.h

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

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

Re: Using LwIP on the STM32H7

2021-01-28 Thread Joel Sherrill

Specific addresses shouldn't be in the shared linkcmds.base.

You could define new macro names like the other memory types and addresses
and add those to the generic linkcmds. Then the linkcmds.base would
generically know those sections and your BSP could set the right macros to
place it.

One thought is to add linkcmds.lwip which have those special sections (if
they are common in LWIP -- not driver specific), and then have the BSP
define the right things and then include linkcmds.lwip and linkcmds.base.
That way BSPs which want to potentially use lwip could include the lwip
linkcmds fragment and get the sections.

But if those section names are driver specific, this isn't a good
organization and we will have to think more.

Hope that makes sense.

--joel

On Thu, Jan 28, 2021 at 7:37 AM Robin Müller 
wrote:

> Some clarification: The linker script used for RTEMS is of course the
> default RTEMS linker script, the FreeRTOS example used the linker file
> taken from the STM32CubeH7 repository.
>
> Kind Regards
> Robin Müller
>
> On Thu, 28 Jan 2021 at 14:35, Robin Müller 
> wrote:
>
>> Hi,
>>
>> I am trying to get LwIP working on the STM32H7 because it has a low RAM
>> usage (at least that's what I heard). We already did this for FreeRTOS, but
>> we used the LwIP Raw API to not be bound specifically to the OS. I am now
>> trying to adapt LwIP to RTEMS , but I'm not really a LwIP expert and most
>> did copy & paste up until now.
>>
>> So far, transferring the code has worked, but there are some specific
>> sections in the code used for our FreeRTOS example which put the ethernet
>> DMA descriptors in specific sections:
>>
>> ETH_DMADescTypeDef DMARxDscrTab[ETH_RX_DESC_CNT]
>> __attribute__((section(".RxDecripSection"))); /* Ethernet Rx DMA
>> Descriptors */
>> ETH_DMADescTypeDef DMATxDscrTab[ETH_TX_DESC_CNT]
>> __attribute__((section(".TxDecripSection")));   /* Ethernet Tx DMA
>> Descriptors */
>> uint8_t Rx_Buff[ETH_RX_DESC_CNT][ETH_RX_BUFFER_SIZE]
>> __attribute__((section(".RxArraySection"))); /* Ethernet Receive Buffers */
>>
>> /* For RTEMS can we put this in the text section? */
>> //ETH_DMADescTypeDef DMARxDscrTab[ETH_RX_DESC_CNT]; /* Ethernet Rx DMA
>> Descriptors */
>> //ETH_DMADescTypeDef DMATxDscrTab[ETH_TX_DESC_CNT];   /* Ethernet Tx DMA
>> Descriptors */
>> //uint8_t Rx_Buff[ETH_RX_DESC_CNT][ETH_RX_BUFFER_SIZE]; /* Ethernet
>> Receive Buffers */
>>
>> I got an "section `.unexpected_sections' will not fit in region
>> *   `UNEXPECTED_SECTIONS'" error because of this. I checked the linker
>> script used, which was taken from the STM32CubeH7 repository and found this
>> LwIP specific section:
>>
>>   .lwip_sec (NOLOAD) : {
>> . = ABSOLUTE(0x3004);
>> *(.RxDecripSection)
>>
>> . = ABSOLUTE(0x30040060);
>> *(.TxDecripSection)
>>
>> . = ABSOLUTE(0x30040200);
>> *(.RxArraySection)
>>   } >RAM_D2 AT> FLASH
>>
>> So the descriptors are placed at RAM_D2 (or SRAM_3 in RTEMS). I've placed
>> the following
>> section in linkcmds.base now:
>>
>> .lwip_sec (NOLOAD) : ALIGN_WITH_INPUT {
>> . = ABSOLUTE(0x3004);
>> *(.RxDecripSection)
>>
>> . = ABSOLUTE(0x30040060);
>> *(.TxDecripSection)
>>
>> . = ABSOLUTE(0x30040200);
>>*(.RxArraySection)
>>   } >SRAM_3 AT> REGION_TEXT_LOAD
>>
>> Are any STM32 or LwIP experts here that see a problem with this adaption?
>> I still need to do some other stuff to integrate LwIP properly so I haven't
>> tested it yet. Are there any other thinks I need to take into account for
>> making LwIP work with RTEMS?
>>
>> Kind Regards
>> Robin
>>
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Using LwIP on the STM32H7

2021-01-28 Thread Robin Müller

Some clarification: The linker script used for RTEMS is of course the
default RTEMS linker script, the FreeRTOS example used the linker file
taken from the STM32CubeH7 repository.

Kind Regards
Robin Müller

On Thu, 28 Jan 2021 at 14:35, Robin Müller 
wrote:

> Hi,
>
> I am trying to get LwIP working on the STM32H7 because it has a low RAM
> usage (at least that's what I heard). We already did this for FreeRTOS, but
> we used the LwIP Raw API to not be bound specifically to the OS. I am now
> trying to adapt LwIP to RTEMS , but I'm not really a LwIP expert and most
> did copy & paste up until now.
>
> So far, transferring the code has worked, but there are some specific
> sections in the code used for our FreeRTOS example which put the ethernet
> DMA descriptors in specific sections:
>
> ETH_DMADescTypeDef DMARxDscrTab[ETH_RX_DESC_CNT]
> __attribute__((section(".RxDecripSection"))); /* Ethernet Rx DMA
> Descriptors */
> ETH_DMADescTypeDef DMATxDscrTab[ETH_TX_DESC_CNT]
> __attribute__((section(".TxDecripSection")));   /* Ethernet Tx DMA
> Descriptors */
> uint8_t Rx_Buff[ETH_RX_DESC_CNT][ETH_RX_BUFFER_SIZE]
> __attribute__((section(".RxArraySection"))); /* Ethernet Receive Buffers */
>
> /* For RTEMS can we put this in the text section? */
> //ETH_DMADescTypeDef DMARxDscrTab[ETH_RX_DESC_CNT]; /* Ethernet Rx DMA
> Descriptors */
> //ETH_DMADescTypeDef DMATxDscrTab[ETH_TX_DESC_CNT];   /* Ethernet Tx DMA
> Descriptors */
> //uint8_t Rx_Buff[ETH_RX_DESC_CNT][ETH_RX_BUFFER_SIZE]; /* Ethernet
> Receive Buffers */
>
> I got an "section `.unexpected_sections' will not fit in region
> *   `UNEXPECTED_SECTIONS'" error because of this. I checked the linker
> script used, which was taken from the STM32CubeH7 repository and found this
> LwIP specific section:
>
>   .lwip_sec (NOLOAD) : {
> . = ABSOLUTE(0x3004);
> *(.RxDecripSection)
>
> . = ABSOLUTE(0x30040060);
> *(.TxDecripSection)
>
> . = ABSOLUTE(0x30040200);
> *(.RxArraySection)
>   } >RAM_D2 AT> FLASH
>
> So the descriptors are placed at RAM_D2 (or SRAM_3 in RTEMS). I've placed
> the following
> section in linkcmds.base now:
>
> .lwip_sec (NOLOAD) : ALIGN_WITH_INPUT {
> . = ABSOLUTE(0x3004);
> *(.RxDecripSection)
>
> . = ABSOLUTE(0x30040060);
> *(.TxDecripSection)
>
> . = ABSOLUTE(0x30040200);
>*(.RxArraySection)
>   } >SRAM_3 AT> REGION_TEXT_LOAD
>
> Are any STM32 or LwIP experts here that see a problem with this adaption?
> I still need to do some other stuff to integrate LwIP properly so I haven't
> tested it yet. Are there any other thinks I need to take into account for
> making LwIP work with RTEMS?
>
> Kind Regards
> Robin
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Using LwIP on the STM32H7

2021-01-28 Thread Robin Müller

Hi,

I am trying to get LwIP working on the STM32H7 because it has a low RAM
usage (at least that's what I heard). We already did this for FreeRTOS, but
we used the LwIP Raw API to not be bound specifically to the OS. I am now
trying to adapt LwIP to RTEMS , but I'm not really a LwIP expert and most
did copy & paste up until now.

So far, transferring the code has worked, but there are some specific
sections in the code used for our FreeRTOS example which put the ethernet
DMA descriptors in specific sections:

ETH_DMADescTypeDef DMARxDscrTab[ETH_RX_DESC_CNT]
__attribute__((section(".RxDecripSection"))); /* Ethernet Rx DMA
Descriptors */
ETH_DMADescTypeDef DMATxDscrTab[ETH_TX_DESC_CNT]
__attribute__((section(".TxDecripSection")));   /* Ethernet Tx DMA
Descriptors */
uint8_t Rx_Buff[ETH_RX_DESC_CNT][ETH_RX_BUFFER_SIZE]
__attribute__((section(".RxArraySection"))); /* Ethernet Receive Buffers */

/* For RTEMS can we put this in the text section? */
//ETH_DMADescTypeDef DMARxDscrTab[ETH_RX_DESC_CNT]; /* Ethernet Rx DMA
Descriptors */
//ETH_DMADescTypeDef DMATxDscrTab[ETH_TX_DESC_CNT];   /* Ethernet Tx DMA
Descriptors */
//uint8_t Rx_Buff[ETH_RX_DESC_CNT][ETH_RX_BUFFER_SIZE]; /* Ethernet Receive
Buffers */

I got an "section `.unexpected_sections' will not fit in region
*   `UNEXPECTED_SECTIONS'" error because of this. I checked the linker
script used, which was taken from the STM32CubeH7 repository and found this
LwIP specific section:

  .lwip_sec (NOLOAD) : {
. = ABSOLUTE(0x3004);
*(.RxDecripSection)

. = ABSOLUTE(0x30040060);
*(.TxDecripSection)

. = ABSOLUTE(0x30040200);
*(.RxArraySection)
  } >RAM_D2 AT> FLASH

So the descriptors are placed at RAM_D2 (or SRAM_3 in RTEMS). I've placed
the following
section in linkcmds.base now:

.lwip_sec (NOLOAD) : ALIGN_WITH_INPUT {
. = ABSOLUTE(0x3004);
*(.RxDecripSection)

. = ABSOLUTE(0x30040060);
*(.TxDecripSection)

. = ABSOLUTE(0x30040200);
   *(.RxArraySection)
  } >SRAM_3 AT> REGION_TEXT_LOAD

Are any STM32 or LwIP experts here that see a problem with this adaption? I
still need to do some other stuff to integrate LwIP properly so I haven't
tested it yet. Are there any other thinks I need to take into account for
making LwIP work with RTEMS?

Kind Regards
Robin
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Using LwIP on the STM32H7

Re: Using LwIP on the STM32H7

Re: Using LwIP on the STM32H7

Re: Using LwIP on the STM32H7

Re: Using LwIP on the STM32H7

Re: Using LwIP on the STM32H7

Re: Using LwIP on the STM32H7

Re: Using LwIP on the STM32H7

Re: Using LwIP on the STM32H7

Re: Using LwIP on the STM32H7

Re: Using LwIP on the STM32H7

Re: Using LwIP on the STM32H7

Using LwIP on the STM32H7

13 matches

Site Navigation

Mail list logo

Footer information