Re: [PATCH] STM32H743ZI Nucleo and basic lwIP support

2021-04-21 Thread Robin Müller
Actually, the configurations for GPIOA and GPIOC are completely overlapping
and could be reused to the NUCLEO BSP.

Kind Regards
Robin

On Wed, 21 Apr 2021 at 11:23, Robin Müller 
wrote:

> I'm sorry I have to dig this up and bother you again but it's something
> that i spotted when browsing the STM CubeH7 code and which is a similar
> problem to the UART3 issue and might affect NUCLEO users who would like to
> use libbsd networking.
> Similarly to the UART3, the pins for the ETH initialization seem to be
> different for the NUCLEO device.
>
> More specifically, the code for the NUCLEO-H743ZI looks like this:
>
>   /* Configure PA1, PA2 and PA7 */
>   GPIO_InitStructure.Speed = GPIO_SPEED_FREQ_HIGH;
>   GPIO_InitStructure.Mode = GPIO_MODE_AF_PP;
>   GPIO_InitStructure.Pull = GPIO_NOPULL;
>   GPIO_InitStructure.Alternate = GPIO_AF11_ETH;
>   GPIO_InitStructure.Pin = GPIO_PIN_1 | GPIO_PIN_2 | GPIO_PIN_7;
>   HAL_GPIO_Init(GPIOA, _InitStructure);
>
>   /* Configure PB13 */
>   GPIO_InitStructure.Pin = GPIO_PIN_13;
>   HAL_GPIO_Init(GPIOB, _InitStructure);
>
>   /* Configure PC1, PC4 and PC5 */
>   GPIO_InitStructure.Pin = GPIO_PIN_1 | GPIO_PIN_4 | GPIO_PIN_5;
>   HAL_GPIO_Init(GPIOC, _InitStructure);
>
>   /* Configure PG2, PG11, PG13 and PG14 */
>   GPIO_InitStructure.Pin =  GPIO_PIN_2 | GPIO_PIN_11 | GPIO_PIN_13;
>   HAL_GPIO_Init(GPIOG, _InitStructure);
>
> So instead of GPIOA 1,2 and 7, GPIOG 11, 12 and 13 and GPIOC 1, 4, 5, the
> pins above are used.
>
> KInd Regards
> Robin
>
> On Mon, 12 Apr 2021 at 11:23, Robin Müller 
> wrote:
>
>> I can split up the rest of the patch.
>> I would rename STM32H7_ADD_LWIP from the BSP configuration to
>> RTEMS_USE_LWIP as a more generic variant which could be reused for other
>> BSPs if that is okay.
>>
>> Kind Regards
>> Robin
>>
>> On Mon, 12 Apr 2021 at 10:46, Robin Müller 
>> wrote:
>>
>>> The variant worked without issues.
>>>
>>> Kind Regards
>>> Robin
>>>
>>> On Fri, 9 Apr 2021 at 09:21, Robin Müller 
>>> wrote:
>>>
 Hello Sebastian,

 I will have a look at it soon.

 Kind Regards
 Robin

 On Tue, 6 Apr 2021 at 10:01, Sebastian Huber <
 sebastian.hu...@embedded-brains.de> wrote:

> Hello Robin,
>
> sorry for the delay. I checked in some patches to add a
> "arm/nucleo-h743zi" BSP variant. Could you please check if this
> variant
> works on the board.
>
> Could you please split up the remaining pieces of the patch into
> separate commits.
>
> --
> 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

Re: [PATCH] STM32H743ZI Nucleo and basic lwIP support

2021-04-21 Thread Robin Müller
I'm sorry I have to dig this up and bother you again but it's something
that i spotted when browsing the STM CubeH7 code and which is a similar
problem to the UART3 issue and might affect NUCLEO users who would like to
use libbsd networking.
Similarly to the UART3, the pins for the ETH initialization seem to be
different for the NUCLEO device.

More specifically, the code for the NUCLEO-H743ZI looks like this:

  /* Configure PA1, PA2 and PA7 */
  GPIO_InitStructure.Speed = GPIO_SPEED_FREQ_HIGH;
  GPIO_InitStructure.Mode = GPIO_MODE_AF_PP;
  GPIO_InitStructure.Pull = GPIO_NOPULL;
  GPIO_InitStructure.Alternate = GPIO_AF11_ETH;
  GPIO_InitStructure.Pin = GPIO_PIN_1 | GPIO_PIN_2 | GPIO_PIN_7;
  HAL_GPIO_Init(GPIOA, _InitStructure);

  /* Configure PB13 */
  GPIO_InitStructure.Pin = GPIO_PIN_13;
  HAL_GPIO_Init(GPIOB, _InitStructure);

  /* Configure PC1, PC4 and PC5 */
  GPIO_InitStructure.Pin = GPIO_PIN_1 | GPIO_PIN_4 | GPIO_PIN_5;
  HAL_GPIO_Init(GPIOC, _InitStructure);

  /* Configure PG2, PG11, PG13 and PG14 */
  GPIO_InitStructure.Pin =  GPIO_PIN_2 | GPIO_PIN_11 | GPIO_PIN_13;
  HAL_GPIO_Init(GPIOG, _InitStructure);

So instead of GPIOA 1,2 and 7, GPIOG 11, 12 and 13 and GPIOC 1, 4, 5, the
pins above are used.

KInd Regards
Robin

On Mon, 12 Apr 2021 at 11:23, Robin Müller 
wrote:

> I can split up the rest of the patch.
> I would rename STM32H7_ADD_LWIP from the BSP configuration to
> RTEMS_USE_LWIP as a more generic variant which could be reused for other
> BSPs if that is okay.
>
> Kind Regards
> Robin
>
> On Mon, 12 Apr 2021 at 10:46, Robin Müller 
> wrote:
>
>> The variant worked without issues.
>>
>> Kind Regards
>> Robin
>>
>> On Fri, 9 Apr 2021 at 09:21, Robin Müller 
>> wrote:
>>
>>> Hello Sebastian,
>>>
>>> I will have a look at it soon.
>>>
>>> Kind Regards
>>> Robin
>>>
>>> On Tue, 6 Apr 2021 at 10:01, Sebastian Huber <
>>> sebastian.hu...@embedded-brains.de> wrote:
>>>
 Hello Robin,

 sorry for the delay. I checked in some patches to add a
 "arm/nucleo-h743zi" BSP variant. Could you please check if this variant
 works on the board.

 Could you please split up the remaining pieces of the patch into
 separate commits.

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

Re: [PATCH] STM32H743ZI Nucleo and basic lwIP support

2021-04-12 Thread Robin Müller
I can split up the rest of the patch.
I would rename STM32H7_ADD_LWIP from the BSP configuration to
RTEMS_USE_LWIP as a more generic variant which could be reused for other
BSPs if that is okay.

Kind Regards
Robin

On Mon, 12 Apr 2021 at 10:46, Robin Müller 
wrote:

> The variant worked without issues.
>
> Kind Regards
> Robin
>
> On Fri, 9 Apr 2021 at 09:21, Robin Müller 
> wrote:
>
>> Hello Sebastian,
>>
>> I will have a look at it soon.
>>
>> Kind Regards
>> Robin
>>
>> On Tue, 6 Apr 2021 at 10:01, Sebastian Huber <
>> sebastian.hu...@embedded-brains.de> wrote:
>>
>>> Hello Robin,
>>>
>>> sorry for the delay. I checked in some patches to add a
>>> "arm/nucleo-h743zi" BSP variant. Could you please check if this variant
>>> works on the board.
>>>
>>> Could you please split up the remaining pieces of the patch into
>>> separate commits.
>>>
>>> --
>>> 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

Re: [PATCH] STM32H743ZI Nucleo and basic lwIP support

2021-04-12 Thread Robin Müller
The variant worked without issues.

Kind Regards
Robin

On Fri, 9 Apr 2021 at 09:21, Robin Müller  wrote:

> Hello Sebastian,
>
> I will have a look at it soon.
>
> Kind Regards
> Robin
>
> On Tue, 6 Apr 2021 at 10:01, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> Hello Robin,
>>
>> sorry for the delay. I checked in some patches to add a
>> "arm/nucleo-h743zi" BSP variant. Could you please check if this variant
>> works on the board.
>>
>> Could you please split up the remaining pieces of the patch into
>> separate commits.
>>
>> --
>> 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

Re: [PATCH] STM32H743ZI Nucleo and basic lwIP support

2021-04-09 Thread Robin Müller
Hello Sebastian,

I will have a look at it soon.

Kind Regards
Robin

On Tue, 6 Apr 2021 at 10:01, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Robin,
>
> sorry for the delay. I checked in some patches to add a
> "arm/nucleo-h743zi" BSP variant. Could you please check if this variant
> works on the board.
>
> Could you please split up the remaining pieces of the patch into
> separate commits.
>
> --
> 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

Re: [PATCH] STM32H743ZI Nucleo and basic lwIP support

2021-04-06 Thread Sebastian Huber

Hello Robin,

sorry for the delay. I checked in some patches to add a 
"arm/nucleo-h743zi" BSP variant. Could you please check if this variant 
works on the board.


Could you please split up the remaining pieces of the patch into 
separate commits.


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

Re: [PATCH] STM32H743ZI Nucleo and basic lwIP support

2021-04-02 Thread Vijay Kumar Banerjee
On Fri, Apr 2, 2021 at 2:25 AM Robin Müller 
wrote:
>
> Hi Vijay,
>
> It looks interesting, but I am not really a LwIP expert. I might look
into it once I have more time in 1-2 weeks.
> I only have a BBB and the STM32H7 as test HW right now, but I guess this
is a good starting point.
That indeed is a good starting point.

> Does this mean that the lwIP repository contains the architecture
specific sources shown above? (so the DMA descriptors basically and maybe
the LAN device driver).
Yes, The architecture-specific sources (like the LAN driver) will go to the
lwip repository. The repository isn't really that well structured yet but I
would be working on getting it in shape and there's also interest from a
GSoC student, so this might come in shape with combined efforts. :)

>The lwIP support would then be built as part of the BSP?

The BSP would be built without any specific network stack. The network
stack is supposed to be built separately and then used with the BSP, which
means all the network-related drives go into respective network stacks
(lwip is one of these 3 network stacks). So far this is the plan and the
legacy network drivers have already been moved to its own separate
repository, so we'll take a similar approach for lwip as well

>And would it use the mainloop mode or the OS mode? The STM32 example I
implemented uses the mainloop mode with NO_SYS defined to 1, so I am not
familiar with the OS mode, but I guess it would make sense to use the OS
mode, porting it to RTEMS.

Yes, it would make sense to use the OS mode. I guess the NO_SYS needs to be
set to 0, which means it'll use the sys_arch definitions. We have an RTEMS
port for the sys_arch, done by Pavel Pisa. You can find it here:
https://git.rtems.org/vijay/rtems-lwip.git/tree/lwip/ports/os/rtems/arch/sys_arch.h
. It could be possible that all the drivers use this port and extend the
sys_arch module according to the requirements, but I'm not totally sure if
or how that'll work out. If each driver needs to have a separate sys_arch
file, we'll have to add it along with the drivers and find a way to select
the correct sources for the given bsp. I think that using an ini or yaml
config file to define the requirements would be a clean solution to teach
waf which modules to build.

Thank you for working on getting lwip integrated with stm32 h7. This would
be a great start for the rtems-lwip and I'm happy to work with you to get
it merged to that repository. I have also found a BBB driver for lwip and
I'll try to integrate that as well. We'll probably be able to get hardware
tests from these two boards soon. :)


Best regards,
Vijay

>
> Kind Regards
> Robin
>
>
> On Mon, 29 Mar 2021 at 22:25, Vijay Kumar Banerjee 
wrote:
>>
>> On Mon, Mar 29, 2021 at 9:52 AM Gedare Bloom  wrote:
>> >
>> > On Mon, Mar 29, 2021 at 6:17 AM Robin Mueller <
robin.muelle...@gmail.com> wrote:
>> > >
>> > > This patch adds support for the STM32H743ZI-Nucleo board
>> > > variation. This currently works by setting the STM32H743ZI_NUCLEO
>> > > flag in the config.ini flag
>> > >
>> > > It also adds basic lwIP support which can be enabled
>> > > with the flag STM32H7_ADD_LWIP. This enables certain functionalities
>> > > required for lwIP to work properly
>> > >
>> > > This patch also changes the default implementation
>> > > of HAL_GetTick to return the system tick by forwarding the call
>> > > to the respective RTEMS function.
>> > >
>> > > ---
>> > >  bsps/arm/stm32h7/console/console-usart3-cfg.c | 21 
>> > >  bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c  | 16 -
>> > >  .../stm32h7/include/Legacy/stm32_hal_legacy.h |  4 +++-
>> > >  bsps/arm/stm32h7/include/stm32h7xx_hal_conf.h | 11 -
>> > >  bsps/arm/stm32h7/include/stm32h7xx_hal_uart.h |  1 +
>> > >  bsps/arm/stm32h7/start/bspstart.c |  2 +-
>> > >  bsps/arm/stm32h7/start/stm32h7-hal-eth.c  |  3 +--
>> > >  spec/build/bsps/arm/stm32h7/bspstm32h7.yml|  4 
>> > >  spec/build/bsps/arm/stm32h7/opth743nucleo.yml | 13 ++
>> > >  spec/build/bsps/arm/stm32h7/optlwip.yml   | 24
+++
>> > >  10 files changed, 88 insertions(+), 11 deletions(-)
>> > >  create mode 100644 spec/build/bsps/arm/stm32h7/opth743nucleo.yml
>> > >  create mode 100644 spec/build/bsps/arm/stm32h7/optlwip.yml
>> > >
>> > > diff --git a/bsps/arm/stm32h7/console/console-usart3-cfg.c
b/bsps/arm/stm32h7/console/console-usart3-cfg.c
>> > > index b40f6da5aa..dc552610e1 100644
>> > > --- a/bsps/arm/stm32h7/console/console-usart3-cfg.c
>> > > +++ b/bsps/arm/stm32h7/console/console-usart3-cfg.c
>> > > @@ -25,12 +25,32 @@
>> > >   * POSSIBILITY OF SUCH DAMAGE.
>> > >   */
>> > >
>> > > +#ifdef __rtems__
>> > > +#include 
>> > > +#endif
>> > > +
>> > >  #ifdef HAVE_CONFIG_H
>> > >  #include "config.h"
>> > >  #endif
>> > >
>> > >  #include 
>> > >
>> > > +#if STM32H743ZI_NUCLEO == 1
>> > > +const stm32h7_uart_config stm32h7_usart3_config = {
>> > > +  .gpio = {
>> > > +.regs = 

Re: [PATCH] STM32H743ZI Nucleo and basic lwIP support

2021-04-02 Thread Robin Müller
 The change with void HAL_ETH_MspInit(ETH_HandleTypeDef *heth) was just
that most
other function definitions I saw were on one line so I assumed this was a
little formatting mistake. I can discard the change if this was
intentional.

I can add #ifndef __rtems__ for the section with the legacy defines as well.
Kind Regards
Robin

On Mon, 29 Mar 2021 at 17:52, Gedare Bloom  wrote:

> On Mon, Mar 29, 2021 at 6:17 AM Robin Mueller 
> wrote:
> >
> > This patch adds support for the STM32H743ZI-Nucleo board
> > variation. This currently works by setting the STM32H743ZI_NUCLEO
> > flag in the config.ini flag
> >
> > It also adds basic lwIP support which can be enabled
> > with the flag STM32H7_ADD_LWIP. This enables certain functionalities
> > required for lwIP to work properly
> >
> > This patch also changes the default implementation
> > of HAL_GetTick to return the system tick by forwarding the call
> > to the respective RTEMS function.
> >
> > ---
> >  bsps/arm/stm32h7/console/console-usart3-cfg.c | 21 
> >  bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c  | 16 -
> >  .../stm32h7/include/Legacy/stm32_hal_legacy.h |  4 +++-
> >  bsps/arm/stm32h7/include/stm32h7xx_hal_conf.h | 11 -
> >  bsps/arm/stm32h7/include/stm32h7xx_hal_uart.h |  1 +
> >  bsps/arm/stm32h7/start/bspstart.c |  2 +-
> >  bsps/arm/stm32h7/start/stm32h7-hal-eth.c  |  3 +--
> >  spec/build/bsps/arm/stm32h7/bspstm32h7.yml|  4 
> >  spec/build/bsps/arm/stm32h7/opth743nucleo.yml | 13 ++
> >  spec/build/bsps/arm/stm32h7/optlwip.yml   | 24 +++
> >  10 files changed, 88 insertions(+), 11 deletions(-)
> >  create mode 100644 spec/build/bsps/arm/stm32h7/opth743nucleo.yml
> >  create mode 100644 spec/build/bsps/arm/stm32h7/optlwip.yml
> >
> > diff --git a/bsps/arm/stm32h7/console/console-usart3-cfg.c
> b/bsps/arm/stm32h7/console/console-usart3-cfg.c
> > index b40f6da5aa..dc552610e1 100644
> > --- a/bsps/arm/stm32h7/console/console-usart3-cfg.c
> > +++ b/bsps/arm/stm32h7/console/console-usart3-cfg.c
> > @@ -25,12 +25,32 @@
> >   * POSSIBILITY OF SUCH DAMAGE.
> >   */
> >
> > +#ifdef __rtems__
> > +#include 
> > +#endif
> > +
> >  #ifdef HAVE_CONFIG_H
> >  #include "config.h"
> >  #endif
> >
> >  #include 
> >
> > +#if STM32H743ZI_NUCLEO == 1
> > +const stm32h7_uart_config stm32h7_usart3_config = {
> > +  .gpio = {
> > +.regs = GPIOD,
> > +.config = {
> > +  .Pin = GPIO_PIN_8 | GPIO_PIN_9,
> > +  .Mode = GPIO_MODE_AF_PP,
> > +  .Pull = GPIO_NOPULL,
> > +  .Speed = GPIO_SPEED_FREQ_LOW,
> > +  .Alternate = GPIO_AF7_USART3
> > +}
> > +  },
> > +  .irq = USART3_IRQn,
> > +  .device_index = 2
> > +};
> > +#else
> >  const stm32h7_uart_config stm32h7_usart3_config = {
> >.gpio = {
> >  .regs = GPIOB,
> > @@ -45,3 +65,4 @@ const stm32h7_uart_config stm32h7_usart3_config = {
> >.irq = USART3_IRQn,
> >.device_index = 2
> >  };
> > +#endif /*  STM32H743ZI_NUCLEO == 1 */
> > diff --git a/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> b/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> > index 4f2634df5b..6c3590bce8 100644
> > --- a/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> > +++ b/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> > @@ -146,6 +146,10 @@
> >  /* Includes
> --*/
> >  #include "stm32h7xx_hal.h"
> >
> > +#ifdef __rtems__
> > +#include 
> > +#endif
> > +
> >  /** @addtogroup STM32H7xx_HAL_Driver
> >* @{
> >*/
> > @@ -361,10 +365,10 @@ HAL_StatusTypeDef HAL_ETH_Init(ETH_HandleTypeDef
> *heth)
> >/*-- MAC, MTL and DMA default Configuration
> */
> >ETH_MACDMAConfig(heth);
> >
> > -#ifndef __rtems__
> > +#if STM32H7_ADD_LWIP == 1
>
> Someone else may be able to address whether we need to disable this
> stuff for 'non-lwip' builds of stm32. There is an ongoing effort to
> collect lwip drivers and lwip build as a library after building rtems,
> so maybe this will move eventually to the lwip driver repo when that
> gets into production.
>
> >/* SET DSL to 64 bit */
> >MODIFY_REG(heth->Instance->DMACCR, ETH_DMACCR_DSL,
> ETH_DMACCR_DSL_64BIT);
> > -#endif /* __rtems__ */
> > +#endif
> >
> >/* Set Receive Buffers Length (must be a multiple of 4) */
> >if ((heth->Init.RxBuffLen % 0x4U) != 0x0U)
> > @@ -2647,7 +2651,7 @@ static void
> ETH_MAC_MDIO_ClkConfig(ETH_HandleTypeDef *heth)
> >*/
> >  static void ETH_DMATxDescListInit(ETH_HandleTypeDef *heth)
> >  {
> > -#ifndef __rtems__
> > +#if STM32H7_ADD_LWIP == 1
> >ETH_DMADescTypeDef *dmatxdesc;
> >uint32_t i;
> >
> > @@ -2674,7 +2678,7 @@ static void
> ETH_DMATxDescListInit(ETH_HandleTypeDef *heth)
> >
> >/* Set Transmit Descriptor Tail pointer */
> >WRITE_REG(heth->Instance->DMACTDTPR, (uint32_t) heth->Init.TxDesc);
> > -#endif /* __rtems__ */
> > +#endif /* STM32H7_ADD_LWIP == 1 */
> >  }
> >
> >  /**
> > @@ -2686,7 +2690,7 @@ static void
> 

Re: [PATCH] STM32H743ZI Nucleo and basic lwIP support

2021-04-02 Thread Robin Müller
Hi Vijay,

It looks interesting, but I am not really a LwIP expert. I might look into
it once I have more time in 1-2 weeks.
I only have a BBB and the STM32H7 as test HW right now, but I guess this is
a good starting point.
Does this mean that the lwIP repository contains the architecture specific
sources shown above? (so the DMA descriptors basically and maybe the LAN
device driver). The lwIP support would then be built as part of the BSP?
And would it use the mainloop mode or the OS mode? The STM32 example I
implemented uses the mainloop mode with NO_SYS defined to 1, so I am not
familiar with the OS mode, but I guess it would make sense to use the OS
mode, porting it to RTEMS.

Kind Regards
Robin


On Mon, 29 Mar 2021 at 22:25, Vijay Kumar Banerjee  wrote:

> On Mon, Mar 29, 2021 at 9:52 AM Gedare Bloom  wrote:
> >
> > On Mon, Mar 29, 2021 at 6:17 AM Robin Mueller 
> wrote:
> > >
> > > This patch adds support for the STM32H743ZI-Nucleo board
> > > variation. This currently works by setting the STM32H743ZI_NUCLEO
> > > flag in the config.ini flag
> > >
> > > It also adds basic lwIP support which can be enabled
> > > with the flag STM32H7_ADD_LWIP. This enables certain functionalities
> > > required for lwIP to work properly
> > >
> > > This patch also changes the default implementation
> > > of HAL_GetTick to return the system tick by forwarding the call
> > > to the respective RTEMS function.
> > >
> > > ---
> > >  bsps/arm/stm32h7/console/console-usart3-cfg.c | 21 
> > >  bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c  | 16 -
> > >  .../stm32h7/include/Legacy/stm32_hal_legacy.h |  4 +++-
> > >  bsps/arm/stm32h7/include/stm32h7xx_hal_conf.h | 11 -
> > >  bsps/arm/stm32h7/include/stm32h7xx_hal_uart.h |  1 +
> > >  bsps/arm/stm32h7/start/bspstart.c |  2 +-
> > >  bsps/arm/stm32h7/start/stm32h7-hal-eth.c  |  3 +--
> > >  spec/build/bsps/arm/stm32h7/bspstm32h7.yml|  4 
> > >  spec/build/bsps/arm/stm32h7/opth743nucleo.yml | 13 ++
> > >  spec/build/bsps/arm/stm32h7/optlwip.yml   | 24 +++
> > >  10 files changed, 88 insertions(+), 11 deletions(-)
> > >  create mode 100644 spec/build/bsps/arm/stm32h7/opth743nucleo.yml
> > >  create mode 100644 spec/build/bsps/arm/stm32h7/optlwip.yml
> > >
> > > diff --git a/bsps/arm/stm32h7/console/console-usart3-cfg.c
> b/bsps/arm/stm32h7/console/console-usart3-cfg.c
> > > index b40f6da5aa..dc552610e1 100644
> > > --- a/bsps/arm/stm32h7/console/console-usart3-cfg.c
> > > +++ b/bsps/arm/stm32h7/console/console-usart3-cfg.c
> > > @@ -25,12 +25,32 @@
> > >   * POSSIBILITY OF SUCH DAMAGE.
> > >   */
> > >
> > > +#ifdef __rtems__
> > > +#include 
> > > +#endif
> > > +
> > >  #ifdef HAVE_CONFIG_H
> > >  #include "config.h"
> > >  #endif
> > >
> > >  #include 
> > >
> > > +#if STM32H743ZI_NUCLEO == 1
> > > +const stm32h7_uart_config stm32h7_usart3_config = {
> > > +  .gpio = {
> > > +.regs = GPIOD,
> > > +.config = {
> > > +  .Pin = GPIO_PIN_8 | GPIO_PIN_9,
> > > +  .Mode = GPIO_MODE_AF_PP,
> > > +  .Pull = GPIO_NOPULL,
> > > +  .Speed = GPIO_SPEED_FREQ_LOW,
> > > +  .Alternate = GPIO_AF7_USART3
> > > +}
> > > +  },
> > > +  .irq = USART3_IRQn,
> > > +  .device_index = 2
> > > +};
> > > +#else
> > >  const stm32h7_uart_config stm32h7_usart3_config = {
> > >.gpio = {
> > >  .regs = GPIOB,
> > > @@ -45,3 +65,4 @@ const stm32h7_uart_config stm32h7_usart3_config = {
> > >.irq = USART3_IRQn,
> > >.device_index = 2
> > >  };
> > > +#endif /*  STM32H743ZI_NUCLEO == 1 */
> > > diff --git a/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> b/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> > > index 4f2634df5b..6c3590bce8 100644
> > > --- a/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> > > +++ b/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> > > @@ -146,6 +146,10 @@
> > >  /* Includes
> --*/
> > >  #include "stm32h7xx_hal.h"
> > >
> > > +#ifdef __rtems__
> > > +#include 
> > > +#endif
> > > +
> > >  /** @addtogroup STM32H7xx_HAL_Driver
> > >* @{
> > >*/
> > > @@ -361,10 +365,10 @@ HAL_StatusTypeDef HAL_ETH_Init(ETH_HandleTypeDef
> *heth)
> > >/*-- MAC, MTL and DMA default Configuration
> */
> > >ETH_MACDMAConfig(heth);
> > >
> > > -#ifndef __rtems__
> > > +#if STM32H7_ADD_LWIP == 1
> >
> > Someone else may be able to address whether we need to disable this
> > stuff for 'non-lwip' builds of stm32. There is an ongoing effort to
> > collect lwip drivers and lwip build as a library after building rtems,
> > so maybe this will move eventually to the lwip driver repo when that
> > gets into production.
> >
> Hi,
>
> Yes, we're moving all the network stacks out of RTEMS so that a user
> can choose their preferred network stack to work with RTEMS. The LWIP
> repository is in initial state and it is gradually starting to include
> the drivers. This lwip patch would be a great 

Re: [PATCH] STM32H743ZI Nucleo and basic lwIP support

2021-03-29 Thread Vijay Kumar Banerjee
On Mon, Mar 29, 2021 at 9:52 AM Gedare Bloom  wrote:
>
> On Mon, Mar 29, 2021 at 6:17 AM Robin Mueller  
> wrote:
> >
> > This patch adds support for the STM32H743ZI-Nucleo board
> > variation. This currently works by setting the STM32H743ZI_NUCLEO
> > flag in the config.ini flag
> >
> > It also adds basic lwIP support which can be enabled
> > with the flag STM32H7_ADD_LWIP. This enables certain functionalities
> > required for lwIP to work properly
> >
> > This patch also changes the default implementation
> > of HAL_GetTick to return the system tick by forwarding the call
> > to the respective RTEMS function.
> >
> > ---
> >  bsps/arm/stm32h7/console/console-usart3-cfg.c | 21 
> >  bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c  | 16 -
> >  .../stm32h7/include/Legacy/stm32_hal_legacy.h |  4 +++-
> >  bsps/arm/stm32h7/include/stm32h7xx_hal_conf.h | 11 -
> >  bsps/arm/stm32h7/include/stm32h7xx_hal_uart.h |  1 +
> >  bsps/arm/stm32h7/start/bspstart.c |  2 +-
> >  bsps/arm/stm32h7/start/stm32h7-hal-eth.c  |  3 +--
> >  spec/build/bsps/arm/stm32h7/bspstm32h7.yml|  4 
> >  spec/build/bsps/arm/stm32h7/opth743nucleo.yml | 13 ++
> >  spec/build/bsps/arm/stm32h7/optlwip.yml   | 24 +++
> >  10 files changed, 88 insertions(+), 11 deletions(-)
> >  create mode 100644 spec/build/bsps/arm/stm32h7/opth743nucleo.yml
> >  create mode 100644 spec/build/bsps/arm/stm32h7/optlwip.yml
> >
> > diff --git a/bsps/arm/stm32h7/console/console-usart3-cfg.c 
> > b/bsps/arm/stm32h7/console/console-usart3-cfg.c
> > index b40f6da5aa..dc552610e1 100644
> > --- a/bsps/arm/stm32h7/console/console-usart3-cfg.c
> > +++ b/bsps/arm/stm32h7/console/console-usart3-cfg.c
> > @@ -25,12 +25,32 @@
> >   * POSSIBILITY OF SUCH DAMAGE.
> >   */
> >
> > +#ifdef __rtems__
> > +#include 
> > +#endif
> > +
> >  #ifdef HAVE_CONFIG_H
> >  #include "config.h"
> >  #endif
> >
> >  #include 
> >
> > +#if STM32H743ZI_NUCLEO == 1
> > +const stm32h7_uart_config stm32h7_usart3_config = {
> > +  .gpio = {
> > +.regs = GPIOD,
> > +.config = {
> > +  .Pin = GPIO_PIN_8 | GPIO_PIN_9,
> > +  .Mode = GPIO_MODE_AF_PP,
> > +  .Pull = GPIO_NOPULL,
> > +  .Speed = GPIO_SPEED_FREQ_LOW,
> > +  .Alternate = GPIO_AF7_USART3
> > +}
> > +  },
> > +  .irq = USART3_IRQn,
> > +  .device_index = 2
> > +};
> > +#else
> >  const stm32h7_uart_config stm32h7_usart3_config = {
> >.gpio = {
> >  .regs = GPIOB,
> > @@ -45,3 +65,4 @@ const stm32h7_uart_config stm32h7_usart3_config = {
> >.irq = USART3_IRQn,
> >.device_index = 2
> >  };
> > +#endif /*  STM32H743ZI_NUCLEO == 1 */
> > diff --git a/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c 
> > b/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> > index 4f2634df5b..6c3590bce8 100644
> > --- a/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> > +++ b/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> > @@ -146,6 +146,10 @@
> >  /* Includes 
> > --*/
> >  #include "stm32h7xx_hal.h"
> >
> > +#ifdef __rtems__
> > +#include 
> > +#endif
> > +
> >  /** @addtogroup STM32H7xx_HAL_Driver
> >* @{
> >*/
> > @@ -361,10 +365,10 @@ HAL_StatusTypeDef HAL_ETH_Init(ETH_HandleTypeDef 
> > *heth)
> >/*-- MAC, MTL and DMA default Configuration 
> > */
> >ETH_MACDMAConfig(heth);
> >
> > -#ifndef __rtems__
> > +#if STM32H7_ADD_LWIP == 1
>
> Someone else may be able to address whether we need to disable this
> stuff for 'non-lwip' builds of stm32. There is an ongoing effort to
> collect lwip drivers and lwip build as a library after building rtems,
> so maybe this will move eventually to the lwip driver repo when that
> gets into production.
>
Hi,

Yes, we're moving all the network stacks out of RTEMS so that a user
can choose their preferred network stack to work with RTEMS. The LWIP
repository is in initial state and it is gradually starting to include
the drivers. This lwip patch would be a great start of adding the
drivers and I'm happy to work with you to get it integrated into that
repository. Would you be interested in taking a look at it and adding
it to the rtems-lwip repository?
https://git.rtems.org/vijay/rtems-lwip.git/

Once this is in a working state, this repository will be added to
rtems top directory as official rtems-lwip.


Best regards,
Vijay
> >/* SET DSL to 64 bit */
> >MODIFY_REG(heth->Instance->DMACCR, ETH_DMACCR_DSL, ETH_DMACCR_DSL_64BIT);
> > -#endif /* __rtems__ */
> > +#endif
> >
> >/* Set Receive Buffers Length (must be a multiple of 4) */
> >if ((heth->Init.RxBuffLen % 0x4U) != 0x0U)
> > @@ -2647,7 +2651,7 @@ static void ETH_MAC_MDIO_ClkConfig(ETH_HandleTypeDef 
> > *heth)
> >*/
> >  static void ETH_DMATxDescListInit(ETH_HandleTypeDef *heth)
> >  {
> > -#ifndef __rtems__
> > +#if STM32H7_ADD_LWIP == 1
> >ETH_DMADescTypeDef *dmatxdesc;
> >uint32_t i;
> >
> > @@ -2674,7 +2678,7 @@ static void 

Re: [PATCH] STM32H743ZI Nucleo and basic lwIP support

2021-03-29 Thread Gedare Bloom
On Mon, Mar 29, 2021 at 6:17 AM Robin Mueller  wrote:
>
> This patch adds support for the STM32H743ZI-Nucleo board
> variation. This currently works by setting the STM32H743ZI_NUCLEO
> flag in the config.ini flag
>
> It also adds basic lwIP support which can be enabled
> with the flag STM32H7_ADD_LWIP. This enables certain functionalities
> required for lwIP to work properly
>
> This patch also changes the default implementation
> of HAL_GetTick to return the system tick by forwarding the call
> to the respective RTEMS function.
>
> ---
>  bsps/arm/stm32h7/console/console-usart3-cfg.c | 21 
>  bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c  | 16 -
>  .../stm32h7/include/Legacy/stm32_hal_legacy.h |  4 +++-
>  bsps/arm/stm32h7/include/stm32h7xx_hal_conf.h | 11 -
>  bsps/arm/stm32h7/include/stm32h7xx_hal_uart.h |  1 +
>  bsps/arm/stm32h7/start/bspstart.c |  2 +-
>  bsps/arm/stm32h7/start/stm32h7-hal-eth.c  |  3 +--
>  spec/build/bsps/arm/stm32h7/bspstm32h7.yml|  4 
>  spec/build/bsps/arm/stm32h7/opth743nucleo.yml | 13 ++
>  spec/build/bsps/arm/stm32h7/optlwip.yml   | 24 +++
>  10 files changed, 88 insertions(+), 11 deletions(-)
>  create mode 100644 spec/build/bsps/arm/stm32h7/opth743nucleo.yml
>  create mode 100644 spec/build/bsps/arm/stm32h7/optlwip.yml
>
> diff --git a/bsps/arm/stm32h7/console/console-usart3-cfg.c 
> b/bsps/arm/stm32h7/console/console-usart3-cfg.c
> index b40f6da5aa..dc552610e1 100644
> --- a/bsps/arm/stm32h7/console/console-usart3-cfg.c
> +++ b/bsps/arm/stm32h7/console/console-usart3-cfg.c
> @@ -25,12 +25,32 @@
>   * POSSIBILITY OF SUCH DAMAGE.
>   */
>
> +#ifdef __rtems__
> +#include 
> +#endif
> +
>  #ifdef HAVE_CONFIG_H
>  #include "config.h"
>  #endif
>
>  #include 
>
> +#if STM32H743ZI_NUCLEO == 1
> +const stm32h7_uart_config stm32h7_usart3_config = {
> +  .gpio = {
> +.regs = GPIOD,
> +.config = {
> +  .Pin = GPIO_PIN_8 | GPIO_PIN_9,
> +  .Mode = GPIO_MODE_AF_PP,
> +  .Pull = GPIO_NOPULL,
> +  .Speed = GPIO_SPEED_FREQ_LOW,
> +  .Alternate = GPIO_AF7_USART3
> +}
> +  },
> +  .irq = USART3_IRQn,
> +  .device_index = 2
> +};
> +#else
>  const stm32h7_uart_config stm32h7_usart3_config = {
>.gpio = {
>  .regs = GPIOB,
> @@ -45,3 +65,4 @@ const stm32h7_uart_config stm32h7_usart3_config = {
>.irq = USART3_IRQn,
>.device_index = 2
>  };
> +#endif /*  STM32H743ZI_NUCLEO == 1 */
> diff --git a/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c 
> b/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> index 4f2634df5b..6c3590bce8 100644
> --- a/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> +++ b/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> @@ -146,6 +146,10 @@
>  /* Includes 
> --*/
>  #include "stm32h7xx_hal.h"
>
> +#ifdef __rtems__
> +#include 
> +#endif
> +
>  /** @addtogroup STM32H7xx_HAL_Driver
>* @{
>*/
> @@ -361,10 +365,10 @@ HAL_StatusTypeDef HAL_ETH_Init(ETH_HandleTypeDef *heth)
>/*-- MAC, MTL and DMA default Configuration 
> */
>ETH_MACDMAConfig(heth);
>
> -#ifndef __rtems__
> +#if STM32H7_ADD_LWIP == 1

Someone else may be able to address whether we need to disable this
stuff for 'non-lwip' builds of stm32. There is an ongoing effort to
collect lwip drivers and lwip build as a library after building rtems,
so maybe this will move eventually to the lwip driver repo when that
gets into production.

>/* SET DSL to 64 bit */
>MODIFY_REG(heth->Instance->DMACCR, ETH_DMACCR_DSL, ETH_DMACCR_DSL_64BIT);
> -#endif /* __rtems__ */
> +#endif
>
>/* Set Receive Buffers Length (must be a multiple of 4) */
>if ((heth->Init.RxBuffLen % 0x4U) != 0x0U)
> @@ -2647,7 +2651,7 @@ static void ETH_MAC_MDIO_ClkConfig(ETH_HandleTypeDef 
> *heth)
>*/
>  static void ETH_DMATxDescListInit(ETH_HandleTypeDef *heth)
>  {
> -#ifndef __rtems__
> +#if STM32H7_ADD_LWIP == 1
>ETH_DMADescTypeDef *dmatxdesc;
>uint32_t i;
>
> @@ -2674,7 +2678,7 @@ static void ETH_DMATxDescListInit(ETH_HandleTypeDef 
> *heth)
>
>/* Set Transmit Descriptor Tail pointer */
>WRITE_REG(heth->Instance->DMACTDTPR, (uint32_t) heth->Init.TxDesc);
> -#endif /* __rtems__ */
> +#endif /* STM32H7_ADD_LWIP == 1 */
>  }
>
>  /**
> @@ -2686,7 +2690,7 @@ static void ETH_DMATxDescListInit(ETH_HandleTypeDef 
> *heth)
>*/
>  static void ETH_DMARxDescListInit(ETH_HandleTypeDef *heth)
>  {
> -#ifndef __rtems__
> +#if STM32H7_ADD_LWIP == 1
>ETH_DMADescTypeDef *dmarxdesc;
>uint32_t i;
>
> @@ -2719,7 +2723,7 @@ static void ETH_DMARxDescListInit(ETH_HandleTypeDef 
> *heth)
>
>/* Set Receive Descriptor Tail pointer Address */
>WRITE_REG(heth->Instance->DMACRDTPR, ((uint32_t)(heth->Init.RxDesc + 
> (((uint32_t)(ETH_RX_DESC_CNT - 1))*sizeof(ETH_DMADescTypeDef);
> -#endif /* __rtems__ */
> +#endif /* STM32H7_ADD_LWIP == 1 */
>  }
>
>  /**
> diff --git