Topics

make menuconfig for STM32MP157 activating STM32Cube ?

friedtj@...
 

This answered the question: adding a Kconfig with the STM32Cube modules
solved the issue, without including objects in the CMakeLists.txt despite
having STM32Cube in $ZEPHYR_BASE/../modules/hal/stm32/stm32cube.

Thank you, Jean-Michel

----- Mail original -----
De: "Erwan Gouriou" <erwan.gouriou@...>
À: friedtj@...
Cc: "devel" <devel@...>
Envoyé: Mardi 18 Février 2020 08:56:39
Objet: Re: [Zephyr-devel] make menuconfig for STM32MP157 activating STM32Cube ?


Hi,


Can you check following readme section and see if it answers your point?


https://github.com/zephyrproject-rtos/hal_stm32/blob/master/README.rst#use-stm32cube-in-your-application



Cheers
Erwan

Le sam. 15 févr. 2020 à 17:45, < friedtj@... > a écrit :


I am building https://github.com/STMicroelectronics/logicanalyser (RPMSG
and VirtIO example for the STM32MP157 using OpenAMP) for Zephyr and have been
facing the issue of linking with the STM32Cube library functions.

I am using the external arm-none-eabi-gcc compilation toolchain under
Debian/GNU Linux with
export ZEPHYR_TOOLCHAIN_VARIANT=cross-compile
export CROSS_COMPILE=/usr/bin/arm-none-eabi-

The tree structure I have (west init && cd zephyr && west update)
has created modules/hal/stm32/stm32cube/ at the same level than zephyr.

This ST example relies heavily on the STM32Cube framework I had to link with.
I achieved a functional result by adding in my CMakeLists.txt the following statement

target_sources(app PRIVATE src/main.c src/rpmsg_hdr.c src/openamp.c src/mbox_ipcc.c src/rsc_table.c src/copro_sync.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_dma.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_gpio.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_rcc_ex.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_ipcc.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_cortex.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_tim_ex.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_pwr.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_tim.c)

following the advice I read at
https://github.com/intel/zephyr/tree/master/ext/hal/st/stm32cube
stating

"Plus add HAL driver file (when needed):
obj-$(CONFIG_SERIAL_HAS_DRIVER) += stm32yyxx/drivers/src/stm32yyxx_hal_uart.o"

This is most probably *not* the right way and hence my question to this list:
if I wish to activate these functions in STM32Cube, make menuconfig in the build directory
shows
-*- <HAS_STM32CUBE>
in red, but then all other subsystems (eg - - <USE_STM32_HAL_DMA> or
- - <USE_STM32_HAL_IPCC>) which I believe would fill the cmake configuration
file properly are disabled and cannot be enabled. I fail to understand what
option prevents me from activating these functionalities.

Could anyone explain what I am doing wrong in this configuration ?

Thank you, Jean-Michel

Arnaud POULIQUEN
 

Hi,

Regarding your link : https://github.com/intel/zephyr/tree/master/ext/hal/st/stm32cube

Seems that you don't point to the good zephyr project
Please refer to https://github.com/zephyrproject-rtos for the code
Stm32cube HALs are available here: https://github.com/zephyrproject-rtos/hal_stm32/tree/master/stm32cube

If you want an example of OpenAMP implementation for stm32mp1 : https://github.com/zephyrproject-rtos/zephyr/pull/16985

Regards,
Arnaud

-----Original Message-----
From: devel@... <devel@...> On
Behalf Of friedtj@...
Sent: samedi 15 février 2020 17:00
To: devel@...
Subject: [Zephyr-devel] make menuconfig for STM32MP157 activating
STM32Cube ?

I am building https://github.com/STMicroelectronics/logicanalyser (RPMSG
and VirtIO example for the STM32MP157 using OpenAMP) for Zephyr and
have been facing the issue of linking with the STM32Cube library functions.

I am using the external arm-none-eabi-gcc compilation toolchain under
Debian/GNU Linux with export ZEPHYR_TOOLCHAIN_VARIANT=cross-
compile
export CROSS_COMPILE=/usr/bin/arm-none-eabi-

The tree structure I have (west init && cd zephyr && west update) has
created modules/hal/stm32/stm32cube/ at the same level than zephyr.

This ST example relies heavily on the STM32Cube framework I had to link
with.
I achieved a functional result by adding in my CMakeLists.txt the following
statement

target_sources(app PRIVATE src/main.c src/rpmsg_hdr.c src/openamp.c
src/mbox_ipcc.c src/rsc_table.c src/copro_sync.c
$ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/driver
s/src/stm32mp1xx_hal_dma.c
$ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/driver
s/src/stm32mp1xx_hal_gpio.c
$ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/driver
s/src/stm32mp1xx_hal_rcc_ex.c
$ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/driver
s/src/stm32mp1xx_hal_ipcc.c
$ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/driver
s/src/stm32mp1xx_hal_cortex.c
$ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/driver
s/src/stm32mp1xx_hal_tim_ex.c
$ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/driver
s/src/stm32mp1xx_hal_pwr.c
$ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/driver
s/src/stm32mp1xx_hal_tim.c)

following the advice I read at
https://github.com/intel/zephyr/tree/master/ext/hal/st/stm32cube
stating

"Plus add HAL driver file (when needed):
obj-$(CONFIG_SERIAL_HAS_DRIVER) +=
stm32yyxx/drivers/src/stm32yyxx_hal_uart.o"

This is most probably *not* the right way and hence my question to this list:
if I wish to activate these functions in STM32Cube, make menuconfig in the
build directory shows
-*- <HAS_STM32CUBE>
in red, but then all other subsystems (eg - - <USE_STM32_HAL_DMA> or
- - <USE_STM32_HAL_IPCC>) which I believe would fill the cmake
configuration file properly are disabled and cannot be enabled. I fail to
understand what option prevents me from activating these functionalities.

Could anyone explain what I am doing wrong in this configuration ?

Thank you, Jean-Michel

Erwan Gouriou
 

Hi,

Can you check following readme section and see if it answers your point?


Cheers
Erwan

Le sam. 15 févr. 2020 à 17:45, <friedtj@...> a écrit :
I am building https://github.com/STMicroelectronics/logicanalyser (RPMSG
and VirtIO example for the STM32MP157 using OpenAMP) for Zephyr and have been
facing the issue of linking with the STM32Cube library functions.

I am using the external arm-none-eabi-gcc compilation toolchain under
Debian/GNU Linux with
export ZEPHYR_TOOLCHAIN_VARIANT=cross-compile
export CROSS_COMPILE=/usr/bin/arm-none-eabi-

The tree structure I have (west init && cd zephyr && west update)
has created modules/hal/stm32/stm32cube/ at the same level than zephyr.

This ST example relies heavily on the STM32Cube framework I had to link with.
I achieved a functional result by adding in my CMakeLists.txt the following statement

target_sources(app PRIVATE src/main.c src/rpmsg_hdr.c src/openamp.c src/mbox_ipcc.c src/rsc_table.c src/copro_sync.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_dma.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_gpio.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_rcc_ex.c  $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_ipcc.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_cortex.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_tim_ex.c  $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_pwr.c  $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_tim.c)

following the advice I read at
https://github.com/intel/zephyr/tree/master/ext/hal/st/stm32cube
stating

"Plus add HAL driver file (when needed):
obj-$(CONFIG_SERIAL_HAS_DRIVER) += stm32yyxx/drivers/src/stm32yyxx_hal_uart.o"

This is most probably *not* the right way and hence my question to this list:
if I wish to activate these functions in STM32Cube, make menuconfig in the build directory
shows
-*- <HAS_STM32CUBE>
in red, but then all other subsystems (eg - - <USE_STM32_HAL_DMA> or
- - <USE_STM32_HAL_IPCC>) which I believe would fill the cmake configuration
file properly are disabled and cannot be enabled. I fail to understand what
option prevents me from activating these functionalities.

Could anyone explain what I am doing wrong in this configuration ?

Thank you, Jean-Michel



friedtj@...
 

I am building https://github.com/STMicroelectronics/logicanalyser (RPMSG
and VirtIO example for the STM32MP157 using OpenAMP) for Zephyr and have been
facing the issue of linking with the STM32Cube library functions.

I am using the external arm-none-eabi-gcc compilation toolchain under
Debian/GNU Linux with
export ZEPHYR_TOOLCHAIN_VARIANT=cross-compile
export CROSS_COMPILE=/usr/bin/arm-none-eabi-

The tree structure I have (west init && cd zephyr && west update)
has created modules/hal/stm32/stm32cube/ at the same level than zephyr.

This ST example relies heavily on the STM32Cube framework I had to link with.
I achieved a functional result by adding in my CMakeLists.txt the following statement

target_sources(app PRIVATE src/main.c src/rpmsg_hdr.c src/openamp.c src/mbox_ipcc.c src/rsc_table.c src/copro_sync.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_dma.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_gpio.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_rcc_ex.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_ipcc.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_cortex.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_tim_ex.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_pwr.c $ENV{ZEPHYR_BASE}/../modules/hal/stm32/stm32cube/stm32mp1xx/drivers/src/stm32mp1xx_hal_tim.c)

following the advice I read at
https://github.com/intel/zephyr/tree/master/ext/hal/st/stm32cube
stating

"Plus add HAL driver file (when needed):
obj-$(CONFIG_SERIAL_HAS_DRIVER) += stm32yyxx/drivers/src/stm32yyxx_hal_uart.o"

This is most probably *not* the right way and hence my question to this list:
if I wish to activate these functions in STM32Cube, make menuconfig in the build directory
shows
-*- <HAS_STM32CUBE>
in red, but then all other subsystems (eg - - <USE_STM32_HAL_DMA> or
- - <USE_STM32_HAL_IPCC>) which I believe would fill the cmake configuration
file properly are disabled and cannot be enabled. I fail to understand what
option prevents me from activating these functionalities.

Could anyone explain what I am doing wrong in this configuration ?

Thank you, Jean-Michel