Enhance ST common folder and add new defconfig

STM32MP15x and STM32MP13 can use almost of the same configuration regarding bootloaders and the Linux kernel. To make profit of the commont folder, rename it to 'stm32mp1xx' and change dependencies accordingly.

Signed-off-by Raphael Gallais-Pou <[email protected]>

---
 .checkpackageignore                                                   | 2 +-
 DEVELOPERS                                                            | 2 +-
 .../common/{stm32mp157 => stm32mp1xx}/genimage.cfg.template           | 0
 .../patches/arm-trusted-firmware/arm-trusted-firmware.hash            | 0
 .../patches/linux-headers/linux-headers.hash                          | 0
 .../common/{stm32mp157 => stm32mp1xx}/patches/linux/linux.hash        | 0
 .../common/{stm32mp157 => stm32mp1xx}/patches/uboot/uboot.hash        | 0
 .../common/{stm32mp157 => stm32mp1xx}/post-image.sh                   | 2 +-
 configs/avenger96_defconfig                                           | 2 +-
 configs/stm32mp157a_dk1_defconfig                                     | 4 ++--
 configs/stm32mp157c_dk2_defconfig                                     | 4 ++--
 11 files changed, 8 insertions(+), 8 deletions(-)

Add new defconfig for STMicroelectronics board STM32MP135F-DK.

STM32MP135F-DK features can be found here:
https://www.st.com/en/evaluation-tools/stm32mp135f-dk.html

Signed-off-by Raphael Gallais-Pou <[email protected]>

---
 .../overlay/boot/extlinux/extlinux.conf            |  4 ++
 board/stmicroelectronics/stm32mp135f-dk/readme.txt | 38 ++++++++++++++
 configs/stm32mp135f_dk_defconfig                   | 59 ++++++++++++++++++++++
 3 files changed, 101 insertions(+)

configs/stm32mp135f_dk_defconfig new file +7 -0

new file mode 100644
index 0000000000..cc01a2bd40
@@ -0,0 +1,59 @@
+# Architecture
+BR2_arm=y
+BR2_cortex_a7=y
+
+# Linux headers same as kernel, a 6.9 series
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_6_9=y
+

configs/stm32mp135f_dk_defconfig new file +10 -0

+BR2_PACKAGE_OPTEE_CLIENT=y
+BR2_TARGET_ROOTFS_EXT2=y
+BR2_TARGET_ROOTFS_EXT2_4=y
+BR2_TARGET_ROOTFS_EXT2_SIZE="120M"
+# BR2_TARGET_ROOTFS_TAR is not set
+
+# Bootloaders
+BR2_TARGET_ARM_TRUSTED_FIRMWARE=y
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_VERSION=y
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_VERSION_VALUE="v2.9"

configs/stm32mp135f_dk_defconfig new file +5 -0

+BR2_TARGET_OPTEE_OS_PLATFORM="stm32mp1"
+BR2_TARGET_OPTEE_OS_PLATFORM_FLAVOR="135F_DK"
+BR2_TARGET_UBOOT=y
+BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y
+BR2_TARGET_UBOOT_CUSTOM_VERSION=y

Hello Raphael,

Quoted 2 lines · On Wed, 14 Aug 2024 20:37:03 +0200 Raphael Gallais-Pou <[email protected]>…

Add new defconfig for STMicroelectronics board STM32MP135F-DK.

Quoted 4 lines

STM32MP135F-DK features can be found here:

   https://www.st.com/en/evaluation-tools/stm32mp135f-dk.html

Signed-off-by Raphael Gallais-Pou <[email protected]>

Thanks for the resend, but there was no need to resend: your previous patch was still in our queue of patches to review/merge. I have a number of comments below.

Quoted 6 lines

---
  .../overlay/boot/extlinux/extlinux.conf            |  4 ++
  board/stmicroelectronics/stm32mp135f-dk/readme.txt | 38 ++++++++++++++
  configs/stm32mp135f_dk_defconfig                   | 59 ++++++++++++++++++++++
  3 files changed, 101 insertions(+)

First of all, you need to enable BR2_DOWNLOAD_FORCE_CHECK_HASHES=y, which requires adding:

BR2_GLOBAL_PATCH_DIR="board/stmicroelectronics/stm32mp135f-dk/patches/"

and then run ./utils/add-custom-hashes, which will automatically populate this folder.

Quoted 21 lines

configs/stm32mp135f_dk_defconfig new file +13 -0

new file mode 100644
index 0000000000..cc01a2bd40
@@ -0,0 +1,59 @@
+# Architecture
+BR2_arm=y
+BR2_cortex_a7=y
+
+# Linux headers same as kernel, a 6.9 series
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_6_9=y
+
+# System configuration
+BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV=y
+BR2_ROOTFS_OVERLAY="board/stmicroelectronics/stm32mp135f-dk/overlay"
+BR2_ROOTFS_POST_IMAGE_SCRIPT="board/stmicroelectronics/common/stm32mp1xx/post-image.sh"
+
+# Kernel

configs/stm32mp135f_dk_defconfig line 17

Quoted 4 lines

configs/stm32mp135f_dk_defconfig new file +4 -0

+BR2_LINUX_KERNEL=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="6.9.8"
+BR2_LINUX_KERNEL_DEFCONFIG="multi_v7"

I see on STM32MP157, we're using some custom kernel configuration files, with presumably a more "optimized" configuration than multi_v7. Should we do the same here?

Or maybe we should even have a single common kernel config file for all STM32MP1 platforms?

configs/stm32mp135f_dk_defconfig line 23

Quoted 7 lines

configs/stm32mp135f_dk_defconfig new file +6 -0

+BR2_LINUX_KERNEL_DTS_SUPPORT=y
+BR2_LINUX_KERNEL_INTREE_DTS_NAME="st/stm32mp135f-dk"
+BR2_LINUX_KERNEL_INSTALL_TARGET=y
+
+# Filesystem
+BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=y

Please group this with the Linux kernel options above, this is not "filesystem related".

Quoted 16 lines

configs/stm32mp135f_dk_defconfig new file +15 -0

+BR2_PACKAGE_OPTEE_CLIENT=y
+BR2_TARGET_ROOTFS_EXT2=y
+BR2_TARGET_ROOTFS_EXT2_4=y
+BR2_TARGET_ROOTFS_EXT2_SIZE="120M"
+# BR2_TARGET_ROOTFS_TAR is not set
+
+# Bootloaders
+BR2_TARGET_ARM_TRUSTED_FIRMWARE=y
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_VERSION=y
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_VERSION_VALUE="v2.9"
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_PLATFORM="stm32mp1"
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_FIP=y
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL31=y
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL32_OPTEE=y
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_UBOOT_AS_BL33=y

configs/stm32mp135f_dk_defconfig line 43

Quoted 5 lines

configs/stm32mp135f_dk_defconfig new file +5 -0

+BR2_TARGET_ARM_TRUSTED_FIRMWARE_UBOOT_BL33_IMAGE="u-boot-nodtb.bin"
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_ADDITIONAL_VARIABLES="STM32MP_SDMMC=1 DTB_FILE_NAME=stm32mp135f-dk.dtb E=0 BL33_CFG=$(BINARIES_DIR)/u-boot.dtb"
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_IMAGES="fip.bin *.stm32"
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_NEEDS_DTC=y
+BR2_TARGET_OPTEE_OS=y

Please use the "custom" version mechanism to specify the exact version of OP-TEE to be used, like you did for TF-A, Linux and U-Boot.

Quoted 11 lines

configs/stm32mp135f_dk_defconfig new file +10 -0

+BR2_TARGET_OPTEE_OS_PLATFORM="stm32mp1"
+BR2_TARGET_OPTEE_OS_PLATFORM_FLAVOR="135F_DK"
+BR2_TARGET_UBOOT=y
+BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y
+BR2_TARGET_UBOOT_CUSTOM_VERSION=y
+BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2024.07"
+BR2_TARGET_UBOOT_BOARD_DEFCONFIG="stm32mp13"
+BR2_TARGET_UBOOT_NEEDS_PYLIBFDT=y
+# BR2_TARGET_UBOOT_FORMAT_BIN is not set
+BR2_TARGET_UBOOT_FORMAT_CUSTOM=y

configs/stm32mp135f_dk_defconfig line 58

Quoted 5 lines

configs/stm32mp135f_dk_defconfig new file +5 -0

+BR2_TARGET_UBOOT_FORMAT_CUSTOM_NAME="u-boot-nodtb.bin u-boot.dtb"
+BR2_TARGET_UBOOT_CUSTOM_MAKEOPTS="DEVICE_TREE=stm32mp135f-dk"
+
+# Additional tools
+BR2_PACKAGE_HOST_BMAP_TOOLS=y

Please drop, we don't enable bmap-tools in our defconfigs, we leave that choice up to the user.

Thanks!

Thomas

Quoted 3 lines

Thanks for the resend, but there was no need to resend: your previous patch was still in our queue of patches to review/merge. I have a number of comments below.

Sorry for the inconvenience. I had no news of the patchset which led me to resend it. Thanks for taking the time to review this one and merge the preview.

Quoted 7 lines

First of all, you need to enable BR2_DOWNLOAD_FORCE_CHECK_HASHES=y, which requires adding:

BR2_GLOBAL_PATCH_DIR="board/stmicroelectronics/stm32mp135f-dk/patches/"

and then run ./utils/add-custom-hashes, which will automatically populate this folder.

For this one I think that it will be better to set the directory as the same of the common directory, eg. "board/stmicroelectronics/common/stm32mp1xx/patches/". So that the versions between TF-A/U-Boot, the Linux kernel as well as OP-TEE, if it is activated in the future for the other platforms, will be synced between all stm32mp1* platforms.

Quoted 3 lines

I see on STM32MP157, we're using some custom kernel configuration files, with presumably a more "optimized" configuration than multi_v7. Should we do the same here?

Effectively this reduces the overall kernel size. My thought on this would be to set the general multi_v7 kernel defconfig on the initial stm32mp13 support, and fine tune after. Because there is many hardware differences between stm32mp15 and stm32mp13 platforms (for example there is no audio jack in my knowledge), I feel like this would take quite some time for me to sort every drivers.

What do you think about this process ?

Quoted 2 lines

Please use the "custom" version mechanism to specify the exact version of OP-TEE to be used, like you did for TF-A, Linux and U-Boot.

Ack, forgot about that one. I saw that there was no "custom version" option, like there is for U-Boot and the Kernel. And greping through the other defconfig there is no hardcoded versions. Maybe this can be a idea for the future. For now I will set a custom tarball pointing to the official 4.3.0 tarball. Would this be okay ?

cf. https://github.com/OP-TEE/optee_os/archive/refs/tags/4.3.0.tar.gz

Quoted 2 lines

Please drop, we don't enable bmap-tools in our defconfigs, we leave that choice up to the user.

Ack. Mind that I will leave the BR2_PACKAGE_HOST_GENIMAGE=y option since it is mandatory for building the image.

Hello Raphael,

Quoted 4 lines · On Sat, 17 Aug 2024 12:55:47 +0200 Raphaël Gallais-Pou <[email protected]>…

Quoted 3 lines

Thanks for the resend, but there was no need to resend: your previous patch was still in our queue of patches to review/merge. I have a number of comments below.

Quoted 3 lines

Sorry for the inconvenience. I had no news of the patchset which led me to resend it. Thanks for taking the time to review this one and merge the preview.

Patches are never forgotten: they are tracked under patchwork as soon as they are posted on the mailing list. If you have no news, you can ping on the patch series if you want, but resending without any changes isn't very useful.

Quoted 9 lines

Quoted 8 lines

First of all, you need to enable BR2_DOWNLOAD_FORCE_CHECK_HASHES=y, which requires adding:

BR2_GLOBAL_PATCH_DIR="board/stmicroelectronics/stm32mp135f-dk/patches/"

and then run ./utils/add-custom-hashes, which will automatically populate this folder.

Quoted 6 lines

For this one I think that it will be better to set the directory as the same of the common directory, eg. "board/stmicroelectronics/common/stm32mp1xx/patches/". So that the versions between TF-A/U-Boot, the Linux kernel as well as OP-TEE, if it is activated in the future for the other platforms, will be synced between all stm32mp1* platforms.

But then it means that all the stm32mp1 defconfigs must be updated in sync whenever Linux, U-Boot, TF-A or OP-TEE are bumped.

Quoted 6 lines

Quoted 5 lines

I see on STM32MP157, we're using some custom kernel configuration files, with presumably a more "optimized" configuration than multi_v7. Should we do the same here?

Quoted 8 lines

Effectively this reduces the overall kernel size. My thought on this would be to set the general multi_v7 kernel defconfig on the initial stm32mp13 support, and fine tune after. Because there is many hardware differences between stm32mp15 and stm32mp13 platforms (for example there is no audio jack in my knowledge), I feel like this would take quite some time for me to sort every drivers.

What do you think about this process ?

Why not, but since we'll have a single common kernel config for all, this story of "not having audio jack on STM32MP13" is not very relevant. I.e, what not just use the existing kernel configuration used for MP15 also for MP13, and just add what's missing in this common configuration? We're also not trying to make the super super optimized kernel configuration with only strictly what's needed. But multi_v7 is massively bloated.

Quoted 11 lines

Quoted 3 lines

Please use the "custom" version mechanism to specify the exact version of OP-TEE to be used, like you did for TF-A, Linux and U-Boot.

Ack, forgot about that one. I saw that there was no "custom version" option, like there is for U-Boot and the Kernel. And greping through the other defconfig there is no hardcoded versions. Maybe this can be a idea for the future. For now I will set a custom tarball pointing to the official 4.3.0 tarball. Would this be okay ?

cf. https://github.com/OP-TEE/optee_os/archive/refs/tags/4.3.0.tar.gz

Well, there is definitely a custom version for OP-TEE, like there is for Linux and U-Boot:

choice
prompt "OP-TEE OS version"
default BR2_TARGET_OPTEE_OS_LATEST if BR2_PACKAGE_HOST_RUSTC_ARCH_SUPPORTS help
Select the version of OP-TEE OS you want to use

config BR2_TARGET_OPTEE_OS_LATEST
bool "4.3.0"
depends on BR2_PACKAGE_HOST_RUSTC_ARCH_SUPPORTS select BR2_TARGET_OPTEE_OS_NEEDS_PYTHON_CRYPTOGRAPHY help
Use the latest release tag from the OP-TEE OS official Git repository.

config BR2_TARGET_OPTEE_OS_CUSTOM_TARBALL
bool "Custom tarball"
help
This option allows to specify a URL pointing to an OP-TEE OS source tarball. This URL can use any protocol recognized by Buildroot, like http://, ftp://, file:// or scp://.

When pointing to a local tarball using file://, you may want to use a make variable like $(TOPDIR) to reference the root of the Buildroot tree.

config BR2_TARGET_OPTEE_OS_CUSTOM_GIT
bool "Custom Git repository"
help
Use a custom version fetched from a Git repository.

endchoice

So do the same as what you do for Linux and U-Boot :-)

Quoted 4 lines

Quoted 3 lines

Please drop, we don't enable bmap-tools in our defconfigs, we leave that choice up to the user.

Quoted 2 lines

Ack. Mind that I will leave the BR2_PACKAGE_HOST_GENIMAGE=y option since it is mandatory for building the image.

Absolutely!

Thanks a lot!

Thomas

Le 17/08/2024 à 14:48, Thomas Petazzoni a écrit :

Quoted 9 lines

Hello Raphael,

Quoted 4 lines · On Sat, 17 Aug 2024 12:55:47 +0200 Raphaël Gallais-Pou <[email protected]>…

Quoted 3 lines

Thanks for the resend, but there was no need to resend: your previous patch was still in our queue of patches to review/merge. I have a number of comments below.

Quoted 8 lines

Quoted 3 lines

Sorry for the inconvenience. I had no news of the patchset which led me to resend it. Thanks for taking the time to review this one and merge the preview.

Patches are never forgotten: they are tracked under patchwork as soon as they are posted on the mailing list. If you have no news, you can ping on the patch series if you want, but resending without any changes isn't very useful.

Understood. I will ping if I encounter this situation again. Thank you for your clarification.

Quoted 16 lines

Quoted 9 lines

Quoted 8 lines

First of all, you need to enable BR2_DOWNLOAD_FORCE_CHECK_HASHES=y, which requires adding:

BR2_GLOBAL_PATCH_DIR="board/stmicroelectronics/stm32mp135f-dk/patches/"

and then run ./utils/add-custom-hashes, which will automatically populate this folder.

Quoted 6 lines

For this one I think that it will be better to set the directory as the same of the common directory, eg. "board/stmicroelectronics/common/stm32mp1xx/patches/". So that the versions between TF-A/U-Boot, the Linux kernel as well as OP-TEE, if it is activated in the future for the other platforms, will be synced between all stm32mp1* platforms.

Quoted 2 lines

But then it means that all the stm32mp1 defconfigs must be updated in sync whenever Linux, U-Boot, TF-A or OP-TEE are bumped.

Yes, indeed.

Since stm32mp157c-dk2, stm32mp157a-dk1 and stm32mp135f-dk are pretty much the same product line, I figured that would be easier to tie their component versions together. That would be easier to maintain IMHO.

Quoted 15 lines

Quoted 6 lines

Quoted 5 lines

I see on STM32MP157, we're using some custom kernel configuration files, with presumably a more "optimized" configuration than multi_v7. Should we do the same here?

Quoted 8 lines

Effectively this reduces the overall kernel size. My thought on this would be to set the general multi_v7 kernel defconfig on the initial stm32mp13 support, and fine tune after. Because there is many hardware differences between stm32mp15 and stm32mp13 platforms (for example there is no audio jack in my knowledge), I feel like this would take quite some time for me to sort every drivers.

What do you think about this process ?

Quoted 7 lines

Why not, but since we'll have a single common kernel config for all, this story of "not having audio jack on STM32MP13" is not very relevant. I.e, what not just use the existing kernel configuration used for MP15 also for MP13, and just add what's missing in this common configuration? We're also not trying to make the super super optimized kernel configuration with only strictly what's needed. But multi_v7 is massively bloated.

I absolutely agree. I will use the mp15 then, and do some checking with mp13. If some drivers were missed, they will be added as we go along.

Quoted 45 lines

Quoted 11 lines

Quoted 3 lines

Please use the "custom" version mechanism to specify the exact version of OP-TEE to be used, like you did for TF-A, Linux and U-Boot.

Ack, forgot about that one. I saw that there was no "custom version" option, like there is for U-Boot and the Kernel. And greping through the other defconfig there is no hardcoded versions. Maybe this can be a idea for the future. For now I will set a custom tarball pointing to the official 4.3.0 tarball. Would this be okay ?

cf. https://github.com/OP-TEE/optee_os/archive/refs/tags/4.3.0.tar.gz

Well, there is definitely a custom version for OP-TEE, like there is for Linux and U-Boot:

choice
         prompt "OP-TEE OS version"
         default BR2_TARGET_OPTEE_OS_LATEST if BR2_PACKAGE_HOST_RUSTC_ARCH_SUPPORTS help
           Select the version of OP-TEE OS you want to use

config BR2_TARGET_OPTEE_OS_LATEST
         bool "4.3.0"
         depends on BR2_PACKAGE_HOST_RUSTC_ARCH_SUPPORTS select BR2_TARGET_OPTEE_OS_NEEDS_PYTHON_CRYPTOGRAPHY help
           Use the latest release tag from the OP-TEE OS official Git repository.

config BR2_TARGET_OPTEE_OS_CUSTOM_TARBALL
         bool "Custom tarball"
         help
           This option allows to specify a URL pointing to an OP-TEE OS source tarball. This URL can use any protocol recognized by Buildroot, like http://, ftp://, file:// or scp://.

           When pointing to a local tarball using file://, you may want to use a make variable like $(TOPDIR) to reference the root of the Buildroot tree.

config BR2_TARGET_OPTEE_OS_CUSTOM_GIT
         bool "Custom Git repository"
         help
           Use a custom version fetched from a Git repository.

Quoted 3 lines

endchoice

So do the same as what you do for Linux and U-Boot :-)

Sorry, I am confused. The option set to hardcode the versions for Linux and U-Boot on stm32mp15* is something like BR2_XXX_CUSTOM_VERSION_VALUE. This does not appear for OP-TEE in the code shown above, which leave us with either the custom tarball or custom git repository methods.

Am I missing something ?

Regards,
Raphaël

Quoted 12 lines

Quoted 6 lines

Quoted 3 lines

Please drop, we don't enable bmap-tools in our defconfigs, we leave that choice up to the user.

Ack. Mind that I will leave the BR2_PACKAGE_HOST_GENIMAGE=y option since it is mandatory for building the image.

Absolutely!

Thanks a lot!

Thomas