[Buildroot] [RESEND PATCH 0/2] Enhance ST common folder and add new defconfig

[Buildroot] [RESEND PATCH 0/2] Enhance ST common folder and add new defconfig

[Raphael Gallais-Pou]

This commit series is a first attempt to improve the organization and
functionality of the STM32 platform in Buildroot. It comes with two
patches:

1. Reorder common ST folder:
   - Rename the common ST folder from stm32mp157 to stm32mp1xx.
   - Update references and paths in related configuration files.
   - Prepare to receive new stm32mp13 board.

2. Add new defconfig for STM32MP13:
   - Introduce a new defconfig file (stm32mp13_dk).
   - Boot following the TF-A/OP-TEE/U-Boot/Linux chain.
   - Include generic "multi_v7" defconfig for Linux configuration.

Since this is a RFC, please feel free to discuss how those changes can
be improved.

Signed-off-by: Raphael Gallais-Pou <rgallaispou@gmail.com>
---
Raphael Gallais-Pou (2):
      board/stmicroelectronics/common/stm32mp157: rename folder
      configs/stm32mp135f-dk: new defconfig

 .checkpackageignore                                |  2 +-
 DEVELOPERS                                         |  2 +-
 .../genimage.cfg.template                          |  0
 .../arm-trusted-firmware/arm-trusted-firmware.hash |  0
 .../patches/linux-headers/linux-headers.hash       |  0
 .../patches/linux/linux.hash                       |  0
 .../patches/uboot/uboot.hash                       |  0
 .../{stm32mp157 => stm32mp1xx}/post-image.sh       |  2 +-
 .../overlay/boot/extlinux/extlinux.conf            |  4 ++
 board/stmicroelectronics/stm32mp135f-dk/readme.txt | 38 ++++++++++++++
 configs/avenger96_defconfig                        |  2 +-
 configs/stm32mp135f_dk_defconfig                   | 59 ++++++++++++++++++++++
 configs/stm32mp157a_dk1_defconfig                  |  4 +-
 configs/stm32mp157c_dk2_defconfig                  |  4 +-
 14 files changed, 109 insertions(+), 8 deletions(-)
---
base-commit: a631d5b3da2db55f3209546bb6a8bf0c67924cb6
change-id: 20240729-master-3a7c9cb9c96b

Best regards,
-- 
Raphael Gallais-Pou <rgallaispou@gmail.com>

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH RESEND 1/2] board/stmicroelectronics/common/stm32mp157: rename folder

[Raphael Gallais-Pou]

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 <rgallaispou@gmail.com>
---
 .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(-)

diff --git a/.checkpackageignore b/.checkpackageignore
index 8fe4a16eb8..e1d3d8d906 100644
--- a/.checkpackageignore
+++ b/.checkpackageignore
@@ -82,7 +82,7 @@ board/solidrun/clearfog/post-build.sh Shellcheck
 board/solidrun/macchiatobin/post-build-mainline.sh Shellcheck
 board/solidrun/macchiatobin/post-build.sh Shellcheck
 board/stmicroelectronics/common/stm32f4xx/stm32-post-build.sh Shellcheck
-board/stmicroelectronics/common/stm32mp157/post-image.sh Shellcheck
+board/stmicroelectronics/common/stm32mp1xx/post-image.sh Shellcheck
 board/stmicroelectronics/stm32f429-disco/flash.sh Shellcheck
 board/stmicroelectronics/stm32f469-disco/flash_sd.sh Shellcheck
 board/stmicroelectronics/stm32f469-disco/flash_xip.sh Shellcheck
diff --git a/DEVELOPERS b/DEVELOPERS
index d7d0af3543..4a5394b596 100644
--- a/DEVELOPERS
+++ b/DEVELOPERS
@@ -2236,7 +2236,7 @@ F:	configs/qemu_riscv32_virt_defconfig
 F:	configs/qemu_riscv64_virt_defconfig
 
 N:	Marleen Vos <marleen.vos@mind.be>
-F:	board/stmicroelectronics/common/stm32mp157/
+F:	board/stmicroelectronics/common/stm32mp1xx/
 F:	configs/avenger96_defconfig
 F:	configs/stm32mp157a_dk1_defconfig
 F:	configs/stm32mp157c_dk2_defconfig
diff --git a/board/stmicroelectronics/common/stm32mp157/genimage.cfg.template b/board/stmicroelectronics/common/stm32mp1xx/genimage.cfg.template
similarity index 100%
rename from board/stmicroelectronics/common/stm32mp157/genimage.cfg.template
rename to board/stmicroelectronics/common/stm32mp1xx/genimage.cfg.template
diff --git a/board/stmicroelectronics/common/stm32mp157/patches/arm-trusted-firmware/arm-trusted-firmware.hash b/board/stmicroelectronics/common/stm32mp1xx/patches/arm-trusted-firmware/arm-trusted-firmware.hash
similarity index 100%
rename from board/stmicroelectronics/common/stm32mp157/patches/arm-trusted-firmware/arm-trusted-firmware.hash
rename to board/stmicroelectronics/common/stm32mp1xx/patches/arm-trusted-firmware/arm-trusted-firmware.hash
diff --git a/board/stmicroelectronics/common/stm32mp157/patches/linux-headers/linux-headers.hash b/board/stmicroelectronics/common/stm32mp1xx/patches/linux-headers/linux-headers.hash
similarity index 100%
rename from board/stmicroelectronics/common/stm32mp157/patches/linux-headers/linux-headers.hash
rename to board/stmicroelectronics/common/stm32mp1xx/patches/linux-headers/linux-headers.hash
diff --git a/board/stmicroelectronics/common/stm32mp157/patches/linux/linux.hash b/board/stmicroelectronics/common/stm32mp1xx/patches/linux/linux.hash
similarity index 100%
rename from board/stmicroelectronics/common/stm32mp157/patches/linux/linux.hash
rename to board/stmicroelectronics/common/stm32mp1xx/patches/linux/linux.hash
diff --git a/board/stmicroelectronics/common/stm32mp157/patches/uboot/uboot.hash b/board/stmicroelectronics/common/stm32mp1xx/patches/uboot/uboot.hash
similarity index 100%
rename from board/stmicroelectronics/common/stm32mp157/patches/uboot/uboot.hash
rename to board/stmicroelectronics/common/stm32mp1xx/patches/uboot/uboot.hash
diff --git a/board/stmicroelectronics/common/stm32mp157/post-image.sh b/board/stmicroelectronics/common/stm32mp1xx/post-image.sh
similarity index 93%
rename from board/stmicroelectronics/common/stm32mp157/post-image.sh
rename to board/stmicroelectronics/common/stm32mp1xx/post-image.sh
index 0cf52f4564..77547832ab 100755
--- a/board/stmicroelectronics/common/stm32mp157/post-image.sh
+++ b/board/stmicroelectronics/common/stm32mp1xx/post-image.sh
@@ -22,7 +22,7 @@ main()
 	GENIMAGE_CFG="$(mktemp --suffix genimage.cfg)"
 
 	sed -e "s/%ATFBIN%/${ATFBIN}/" \
-		board/stmicroelectronics/common/stm32mp157/genimage.cfg.template > ${GENIMAGE_CFG}
+		board/stmicroelectronics/common/stm32mp1xx/genimage.cfg.template > ${GENIMAGE_CFG}
 
 	support/scripts/genimage.sh -c ${GENIMAGE_CFG}
 
diff --git a/configs/avenger96_defconfig b/configs/avenger96_defconfig
index 64cfb3c2b0..3b471109f7 100644
--- a/configs/avenger96_defconfig
+++ b/configs/avenger96_defconfig
@@ -7,7 +7,7 @@ BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_6_6=y
 
 # System configuration
 BR2_ROOTFS_OVERLAY="board/arrow/avenger96/overlay/"
-BR2_ROOTFS_POST_IMAGE_SCRIPT="board/stmicroelectronics/common/stm32mp157/post-image.sh"
+BR2_ROOTFS_POST_IMAGE_SCRIPT="board/stmicroelectronics/common/stm32mp1xx/post-image.sh"
 
 # Kernel
 BR2_LINUX_KERNEL=y
diff --git a/configs/stm32mp157a_dk1_defconfig b/configs/stm32mp157a_dk1_defconfig
index 310e179cf7..e2dd48bb17 100644
--- a/configs/stm32mp157a_dk1_defconfig
+++ b/configs/stm32mp157a_dk1_defconfig
@@ -6,10 +6,10 @@ BR2_cortex_a7=y
 BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_6_9=y
 
 # System configuration
-BR2_GLOBAL_PATCH_DIR="board/stmicroelectronics/common/stm32mp157/patches"
+BR2_GLOBAL_PATCH_DIR="board/stmicroelectronics/common/stm32mp1xx/patches"
 BR2_DOWNLOAD_FORCE_CHECK_HASHES=y
 BR2_ROOTFS_OVERLAY="board/stmicroelectronics/stm32mp157a-dk1/overlay/"
-BR2_ROOTFS_POST_IMAGE_SCRIPT="board/stmicroelectronics/common/stm32mp157/post-image.sh"
+BR2_ROOTFS_POST_IMAGE_SCRIPT="board/stmicroelectronics/common/stm32mp1xx/post-image.sh"
 
 # Kernel
 BR2_LINUX_KERNEL=y
diff --git a/configs/stm32mp157c_dk2_defconfig b/configs/stm32mp157c_dk2_defconfig
index 2a9c31df37..d6085583d3 100644
--- a/configs/stm32mp157c_dk2_defconfig
+++ b/configs/stm32mp157c_dk2_defconfig
@@ -6,10 +6,10 @@ BR2_cortex_a7=y
 BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_6_9=y
 
 # System configuration
-BR2_GLOBAL_PATCH_DIR="board/stmicroelectronics/common/stm32mp157/patches"
+BR2_GLOBAL_PATCH_DIR="board/stmicroelectronics/common/stm32mp1xx/patches"
 BR2_DOWNLOAD_FORCE_CHECK_HASHES=y
 BR2_ROOTFS_OVERLAY="board/stmicroelectronics/stm32mp157c-dk2/overlay/"
-BR2_ROOTFS_POST_IMAGE_SCRIPT="board/stmicroelectronics/common/stm32mp157/post-image.sh"
+BR2_ROOTFS_POST_IMAGE_SCRIPT="board/stmicroelectronics/common/stm32mp1xx/post-image.sh"
 
 # Kernel
 BR2_LINUX_KERNEL=y

-- 
2.46.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH RESEND 2/2] configs/stm32mp135f-dk: new defconfig

[Raphael Gallais-Pou]

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 <rgallaispou@gmail.com>
---
 .../overlay/boot/extlinux/extlinux.conf            |  4 ++
 board/stmicroelectronics/stm32mp135f-dk/readme.txt | 38 ++++++++++++++
 configs/stm32mp135f_dk_defconfig                   | 59 ++++++++++++++++++++++
 3 files changed, 101 insertions(+)

diff --git a/board/stmicroelectronics/stm32mp135f-dk/overlay/boot/extlinux/extlinux.conf b/board/stmicroelectronics/stm32mp135f-dk/overlay/boot/extlinux/extlinux.conf
new file mode 100644
index 0000000000..0cc49d6a56
--- /dev/null
+++ b/board/stmicroelectronics/stm32mp135f-dk/overlay/boot/extlinux/extlinux.conf
@@ -0,0 +1,4 @@
+label stm32mp135f-dk-buildroot
+  kernel /boot/zImage
+  devicetree /boot/stm32mp135f-dk.dtb
+  append root=/dev/mmcblk0p4 rootwait
diff --git a/board/stmicroelectronics/stm32mp135f-dk/readme.txt b/board/stmicroelectronics/stm32mp135f-dk/readme.txt
new file mode 100644
index 0000000000..46879f88cf
--- /dev/null
+++ b/board/stmicroelectronics/stm32mp135f-dk/readme.txt
@@ -0,0 +1,38 @@
+STM32MP135F Discovery Kit
+
+Intro
+=====
+
+This configuration supports the STM32MP135F Discovery Kit (DK)
+platform:
+
+  https://www.st.com/en/evaluation-tools/stm32mp135f-dk.html
+
+How to build
+============
+
+ $ make stm32mp135f_dk_defconfig
+ $ make
+
+How to write the microSD card
+=============================
+
+Once the build process is finished you will have an image called
+"sdcard.img" in the output/images/ directory.
+
+Copy the bootable "sdcard.img" onto an microSD card with "dd":
+
+  $ sudo dd if=output/images/sdcard.img of=/dev/sdX
+
+Boot the board
+==============
+
+ (1) Insert the microSD card in connector CN15
+
+ (2) Plug a micro-USB cable in connector CN11 and run your serial
+     communication program on /dev/ttyACM0.
+
+ (3) Plug a USB-C cable in CN6 to power-up the board.
+
+ (4) The system will start, with the console on UART, but also visible
+     on the screen.
diff --git a/configs/stm32mp135f_dk_defconfig b/configs/stm32mp135f_dk_defconfig
new file mode 100644
index 0000000000..cc01a2bd40
--- /dev/null
+++ b/configs/stm32mp135f_dk_defconfig
@@ -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
+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"
+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
+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
+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
+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
+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
+BR2_PACKAGE_HOST_GENIMAGE=y

-- 
2.46.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH RESEND 1/2] board/stmicroelectronics/common/stm32mp157: rename folder

[Thomas Petazzoni via buildroot]

On Wed, 14 Aug 2024 20:37:02 +0200
Raphael Gallais-Pou <rgallaispou@gmail.com> wrote:

> 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 <rgallaispou@gmail.com>
> ---
>  .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(-)

Applied to next, thanks.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH RESEND 2/2] configs/stm32mp135f-dk: new defconfig

[Thomas Petazzoni via buildroot]

Hello Raphael,

On Wed, 14 Aug 2024 20:37:03 +0200
Raphael Gallais-Pou <rgallaispou@gmail.com> wrote:

> 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 <rgallaispou@gmail.com>

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.

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


> diff --git a/configs/stm32mp135f_dk_defconfig b/configs/stm32mp135f_dk_defconfig
> new file mode 100644
> index 0000000000..cc01a2bd40
> --- /dev/null
> +++ b/configs/stm32mp135f_dk_defconfig
> @@ -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
> +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?

> +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".

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

> +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
> +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
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH RESEND 2/2] configs/stm32mp135f-dk: new defconfig

[Raphaël Gallais-Pou]

Le 15/08/2024 à 10:56, Thomas Petazzoni a écrit :
> Hello Raphael,

Hi Thomas,

> 
> On Wed, 14 Aug 2024 20:37:03 +0200
> Raphael Gallais-Pou <rgallaispou@gmail.com> wrote:
> 
>> 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 <rgallaispou@gmail.com>
> 
> 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.

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

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.

> 
> 
>> diff --git a/configs/stm32mp135f_dk_defconfig b/configs/stm32mp135f_dk_defconfig
>> new file mode 100644
>> index 0000000000..cc01a2bd40
>> --- /dev/null
>> +++ b/configs/stm32mp135f_dk_defconfig
>> @@ -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
>> +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?

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 ?

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

That could also be a good idea on the mid term.

> 
>> +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".

Ack.

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

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

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

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

Thanks again,

Regards,
Raphaël

> 
> Thanks!
> 
> Thomas
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH RESEND 2/2] configs/stm32mp135f-dk: new defconfig

[Thomas Petazzoni via buildroot]

Hello Raphael,

On Sat, 17 Aug 2024 12:55:47 +0200
Raphaël Gallais-Pou <rgallaispou@gmail.com> wrote:

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

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.

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

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.


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

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.

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

> > 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
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH RESEND 2/2] configs/stm32mp135f-dk: new defconfig

[Raphaël Gallais-Pou]

Le 17/08/2024 à 14:48, Thomas Petazzoni a écrit :
> Hello Raphael,
> 
> On Sat, 17 Aug 2024 12:55:47 +0200
> Raphaël Gallais-Pou <rgallaispou@gmail.com> wrote:
> 
>>> 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.
> 
> 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.

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

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

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

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


> 
>>> 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
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH RESEND 2/2] configs/stm32mp135f-dk: new defconfig

[Raphaël Gallais-Pou]

Le 17/08/2024 à 16:33, Raphaël Gallais-Pou a écrit :
> 
> 
> Le 17/08/2024 à 14:48, Thomas Petazzoni a écrit :
>> Hello Raphael,
>>
>> On Sat, 17 Aug 2024 12:55:47 +0200
>> Raphaël Gallais-Pou <rgallaispou@gmail.com> wrote:
>>
>>>> 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.
>>
>> 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.
> 
>>
>>>> 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.
>>
>> 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.
> 
>>
>>
>>>> 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 ?
>>
>> 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.
> 
>>
>>>> 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 :-)
> 
> 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 ?
Hi Thomas,

Gentle ping on this, so I can send a v2.
I genuinely don't understand what I should do here.

Thanks in advance for your patience and explanations :-)

Regards,
Raphaël

> 
> Regards,
> Raphaël
> 
> 
>>
>>>> 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
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot