[meta-arm,4/6] arm: trusted-firmware-m: Add recipe

Submitted by Gabor Abonyi on June 22, 2020, 7:13 a.m. | Patch ID: 173757

Details

Message ID 20200622071401.2570-5-gabor.abonyi@arm.com
State Superseded
Headers show

Commit Message

Gabor Abonyi June 22, 2020, 7:13 a.m.
Adds a recipe to pull down the trusted-firmware-m repository and the
ones it depends on. The recipe can either use gcc-arm-none-eabi-native
or armcompiler-native Clang toolchain to compile the firmware.

Change-Id: I37a4ba38982b5b1d387eccbb26bb5c79bddab0f7
Signed-off-by: Gabor Abonyi <gabor.abonyi@arm.com>
---
 meta-arm/conf/layer.conf                      |   1 +
 .../trusted-firmware-m/trusted-firmware-m.inc | 118 ++++++++++++++++++
 .../trusted-firmware-m_1.0.bb                 |  25 ++++
 3 files changed, 144 insertions(+)
 create mode 100644 meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m.inc
 create mode 100644 meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m_1.0.bb

Patch hide | download patch | download mbox

diff --git a/meta-arm/conf/layer.conf b/meta-arm/conf/layer.conf
index 3341972..10a7951 100644
--- a/meta-arm/conf/layer.conf
+++ b/meta-arm/conf/layer.conf
@@ -11,5 +11,6 @@  BBFILE_PRIORITY_meta-arm = "6"
 
 LAYERDEPENDS_meta-arm = " \
     core \
+    arm-toolchain \
 "
 LAYERSERIES_COMPAT_meta-arm = "warrior zeus dunfell"
diff --git a/meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m.inc b/meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m.inc
new file mode 100644
index 0000000..a7c4319
--- /dev/null
+++ b/meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m.inc
@@ -0,0 +1,118 @@ 
+# SPDX-License-Identifier: MIT
+#
+# Copyright (c) 2020 Arm Limited
+#
+
+SUMMARY = "Trusted Firmware for Cortex-M"
+DESCRIPTION = "Trusted Firmware-M"
+HOMEPAGE = "https://git.trustedfirmware.org/trusted-firmware-m.git"
+PROVIDES = "virtual/trusted-firmware-m"
+
+inherit python3native cmake deploy
+
+TFM_DEPENDS ?= ""
+DEPENDS += "${TFM_DEPENDS}"
+DEPENDS += "python3-cryptography-native python3-pyasn1-native"
+DEPENDS += "python3-jinja2-native python3-cbor-native python3-pyyaml-native"
+
+S = "${WORKDIR}/git/tfm"
+# Sub-directory in which to build.
+BUILD_DIR = "cmake_build"
+B = "${S}/${BUILD_DIR}"
+
+COMPATIBLE_MACHINE ?= "invalid"
+
+# Build for debug (set TFA_DEBUG to 1 to activate)
+TFM_DEBUG ?= "0"
+# Set target config
+TFM_CONFIG ?= "ConfigDefault.cmake"
+# Platform must be set for each machine
+TFM_PLATFORM ?= "invalid"
+
+# Uncomment, or copy these lines to your local.conf to use the Arm Clang compiler
+# from meta-arm-toolchain.
+# Please make sure to check the applicable license beforehand!
+#LICENSE_FLAGS_WHITELIST = "commercial_armcompiler-native"
+#TFM_COMPILER = "ARMCLANG"
+# Uncomment the line below to use the license from your host machine:
+#inherit armcompiler-host-license
+# Otherwise you have to set and export the following variables manually.
+# ARM_DS_DEFAULT_TOOLKIT_KEY, ARMLMD_LICENSE_FILE, LM_LICENSE_FILE
+
+# Setting GCC as the default TF-M compiler
+TFM_COMPILER ?= "GNUARM"
+DEPENDS += "${@'armcompiler-native' if d.getVar('TFM_COMPILER', True) == 'ARMCLANG' else 'gcc-arm-none-eabi-native'}"
+
+# Add platform parameters
+EXTRA_OECMAKE += "-DTARGET_PLATFORM=${TFM_PLATFORM}"
+
+# Add compiler parameters
+EXTRA_OECMAKE += "-DCOMPILER=${TFM_COMPILER}"
+
+# Handle TFM_DEBUG parameter
+EXTRA_OECMAKE += "${@bb.utils.contains('TFM_DEBUG', '1', '-DCMAKE_BUILD_TYPE=Debug', '', d)}"
+EXTRA_OECMAKE += "-DPROJ_CONFIG=${S}/configs/${TFM_CONFIG}"
+
+# Let the Makefile handle setting up the CFLAGS and LDFLAGS as it is a standalone application
+CFLAGS[unexport] = "1"
+LDFLAGS[unexport] = "1"
+AS[unexport] = "1"
+LD[unexport] = "1"
+
+# This is needed because CMSIS_5 source package originally has .pack extension not .zip
+# and bitbake checks this dependency based on file extension
+do_unpack[depends] += "unzip-native:do_populate_sysroot"
+
+do_configure[prefuncs] += "do_check_config"
+do_check_config() {
+    if [ ! -f "${S}/configs/${TFM_CONFIG}" ]; then
+        bbfatal "Couldn't find config file '${TFM_CONFIG}' in '${S}/configs/'"
+    fi
+}
+
+do_configure() {
+    cd ${S}
+    python3 "tools/tfm_parse_manifest_list.py"
+
+    if [ ! -d "${B}" ]
+    then
+        install -d ${B}
+    else
+        rm -f ${B}/CMakeCache.txt
+    fi
+
+    cd ${B}
+    cmake -G"Unix Makefiles" --build ${S} ${EXTRA_OECMAKE}
+}
+
+do_compile() {
+    if [ -d "${B}" ]
+    then
+        oe_runmake -C ${B} install
+    else
+        bbfatal "TF-M CMake not generated!"
+    fi
+}
+
+do_install() {
+    if [ ! -d "${B}/install/outputs" ]
+    then
+        bbfatal "Output not found in '${B}/install/outputs'!"
+    fi
+
+    install -d -m 755 ${D}/firmware
+    cd ${B}/install/outputs
+    for dir in *;do
+        install -D -p -m 0644 $dir/* -t ${D}/firmware/$dir/
+    done
+}
+
+FILES_${PN} = "/firmware"
+SYSROOT_DIRS += "/firmware"
+# Skip QA check for relocations in .text of elf binaries
+INSANE_SKIP_${PN} = "textrel"
+
+addtask deploy after do_install
+do_deploy() {
+    cp -rf ${D}/firmware/* ${DEPLOYDIR}/
+}
diff --git a/meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m_1.0.bb b/meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m_1.0.bb
new file mode 100644
index 0000000..5779c08
--- /dev/null
+++ b/meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m_1.0.bb
@@ -0,0 +1,25 @@ 
+# Trusted Firmware-M 1.0
+
+# TF-Mv1.0
+SRCREV_tfm = "TF-Mv1.0"
+LICENSE = "BSD-3-Clause & Apachev2"
+
+LIC_FILES_CHKSUM ?= "file://license.rst;md5=07f368487da347f3c7bd0fc3085f3afa"
+LIC_FILES_CHKSUM += "file://../mbed-crypto/LICENSE;md5=302d50a6369f5f22efdb674db908167a"
+LIC_FILES_CHKSUM += "file://../mbedtls/LICENSE;md5=302d50a6369f5f22efdb674db908167a"
+LIC_FILES_CHKSUM += "file://../CMSIS_5/LICENSE.txt;md5=c4082b6c254c9fb71136710391d9728b"
+
+SRC_URI  = "git://git.trustedfirmware.org/trusted-firmware-m.git;protocol=https;branch=master;name=tfm;destsuffix=${S}"
+SRC_URI += "git://github.com/ARMmbed/mbed-crypto.git;protocol=https;branch=development;name=mbed-crypto;destsuffix=${S}/../mbed-crypto"
+SRC_URI += "git://github.com/ARMmbed/mbedtls.git;protocol=https;branch=mbedtls-2.7;name=mbedtls;destsuffix=${S}/../mbedtls"
+SRC_URI += "https://github.com/ARM-software/CMSIS_5/releases/download/5.5.0/ARM.CMSIS.5.5.0.pack;name=cmsis;subdir=${S}/../CMSIS_5;downloadfilename=ARM.CMSIS.5.5.0.zip"
+
+SRC_URI[cmsis.md5sum] = "73b6cf6b4ab06ac099478e6cf983c08e"
+SRC_URI[cmsis.sha256sum] = "fc6e46c77de29ed05ef3bfd4846a2da49b024bc8854c876ac053aaa8d348ac52"
+
+SRCREV_FORMAT ?= "tfm_mbed-crypto_mbedtls_cmsis"
+SRCREV_mbed-crypto ?= "mbedcrypto-3.0.1"
+SRCREV_mbedtls ?= "mbedtls-2.7.14"
+SRCREV_cmsis ?= "5.5.0"
+
+require trusted-firmware-m.inc

Comments

Denys Dmytriyenko June 22, 2020, 4:49 p.m.
On Mon, Jun 22, 2020 at 09:13:59AM +0200, Gabor Abonyi wrote:
> Adds a recipe to pull down the trusted-firmware-m repository and the
> ones it depends on. The recipe can either use gcc-arm-none-eabi-native
> or armcompiler-native Clang toolchain to compile the firmware.
> 
> Change-Id: I37a4ba38982b5b1d387eccbb26bb5c79bddab0f7
> Signed-off-by: Gabor Abonyi <gabor.abonyi@arm.com>
> ---
>  meta-arm/conf/layer.conf                      |   1 +
>  .../trusted-firmware-m/trusted-firmware-m.inc | 118 ++++++++++++++++++
>  .../trusted-firmware-m_1.0.bb                 |  25 ++++
>  3 files changed, 144 insertions(+)
>  create mode 100644 meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m.inc
>  create mode 100644 meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m_1.0.bb
> 
> diff --git a/meta-arm/conf/layer.conf b/meta-arm/conf/layer.conf
> index 3341972..10a7951 100644
> --- a/meta-arm/conf/layer.conf
> +++ b/meta-arm/conf/layer.conf
> @@ -11,5 +11,6 @@ BBFILE_PRIORITY_meta-arm = "6"
>  
>  LAYERDEPENDS_meta-arm = " \
>      core \
> +    arm-toolchain \

This may be problematic...


>  "
>  LAYERSERIES_COMPAT_meta-arm = "warrior zeus dunfell"
> diff --git a/meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m.inc b/meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m.inc
> new file mode 100644
> index 0000000..a7c4319
> --- /dev/null
> +++ b/meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m.inc
> @@ -0,0 +1,118 @@
> +# SPDX-License-Identifier: MIT
> +#
> +# Copyright (c) 2020 Arm Limited
> +#
> +
> +SUMMARY = "Trusted Firmware for Cortex-M"
> +DESCRIPTION = "Trusted Firmware-M"
> +HOMEPAGE = "https://git.trustedfirmware.org/trusted-firmware-m.git"
> +PROVIDES = "virtual/trusted-firmware-m"
> +
> +inherit python3native cmake deploy
> +
> +TFM_DEPENDS ?= ""
> +DEPENDS += "${TFM_DEPENDS}"
> +DEPENDS += "python3-cryptography-native python3-pyasn1-native"
> +DEPENDS += "python3-jinja2-native python3-cbor-native python3-pyyaml-native"
> +
> +S = "${WORKDIR}/git/tfm"
> +# Sub-directory in which to build.
> +BUILD_DIR = "cmake_build"
> +B = "${S}/${BUILD_DIR}"
> +
> +COMPATIBLE_MACHINE ?= "invalid"
> +
> +# Build for debug (set TFA_DEBUG to 1 to activate)
> +TFM_DEBUG ?= "0"
> +# Set target config
> +TFM_CONFIG ?= "ConfigDefault.cmake"
> +# Platform must be set for each machine
> +TFM_PLATFORM ?= "invalid"
> +
> +# Uncomment, or copy these lines to your local.conf to use the Arm Clang compiler
> +# from meta-arm-toolchain.
> +# Please make sure to check the applicable license beforehand!
> +#LICENSE_FLAGS_WHITELIST = "commercial_armcompiler-native"
> +#TFM_COMPILER = "ARMCLANG"
> +# Uncomment the line below to use the license from your host machine:
> +#inherit armcompiler-host-license
> +# Otherwise you have to set and export the following variables manually.
> +# ARM_DS_DEFAULT_TOOLKIT_KEY, ARMLMD_LICENSE_FILE, LM_LICENSE_FILE
> +
> +# Setting GCC as the default TF-M compiler
> +TFM_COMPILER ?= "GNUARM"
> +DEPENDS += "${@'armcompiler-native' if d.getVar('TFM_COMPILER', True) == 'ARMCLANG' else 'gcc-arm-none-eabi-native'}"
> +
> +# Add platform parameters
> +EXTRA_OECMAKE += "-DTARGET_PLATFORM=${TFM_PLATFORM}"
> +
> +# Add compiler parameters
> +EXTRA_OECMAKE += "-DCOMPILER=${TFM_COMPILER}"
> +
> +# Handle TFM_DEBUG parameter
> +EXTRA_OECMAKE += "${@bb.utils.contains('TFM_DEBUG', '1', '-DCMAKE_BUILD_TYPE=Debug', '', d)}"
> +EXTRA_OECMAKE += "-DPROJ_CONFIG=${S}/configs/${TFM_CONFIG}"
> +
> +# Let the Makefile handle setting up the CFLAGS and LDFLAGS as it is a standalone application
> +CFLAGS[unexport] = "1"
> +LDFLAGS[unexport] = "1"
> +AS[unexport] = "1"
> +LD[unexport] = "1"
> +
> +# This is needed because CMSIS_5 source package originally has .pack extension not .zip
> +# and bitbake checks this dependency based on file extension
> +do_unpack[depends] += "unzip-native:do_populate_sysroot"
> +
> +do_configure[prefuncs] += "do_check_config"
> +do_check_config() {
> +    if [ ! -f "${S}/configs/${TFM_CONFIG}" ]; then
> +        bbfatal "Couldn't find config file '${TFM_CONFIG}' in '${S}/configs/'"
> +    fi
> +}
> +
> +do_configure() {
> +    cd ${S}
> +    python3 "tools/tfm_parse_manifest_list.py"
> +
> +    if [ ! -d "${B}" ]
> +    then
> +        install -d ${B}
> +    else
> +        rm -f ${B}/CMakeCache.txt
> +    fi
> +
> +    cd ${B}
> +    cmake -G"Unix Makefiles" --build ${S} ${EXTRA_OECMAKE}
> +}
> +
> +do_compile() {
> +    if [ -d "${B}" ]
> +    then
> +        oe_runmake -C ${B} install
> +    else
> +        bbfatal "TF-M CMake not generated!"
> +    fi
> +}
> +
> +do_install() {
> +    if [ ! -d "${B}/install/outputs" ]
> +    then
> +        bbfatal "Output not found in '${B}/install/outputs'!"
> +    fi
> +
> +    install -d -m 755 ${D}/firmware
> +    cd ${B}/install/outputs
> +    for dir in *;do
> +        install -D -p -m 0644 $dir/* -t ${D}/firmware/$dir/
> +    done
> +}
> +
> +FILES_${PN} = "/firmware"
> +SYSROOT_DIRS += "/firmware"
> +# Skip QA check for relocations in .text of elf binaries
> +INSANE_SKIP_${PN} = "textrel"
> +
> +addtask deploy after do_install
> +do_deploy() {
> +    cp -rf ${D}/firmware/* ${DEPLOYDIR}/
> +}
> diff --git a/meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m_1.0.bb b/meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m_1.0.bb
> new file mode 100644
> index 0000000..5779c08
> --- /dev/null
> +++ b/meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m_1.0.bb
> @@ -0,0 +1,25 @@
> +# Trusted Firmware-M 1.0
> +
> +# TF-Mv1.0
> +SRCREV_tfm = "TF-Mv1.0"
> +LICENSE = "BSD-3-Clause & Apachev2"
> +
> +LIC_FILES_CHKSUM ?= "file://license.rst;md5=07f368487da347f3c7bd0fc3085f3afa"
> +LIC_FILES_CHKSUM += "file://../mbed-crypto/LICENSE;md5=302d50a6369f5f22efdb674db908167a"
> +LIC_FILES_CHKSUM += "file://../mbedtls/LICENSE;md5=302d50a6369f5f22efdb674db908167a"
> +LIC_FILES_CHKSUM += "file://../CMSIS_5/LICENSE.txt;md5=c4082b6c254c9fb71136710391d9728b"
> +
> +SRC_URI  = "git://git.trustedfirmware.org/trusted-firmware-m.git;protocol=https;branch=master;name=tfm;destsuffix=${S}"
> +SRC_URI += "git://github.com/ARMmbed/mbed-crypto.git;protocol=https;branch=development;name=mbed-crypto;destsuffix=${S}/../mbed-crypto"
> +SRC_URI += "git://github.com/ARMmbed/mbedtls.git;protocol=https;branch=mbedtls-2.7;name=mbedtls;destsuffix=${S}/../mbedtls"
> +SRC_URI += "https://github.com/ARM-software/CMSIS_5/releases/download/5.5.0/ARM.CMSIS.5.5.0.pack;name=cmsis;subdir=${S}/../CMSIS_5;downloadfilename=ARM.CMSIS.5.5.0.zip"
> +
> +SRC_URI[cmsis.md5sum] = "73b6cf6b4ab06ac099478e6cf983c08e"
> +SRC_URI[cmsis.sha256sum] = "fc6e46c77de29ed05ef3bfd4846a2da49b024bc8854c876ac053aaa8d348ac52"
> +
> +SRCREV_FORMAT ?= "tfm_mbed-crypto_mbedtls_cmsis"
> +SRCREV_mbed-crypto ?= "mbedcrypto-3.0.1"
> +SRCREV_mbedtls ?= "mbedtls-2.7.14"
> +SRCREV_cmsis ?= "5.5.0"
> +
> +require trusted-firmware-m.inc
> -- 
> 2.17.1
> 

>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#734): https://lists.yoctoproject.org/g/meta-arm/message/734
Mute This Topic: https://lists.yoctoproject.org/mt/75033886/3617530
Group Owner: meta-arm+owner@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/meta-arm/unsub  [oe-patchwork@oe-patch.openembedded.org]
-=-=-=-=-=-=-=-=-=-=-=-
Jon Mason June 22, 2020, 5:26 p.m.
On Mon, Jun 22, 2020 at 12:49:36PM -0400, Denys Dmytriyenko wrote:
> On Mon, Jun 22, 2020 at 09:13:59AM +0200, Gabor Abonyi wrote:
> > Adds a recipe to pull down the trusted-firmware-m repository and the
> > ones it depends on. The recipe can either use gcc-arm-none-eabi-native
> > or armcompiler-native Clang toolchain to compile the firmware.
> > 
> > Change-Id: I37a4ba38982b5b1d387eccbb26bb5c79bddab0f7
> > Signed-off-by: Gabor Abonyi <gabor.abonyi@arm.com>
> > ---
> >  meta-arm/conf/layer.conf                      |   1 +
> >  .../trusted-firmware-m/trusted-firmware-m.inc | 118 ++++++++++++++++++
> >  .../trusted-firmware-m_1.0.bb                 |  25 ++++
> >  3 files changed, 144 insertions(+)
> >  create mode 100644 meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m.inc
> >  create mode 100644 meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m_1.0.bb
> > 
> > diff --git a/meta-arm/conf/layer.conf b/meta-arm/conf/layer.conf
> > index 3341972..10a7951 100644
> > --- a/meta-arm/conf/layer.conf
> > +++ b/meta-arm/conf/layer.conf
> > @@ -11,5 +11,6 @@ BBFILE_PRIORITY_meta-arm = "6"
> >  
> >  LAYERDEPENDS_meta-arm = " \
> >      core \
> > +    arm-toolchain \
> 
> This may be problematic...

Yes, this was flagged as a potential problem internally.  Fortunately,
meta-arm-toolchain currently has no other layer dependencies.  So, it
shouldn't hurt too much.  Ccing JPEW directly on this, since his
insight has been helpful in the past.

TF-M requires Arm's LLVM/Clang based toolchain to compile, which is
the second patch of this series.

Thanks,
Jon

> 
> 
> >  "
> >  LAYERSERIES_COMPAT_meta-arm = "warrior zeus dunfell"
> > diff --git a/meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m.inc b/meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m.inc
> > new file mode 100644
> > index 0000000..a7c4319
> > --- /dev/null
> > +++ b/meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m.inc
> > @@ -0,0 +1,118 @@
> > +# SPDX-License-Identifier: MIT
> > +#
> > +# Copyright (c) 2020 Arm Limited
> > +#
> > +
> > +SUMMARY = "Trusted Firmware for Cortex-M"
> > +DESCRIPTION = "Trusted Firmware-M"
> > +HOMEPAGE = "https://git.trustedfirmware.org/trusted-firmware-m.git"
> > +PROVIDES = "virtual/trusted-firmware-m"
> > +
> > +inherit python3native cmake deploy
> > +
> > +TFM_DEPENDS ?= ""
> > +DEPENDS += "${TFM_DEPENDS}"
> > +DEPENDS += "python3-cryptography-native python3-pyasn1-native"
> > +DEPENDS += "python3-jinja2-native python3-cbor-native python3-pyyaml-native"
> > +
> > +S = "${WORKDIR}/git/tfm"
> > +# Sub-directory in which to build.
> > +BUILD_DIR = "cmake_build"
> > +B = "${S}/${BUILD_DIR}"
> > +
> > +COMPATIBLE_MACHINE ?= "invalid"
> > +
> > +# Build for debug (set TFA_DEBUG to 1 to activate)
> > +TFM_DEBUG ?= "0"
> > +# Set target config
> > +TFM_CONFIG ?= "ConfigDefault.cmake"
> > +# Platform must be set for each machine
> > +TFM_PLATFORM ?= "invalid"
> > +
> > +# Uncomment, or copy these lines to your local.conf to use the Arm Clang compiler
> > +# from meta-arm-toolchain.
> > +# Please make sure to check the applicable license beforehand!
> > +#LICENSE_FLAGS_WHITELIST = "commercial_armcompiler-native"
> > +#TFM_COMPILER = "ARMCLANG"
> > +# Uncomment the line below to use the license from your host machine:
> > +#inherit armcompiler-host-license
> > +# Otherwise you have to set and export the following variables manually.
> > +# ARM_DS_DEFAULT_TOOLKIT_KEY, ARMLMD_LICENSE_FILE, LM_LICENSE_FILE
> > +
> > +# Setting GCC as the default TF-M compiler
> > +TFM_COMPILER ?= "GNUARM"
> > +DEPENDS += "${@'armcompiler-native' if d.getVar('TFM_COMPILER', True) == 'ARMCLANG' else 'gcc-arm-none-eabi-native'}"
> > +
> > +# Add platform parameters
> > +EXTRA_OECMAKE += "-DTARGET_PLATFORM=${TFM_PLATFORM}"
> > +
> > +# Add compiler parameters
> > +EXTRA_OECMAKE += "-DCOMPILER=${TFM_COMPILER}"
> > +
> > +# Handle TFM_DEBUG parameter
> > +EXTRA_OECMAKE += "${@bb.utils.contains('TFM_DEBUG', '1', '-DCMAKE_BUILD_TYPE=Debug', '', d)}"
> > +EXTRA_OECMAKE += "-DPROJ_CONFIG=${S}/configs/${TFM_CONFIG}"
> > +
> > +# Let the Makefile handle setting up the CFLAGS and LDFLAGS as it is a standalone application
> > +CFLAGS[unexport] = "1"
> > +LDFLAGS[unexport] = "1"
> > +AS[unexport] = "1"
> > +LD[unexport] = "1"
> > +
> > +# This is needed because CMSIS_5 source package originally has .pack extension not .zip
> > +# and bitbake checks this dependency based on file extension
> > +do_unpack[depends] += "unzip-native:do_populate_sysroot"
> > +
> > +do_configure[prefuncs] += "do_check_config"
> > +do_check_config() {
> > +    if [ ! -f "${S}/configs/${TFM_CONFIG}" ]; then
> > +        bbfatal "Couldn't find config file '${TFM_CONFIG}' in '${S}/configs/'"
> > +    fi
> > +}
> > +
> > +do_configure() {
> > +    cd ${S}
> > +    python3 "tools/tfm_parse_manifest_list.py"
> > +
> > +    if [ ! -d "${B}" ]
> > +    then
> > +        install -d ${B}
> > +    else
> > +        rm -f ${B}/CMakeCache.txt
> > +    fi
> > +
> > +    cd ${B}
> > +    cmake -G"Unix Makefiles" --build ${S} ${EXTRA_OECMAKE}
> > +}
> > +
> > +do_compile() {
> > +    if [ -d "${B}" ]
> > +    then
> > +        oe_runmake -C ${B} install
> > +    else
> > +        bbfatal "TF-M CMake not generated!"
> > +    fi
> > +}
> > +
> > +do_install() {
> > +    if [ ! -d "${B}/install/outputs" ]
> > +    then
> > +        bbfatal "Output not found in '${B}/install/outputs'!"
> > +    fi
> > +
> > +    install -d -m 755 ${D}/firmware
> > +    cd ${B}/install/outputs
> > +    for dir in *;do
> > +        install -D -p -m 0644 $dir/* -t ${D}/firmware/$dir/
> > +    done
> > +}
> > +
> > +FILES_${PN} = "/firmware"
> > +SYSROOT_DIRS += "/firmware"
> > +# Skip QA check for relocations in .text of elf binaries
> > +INSANE_SKIP_${PN} = "textrel"
> > +
> > +addtask deploy after do_install
> > +do_deploy() {
> > +    cp -rf ${D}/firmware/* ${DEPLOYDIR}/
> > +}
> > diff --git a/meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m_1.0.bb b/meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m_1.0.bb
> > new file mode 100644
> > index 0000000..5779c08
> > --- /dev/null
> > +++ b/meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m_1.0.bb
> > @@ -0,0 +1,25 @@
> > +# Trusted Firmware-M 1.0
> > +
> > +# TF-Mv1.0
> > +SRCREV_tfm = "TF-Mv1.0"
> > +LICENSE = "BSD-3-Clause & Apachev2"
> > +
> > +LIC_FILES_CHKSUM ?= "file://license.rst;md5=07f368487da347f3c7bd0fc3085f3afa"
> > +LIC_FILES_CHKSUM += "file://../mbed-crypto/LICENSE;md5=302d50a6369f5f22efdb674db908167a"
> > +LIC_FILES_CHKSUM += "file://../mbedtls/LICENSE;md5=302d50a6369f5f22efdb674db908167a"
> > +LIC_FILES_CHKSUM += "file://../CMSIS_5/LICENSE.txt;md5=c4082b6c254c9fb71136710391d9728b"
> > +
> > +SRC_URI  = "git://git.trustedfirmware.org/trusted-firmware-m.git;protocol=https;branch=master;name=tfm;destsuffix=${S}"
> > +SRC_URI += "git://github.com/ARMmbed/mbed-crypto.git;protocol=https;branch=development;name=mbed-crypto;destsuffix=${S}/../mbed-crypto"
> > +SRC_URI += "git://github.com/ARMmbed/mbedtls.git;protocol=https;branch=mbedtls-2.7;name=mbedtls;destsuffix=${S}/../mbedtls"
> > +SRC_URI += "https://github.com/ARM-software/CMSIS_5/releases/download/5.5.0/ARM.CMSIS.5.5.0.pack;name=cmsis;subdir=${S}/../CMSIS_5;downloadfilename=ARM.CMSIS.5.5.0.zip"
> > +
> > +SRC_URI[cmsis.md5sum] = "73b6cf6b4ab06ac099478e6cf983c08e"
> > +SRC_URI[cmsis.sha256sum] = "fc6e46c77de29ed05ef3bfd4846a2da49b024bc8854c876ac053aaa8d348ac52"
> > +
> > +SRCREV_FORMAT ?= "tfm_mbed-crypto_mbedtls_cmsis"
> > +SRCREV_mbed-crypto ?= "mbedcrypto-3.0.1"
> > +SRCREV_mbedtls ?= "mbedtls-2.7.14"
> > +SRCREV_cmsis ?= "5.5.0"
> > +
> > +require trusted-firmware-m.inc
> > -- 
> > 2.17.1
> > 
> 
> > 
> 

>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#735): https://lists.yoctoproject.org/g/meta-arm/message/735
Mute This Topic: https://lists.yoctoproject.org/mt/75033886/3617530
Group Owner: meta-arm+owner@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/meta-arm/unsub  [oe-patchwork@oe-patch.openembedded.org]
-=-=-=-=-=-=-=-=-=-=-=-
Denys Dmytriyenko June 22, 2020, 5:36 p.m.
On Mon, Jun 22, 2020 at 01:26:54PM -0400, Jon Mason wrote:
> On Mon, Jun 22, 2020 at 12:49:36PM -0400, Denys Dmytriyenko wrote:
> > On Mon, Jun 22, 2020 at 09:13:59AM +0200, Gabor Abonyi wrote:
> > > Adds a recipe to pull down the trusted-firmware-m repository and the
> > > ones it depends on. The recipe can either use gcc-arm-none-eabi-native
> > > or armcompiler-native Clang toolchain to compile the firmware.
> > > 
> > > Change-Id: I37a4ba38982b5b1d387eccbb26bb5c79bddab0f7
> > > Signed-off-by: Gabor Abonyi <gabor.abonyi@arm.com>
> > > ---
> > >  meta-arm/conf/layer.conf                      |   1 +
> > >  .../trusted-firmware-m/trusted-firmware-m.inc | 118 ++++++++++++++++++
> > >  .../trusted-firmware-m_1.0.bb                 |  25 ++++
> > >  3 files changed, 144 insertions(+)
> > >  create mode 100644 meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m.inc
> > >  create mode 100644 meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m_1.0.bb
> > > 
> > > diff --git a/meta-arm/conf/layer.conf b/meta-arm/conf/layer.conf
> > > index 3341972..10a7951 100644
> > > --- a/meta-arm/conf/layer.conf
> > > +++ b/meta-arm/conf/layer.conf
> > > @@ -11,5 +11,6 @@ BBFILE_PRIORITY_meta-arm = "6"
> > >  
> > >  LAYERDEPENDS_meta-arm = " \
> > >      core \
> > > +    arm-toolchain \
> > 
> > This may be problematic...
> 
> Yes, this was flagged as a potential problem internally.  Fortunately,
> meta-arm-toolchain currently has no other layer dependencies.  So, it
> shouldn't hurt too much.  Ccing JPEW directly on this, since his
> insight has been helpful in the past.
> 
> TF-M requires Arm's LLVM/Clang based toolchain to compile, which is
> the second patch of this series.

One of the options is to move TF-M to meta-arm-bsp...
Joshua Watt June 22, 2020, 6:04 p.m.
On 6/22/20 12:36 PM, Denys Dmytriyenko wrote:
> On Mon, Jun 22, 2020 at 01:26:54PM -0400, Jon Mason wrote:
>> On Mon, Jun 22, 2020 at 12:49:36PM -0400, Denys Dmytriyenko wrote:
>>> On Mon, Jun 22, 2020 at 09:13:59AM +0200, Gabor Abonyi wrote:
>>>> Adds a recipe to pull down the trusted-firmware-m repository and the
>>>> ones it depends on. The recipe can either use gcc-arm-none-eabi-native
>>>> or armcompiler-native Clang toolchain to compile the firmware.
>>>>
>>>> Change-Id: I37a4ba38982b5b1d387eccbb26bb5c79bddab0f7
>>>> Signed-off-by: Gabor Abonyi <gabor.abonyi@arm.com>
>>>> ---
>>>>   meta-arm/conf/layer.conf                      |   1 +
>>>>   .../trusted-firmware-m/trusted-firmware-m.inc | 118 ++++++++++++++++++
>>>>   .../trusted-firmware-m_1.0.bb                 |  25 ++++
>>>>   3 files changed, 144 insertions(+)
>>>>   create mode 100644 meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m.inc
>>>>   create mode 100644 meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m_1.0.bb
>>>>
>>>> diff --git a/meta-arm/conf/layer.conf b/meta-arm/conf/layer.conf
>>>> index 3341972..10a7951 100644
>>>> --- a/meta-arm/conf/layer.conf
>>>> +++ b/meta-arm/conf/layer.conf
>>>> @@ -11,5 +11,6 @@ BBFILE_PRIORITY_meta-arm = "6"
>>>>   
>>>>   LAYERDEPENDS_meta-arm = " \
>>>>       core \
>>>> +    arm-toolchain \
>>> This may be problematic...
>> Yes, this was flagged as a potential problem internally.  Fortunately,
>> meta-arm-toolchain currently has no other layer dependencies.  So, it
>> shouldn't hurt too much.  Ccing JPEW directly on this, since his
>> insight has been helpful in the past.
>>
>> TF-M requires Arm's LLVM/Clang based toolchain to compile, which is
>> the second patch of this series.
> One of the options is to move TF-M to meta-arm-bsp...

Ya, I wouldn't want to mandate meta-arm-toolchain here. You could either 
move it to meta-arm-bsp as Denys suggested or possibly use BBFILES_DYNAMIC?


>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#737): https://lists.yoctoproject.org/g/meta-arm/message/737
Mute This Topic: https://lists.yoctoproject.org/mt/75033886/3617530
Group Owner: meta-arm+owner@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/meta-arm/unsub  [oe-patchwork@oe-patch.openembedded.org]
-=-=-=-=-=-=-=-=-=-=-=-
Ross Burton June 22, 2020, 6:23 p.m.
On Mon, 22 Jun 2020 at 08:15, Gabor Abonyi <gabor.abonyi@arm.com> wrote:
> Adds a recipe to pull down the trusted-firmware-m repository and the
> ones it depends on. The recipe can either use gcc-arm-none-eabi-native
> or armcompiler-native Clang toolchain to compile the firmware.

Looks like it's time to start that multiconfig experiment where we
just build another cross compiler inside Yocto.

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#739): https://lists.yoctoproject.org/g/meta-arm/message/739
Mute This Topic: https://lists.yoctoproject.org/mt/75033886/3617530
Group Owner: meta-arm+owner@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/meta-arm/unsub  [oe-patchwork@oe-patch.openembedded.org]
-=-=-=-=-=-=-=-=-=-=-=-
Denys Dmytriyenko June 22, 2020, 6:43 p.m.
On Mon, Jun 22, 2020 at 07:23:24PM +0100, Ross Burton wrote:
> On Mon, 22 Jun 2020 at 08:15, Gabor Abonyi <gabor.abonyi@arm.com> wrote:
> > Adds a recipe to pull down the trusted-firmware-m repository and the
> > ones it depends on. The recipe can either use gcc-arm-none-eabi-native
> > or armcompiler-native Clang toolchain to compile the firmware.
> 
> Looks like it's time to start that multiconfig experiment where we
> just build another cross compiler inside Yocto.

You can check meta-ti - our K3 platforms have Aarch64 Cortex-A cores and Armv7 
Cortex-R cores, so meta-ti now uses multiconfig to build 2 cross compilers and 
use those for corresponding components. TF-M sounds like a perfect use case 
for that, as well.
Ross Burton June 22, 2020, 7:29 p.m.
On Mon, 22 Jun 2020 at 19:44, Denys Dmytriyenko <denis@denix.org> wrote:
> > Looks like it's time to start that multiconfig experiment where we
> > just build another cross compiler inside Yocto.
>
> You can check meta-ti - our K3 platforms have Aarch64 Cortex-A cores and Armv7
> Cortex-R cores, so meta-ti now uses multiconfig to build 2 cross compilers and
> use those for corresponding components. TF-M sounds like a perfect use case
> for that, as well.

Awesome for doing it already.  Does it work well?

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#741): https://lists.yoctoproject.org/g/meta-arm/message/741
Mute This Topic: https://lists.yoctoproject.org/mt/75033886/3617530
Group Owner: meta-arm+owner@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/meta-arm/unsub  [oe-patchwork@oe-patch.openembedded.org]
-=-=-=-=-=-=-=-=-=-=-=-
Denys Dmytriyenko June 22, 2020, 7:48 p.m.
On Mon, Jun 22, 2020 at 08:29:02PM +0100, Ross Burton wrote:
> On Mon, 22 Jun 2020 at 19:44, Denys Dmytriyenko <denis@denix.org> wrote:
> > > Looks like it's time to start that multiconfig experiment where we
> > > just build another cross compiler inside Yocto.
> >
> > You can check meta-ti - our K3 platforms have Aarch64 Cortex-A cores and Armv7
> > Cortex-R cores, so meta-ti now uses multiconfig to build 2 cross compilers and
> > use those for corresponding components. TF-M sounds like a perfect use case
> > for that, as well.
> 
> Awesome for doing it already.  Does it work well?

Works quite well, as long as you can express relations between multiconfigs 
with build-time dependency and hand-off via DEPLOY_DIR. Works quite well if 
you only need to do firmwares or bootloaders for those extra cores. You can 
even have those packaged into a partition in your wic image.

But more complex use cases, which would require run-time dependencies, like 
packaging an SDK with both cross-compilers and sysroots, aren't supported yet.
Diego Sueiro June 23, 2020, 7:06 a.m.
On Mon, Jun 22, 2020 at 08:48 PM, Denys Dmytriyenko wrote:

>
> On Mon, Jun 22, 2020 at 08:29:02PM +0100, Ross Burton wrote:
> > On Mon, 22 Jun 2020 at 19:44, Denys Dmytriyenko <denis@denix.org> wrote:
> > > > Looks like it's time to start that multiconfig experiment where we
> > > > just build another cross compiler inside Yocto.
> > >
> > > You can check meta-ti - our K3 platforms have Aarch64 Cortex-A cores and
> Armv7
> > > Cortex-R cores, so meta-ti now uses multiconfig to build 2 cross compilers
> and
> > > use those for corresponding components. TF-M sounds like a perfect use
> case
> > > for that, as well.
> > 
> > Awesome for doing it already.  Does it work well?
> 
> Works quite well, as long as you can express relations between multiconfigs 
> with build-time dependency and hand-off via DEPLOY_DIR. Works quite well if 
> you only need to do firmwares or bootloaders for those extra cores. You can 
> even have those packaged into a partition in your wic image.
> 
> But more complex use cases, which would require run-time dependencies, like 
> packaging an SDK with both cross-compilers and sysroots, aren't supported yet.
> 
> -- 
> Denys
>
On Mon, Jun 22, 2020 at 08:48 PM, Denys Dmytriyenko wrote:

>
> On Mon, Jun 22, 2020 at 08:29:02PM +0100, Ross Burton wrote:
> > On Mon, 22 Jun 2020 at 19:44, Denys Dmytriyenko <denis@denix.org> wrote:
> > > > Looks like it's time to start that multiconfig experiment where we
> > > > just build another cross compiler inside Yocto.
> > >
> > > You can check meta-ti - our K3 platforms have Aarch64 Cortex-A cores and
> Armv7
> > > Cortex-R cores, so meta-ti now uses multiconfig to build 2 cross compilers
> and
> > > use those for corresponding components. TF-M sounds like a perfect use
> case
> > > for that, as well.
> > 
> > Awesome for doing it already.  Does it work well?
> 
> Works quite well, as long as you can express relations between multiconfigs 
> with build-time dependency and hand-off via DEPLOY_DIR. Works quite well if 
> you only need to do firmwares or bootloaders for those extra cores. You can 
> even have those packaged into a partition in your wic image.
> 
> But more complex use cases, which would require run-time dependencies, like 
> packaging an SDK with both cross-compilers and sysroots, aren't supported yet.
> 
> -- 
> Denys
>

I'm struggling to understand what multiconfig and building the toolchain from source will help on removing the meta-arm dependency on meta-arm-toolchain.
Can you guys elaborate better?

The ideal place for trusted-firmware-[a|m] recipes is meta-arm layer since they are generic and supposed to be specialized/customized/extended/tweaked by BSP layers.

Using BBFILES_DYNAMIC is a feasible possibility (despite adding at least more two directory levels) if adding meta-arm-toolchain as default dependency on meta-arm will cause so much pain.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#746): https://lists.yoctoproject.org/g/meta-arm/message/746
Mute This Topic: https://lists.yoctoproject.org/mt/75033886/3617530
Group Owner: meta-arm+owner@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/meta-arm/unsub  [oe-patchwork@oe-patch.openembedded.org]
-=-=-=-=-=-=-=-=-=-=-=-
Gabor Abonyi June 23, 2020, 8:59 a.m.
If I move TF-M to meta-arm-bsp, then meta-arm-bsp would have the dependency on arm-toolchain. Would that be better?
(I do not understand why meta-arm depending on arm-toolchain is a bad thing, explanations are welcome :) )
 
I experimented with BBFILES_DYNAMIC, but it is very unhelpful from end-user perspective (if arm-toolchain is not in bblayers):
"ERROR: Nothing PROVIDES 'trusted-firmware-m'. Close matches:
  trusted-firmware-a"
Compared to the current one:
"ERROR: Layer 'meta-arm' depends on layer 'arm-toolchain', but this layer is not enabled in your configuration"

I am open to any suggestions.
 
-----Original Message-----
From: meta-arm@lists.yoctoproject.org <meta-arm@lists.yoctoproject.org> On Behalf Of Joshua Watt via lists.yoctoproject.org

Sent: 2020. június 22., hétfő 20:04
To: Denys Dmytriyenko <denis@denix.org>; Jon Mason <jdmason@kudzu.us>
Cc: Gabor Abonyi <Gabor.Abonyi@arm.com>; meta-arm@lists.yoctoproject.org; nd <nd@arm.com>
Subject: Re: [meta-arm] [PATCH 4/6] arm: trusted-firmware-m: Add recipe


On 6/22/20 12:36 PM, Denys Dmytriyenko wrote:
> On Mon, Jun 22, 2020 at 01:26:54PM -0400, Jon Mason wrote:

>> On Mon, Jun 22, 2020 at 12:49:36PM -0400, Denys Dmytriyenko wrote:

>>> On Mon, Jun 22, 2020 at 09:13:59AM +0200, Gabor Abonyi wrote:

>>>> Adds a recipe to pull down the trusted-firmware-m repository and 

>>>> the ones it depends on. The recipe can either use 

>>>> gcc-arm-none-eabi-native or armcompiler-native Clang toolchain to compile the firmware.

>>>>

>>>> Change-Id: I37a4ba38982b5b1d387eccbb26bb5c79bddab0f7

>>>> Signed-off-by: Gabor Abonyi <gabor.abonyi@arm.com>

>>>> ---

>>>>   meta-arm/conf/layer.conf                      |   1 +

>>>>   .../trusted-firmware-m/trusted-firmware-m.inc | 118 ++++++++++++++++++

>>>>   .../trusted-firmware-m_1.0.bb                 |  25 ++++

>>>>   3 files changed, 144 insertions(+)

>>>>   create mode 100644 meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m.inc

>>>>   create mode 100644 

>>>> meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m_1.0.bb

>>>>

>>>> diff --git a/meta-arm/conf/layer.conf b/meta-arm/conf/layer.conf 

>>>> index 3341972..10a7951 100644

>>>> --- a/meta-arm/conf/layer.conf

>>>> +++ b/meta-arm/conf/layer.conf

>>>> @@ -11,5 +11,6 @@ BBFILE_PRIORITY_meta-arm = "6"

>>>>   

>>>>   LAYERDEPENDS_meta-arm = " \

>>>>       core \

>>>> +    arm-toolchain \

>>> This may be problematic...

>> Yes, this was flagged as a potential problem internally.  

>> Fortunately, meta-arm-toolchain currently has no other layer 

>> dependencies.  So, it shouldn't hurt too much.  Ccing JPEW directly 

>> on this, since his insight has been helpful in the past.

>>

>> TF-M requires Arm's LLVM/Clang based toolchain to compile, which is 

>> the second patch of this series.

> One of the options is to move TF-M to meta-arm-bsp...


Ya, I wouldn't want to mandate meta-arm-toolchain here. You could either move it to meta-arm-bsp as Denys suggested or possibly use BBFILES_DYNAMIC?


>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#748): https://lists.yoctoproject.org/g/meta-arm/message/748
Mute This Topic: https://lists.yoctoproject.org/mt/75033886/3617530
Group Owner: meta-arm+owner@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/meta-arm/unsub  [oe-patchwork@oe-patch.openembedded.org]
-=-=-=-=-=-=-=-=-=-=-=-
Denys Dmytriyenko July 1, 2020, 6:08 p.m.
On Tue, Jun 23, 2020 at 08:59:56AM +0000, Gabor Abonyi wrote:
> If I move TF-M to meta-arm-bsp, then meta-arm-bsp would have the dependency on arm-toolchain. Would that be better?
> (I do not understand why meta-arm depending on arm-toolchain is a bad thing, explanations are welcome :) )

meta-arm is meant to be a central place for shared components to be used by 
other BSPs. Kind of a community layer, if you like. And arm-toolchain is kind 
of a special layer and may not be desirable by all BSPs, so that would reduce 
overall usefulness of meta-arm layer. Each individual BSP (and meta-arm-bsp is 
one of those) is free to depend on arm-toolchain layer directly, if needed.
Denys Dmytriyenko July 1, 2020, 6:10 p.m.
On Tue, Jun 23, 2020 at 12:06:56AM -0700, Diego Sueiro wrote:
> On Mon, Jun 22, 2020 at 08:48 PM, Denys Dmytriyenko wrote:
> 
> >
> > On Mon, Jun 22, 2020 at 08:29:02PM +0100, Ross Burton wrote:
> > > On Mon, 22 Jun 2020 at 19:44, Denys Dmytriyenko <denis@denix.org> wrote:
> > > > > Looks like it's time to start that multiconfig experiment where we
> > > > > just build another cross compiler inside Yocto.
> > > >
> > > > You can check meta-ti - our K3 platforms have Aarch64 Cortex-A cores and
> > Armv7
> > > > Cortex-R cores, so meta-ti now uses multiconfig to build 2 cross compilers
> > and
> > > > use those for corresponding components. TF-M sounds like a perfect use
> > case
> > > > for that, as well.
> > > 
> > > Awesome for doing it already.  Does it work well?
> > 
> > Works quite well, as long as you can express relations between multiconfigs 
> > with build-time dependency and hand-off via DEPLOY_DIR. Works quite well if 
> > you only need to do firmwares or bootloaders for those extra cores. You can 
> > even have those packaged into a partition in your wic image.
> > 
> > But more complex use cases, which would require run-time dependencies, like 
> > packaging an SDK with both cross-compilers and sysroots, aren't supported yet.
> > 
> > -- 
> > Denys
> >
> On Mon, Jun 22, 2020 at 08:48 PM, Denys Dmytriyenko wrote:
> 
> >
> > On Mon, Jun 22, 2020 at 08:29:02PM +0100, Ross Burton wrote:
> > > On Mon, 22 Jun 2020 at 19:44, Denys Dmytriyenko <denis@denix.org> wrote:
> > > > > Looks like it's time to start that multiconfig experiment where we
> > > > > just build another cross compiler inside Yocto.
> > > >
> > > > You can check meta-ti - our K3 platforms have Aarch64 Cortex-A cores and
> > Armv7
> > > > Cortex-R cores, so meta-ti now uses multiconfig to build 2 cross compilers
> > and
> > > > use those for corresponding components. TF-M sounds like a perfect use
> > case
> > > > for that, as well.
> > > 
> > > Awesome for doing it already.  Does it work well?
> > 
> > Works quite well, as long as you can express relations between multiconfigs 
> > with build-time dependency and hand-off via DEPLOY_DIR. Works quite well if 
> > you only need to do firmwares or bootloaders for those extra cores. You can 
> > even have those packaged into a partition in your wic image.
> > 
> > But more complex use cases, which would require run-time dependencies, like 
> > packaging an SDK with both cross-compilers and sysroots, aren't supported yet.
> > 
> > -- 
> > Denys
> >
> 
> I'm struggling to understand what multiconfig and building the toolchain 
> from source will help on removing the meta-arm dependency on 
> meta-arm-toolchain.
> Can you guys elaborate better?

I don't believe that was directly related. I'm guessing Ross was wondering if 
building a baremetal toolchain from source will reduce dependencies and that 
is indeed possible with multiconfig.
Gabor Abonyi July 1, 2020, 11:28 p.m.
This is a system generated Comment: Patch 173757 was automatically marked as superseded by patch 174129.
Ross Burton July 2, 2020, 9:14 a.m.
On Wed, 1 Jul 2020 at 19:08, Denys Dmytriyenko <denis@denix.org> wrote:
> meta-arm is meant to be a central place for shared components to be used by
> other BSPs. Kind of a community layer, if you like. And arm-toolchain is kind
> of a special layer and may not be desirable by all BSPs, so that would reduce
> overall usefulness of meta-arm layer. Each individual BSP (and meta-arm-bsp is
> one of those) is free to depend on arm-toolchain layer directly, if needed.

Arguably, tfm should be in meta-arm for the same reasons that tfa is:
it's a shared component and not specific to a single BSP.

The need for a binary toolchain is not ideal but simply adding the
layer doesn't cause it to be used by all recipes.  I propose that we
add this series now and evaluate the use of multiconfig to build a
second cross compiler in the future (sooner rather than later).

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#802): https://lists.yoctoproject.org/g/meta-arm/message/802
Mute This Topic: https://lists.yoctoproject.org/mt/75033886/3617530
Group Owner: meta-arm+owner@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/meta-arm/unsub  [oe-patchwork@oe-patch.openembedded.org]
-=-=-=-=-=-=-=-=-=-=-=-
Jon Mason July 2, 2020, 3:33 p.m.
On Wed, Jul 01, 2020 at 02:10:55PM -0400, Denys Dmytriyenko wrote:
> On Tue, Jun 23, 2020 at 12:06:56AM -0700, Diego Sueiro wrote:
> > On Mon, Jun 22, 2020 at 08:48 PM, Denys Dmytriyenko wrote:
> > 
> > >
> > > On Mon, Jun 22, 2020 at 08:29:02PM +0100, Ross Burton wrote:
> > > > On Mon, 22 Jun 2020 at 19:44, Denys Dmytriyenko <denis@denix.org> wrote:
> > > > > > Looks like it's time to start that multiconfig experiment where we
> > > > > > just build another cross compiler inside Yocto.
> > > > >
> > > > > You can check meta-ti - our K3 platforms have Aarch64 Cortex-A cores and
> > > Armv7
> > > > > Cortex-R cores, so meta-ti now uses multiconfig to build 2 cross compilers
> > > and
> > > > > use those for corresponding components. TF-M sounds like a perfect use
> > > case
> > > > > for that, as well.
> > > > 
> > > > Awesome for doing it already.  Does it work well?
> > > 
> > > Works quite well, as long as you can express relations between multiconfigs 
> > > with build-time dependency and hand-off via DEPLOY_DIR. Works quite well if 
> > > you only need to do firmwares or bootloaders for those extra cores. You can 
> > > even have those packaged into a partition in your wic image.
> > > 
> > > But more complex use cases, which would require run-time dependencies, like 
> > > packaging an SDK with both cross-compilers and sysroots, aren't supported yet.
> > > 
> > > -- 
> > > Denys
> > >
> > On Mon, Jun 22, 2020 at 08:48 PM, Denys Dmytriyenko wrote:
> > 
> > >
> > > On Mon, Jun 22, 2020 at 08:29:02PM +0100, Ross Burton wrote:
> > > > On Mon, 22 Jun 2020 at 19:44, Denys Dmytriyenko <denis@denix.org> wrote:
> > > > > > Looks like it's time to start that multiconfig experiment where we
> > > > > > just build another cross compiler inside Yocto.
> > > > >
> > > > > You can check meta-ti - our K3 platforms have Aarch64 Cortex-A cores and
> > > Armv7
> > > > > Cortex-R cores, so meta-ti now uses multiconfig to build 2 cross compilers
> > > and
> > > > > use those for corresponding components. TF-M sounds like a perfect use
> > > case
> > > > > for that, as well.
> > > > 
> > > > Awesome for doing it already.  Does it work well?
> > > 
> > > Works quite well, as long as you can express relations between multiconfigs 
> > > with build-time dependency and hand-off via DEPLOY_DIR. Works quite well if 
> > > you only need to do firmwares or bootloaders for those extra cores. You can 
> > > even have those packaged into a partition in your wic image.
> > > 
> > > But more complex use cases, which would require run-time dependencies, like 
> > > packaging an SDK with both cross-compilers and sysroots, aren't supported yet.
> > > 
> > > -- 
> > > Denys
> > >
> > 
> > I'm struggling to understand what multiconfig and building the toolchain 
> > from source will help on removing the meta-arm dependency on 
> > meta-arm-toolchain.
> > Can you guys elaborate better?
> 
> I don't believe that was directly related. I'm guessing Ross was wondering if 
> building a baremetal toolchain from source will reduce dependencies and that 
> is indeed possible with multiconfig.

Yes, I believe multiconfig will help break the dep in meta-arm and
move it to meta-arm-bsp (assuming that it is determined that the Arm
Clang compiler is superior).

Thanks,
Jon

> 
> -- 
> Denys
> 
> 
> > The ideal place for trusted-firmware-[a|m] recipes is meta-arm layer since 
> > they are generic and supposed to be specialized/customized/extended/tweaked 
> > by BSP layers.
> > 
> > Using BBFILES_DYNAMIC is a feasible possibility (despite adding at least 
> > more two directory levels) if adding meta-arm-toolchain as default 
> > dependency on meta-arm will cause so much pain.
> 
> > 
> 

>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#803): https://lists.yoctoproject.org/g/meta-arm/message/803
Mute This Topic: https://lists.yoctoproject.org/mt/75033886/3617530
Group Owner: meta-arm+owner@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/meta-arm/unsub  [oe-patchwork@oe-patch.openembedded.org]
-=-=-=-=-=-=-=-=-=-=-=-
Jon Mason July 2, 2020, 3:39 p.m.
On Thu, Jul 02, 2020 at 10:14:55AM +0100, Ross Burton wrote:
> On Wed, 1 Jul 2020 at 19:08, Denys Dmytriyenko <denis@denix.org> wrote:
> > meta-arm is meant to be a central place for shared components to be used by
> > other BSPs. Kind of a community layer, if you like. And arm-toolchain is kind
> > of a special layer and may not be desirable by all BSPs, so that would reduce
> > overall usefulness of meta-arm layer. Each individual BSP (and meta-arm-bsp is
> > one of those) is free to depend on arm-toolchain layer directly, if needed.
> 
> Arguably, tfm should be in meta-arm for the same reasons that tfa is:
> it's a shared component and not specific to a single BSP.
> 
> The need for a binary toolchain is not ideal but simply adding the
> layer doesn't cause it to be used by all recipes.  I propose that we
> add this series now and evaluate the use of multiconfig to build a
> second cross compiler in the future (sooner rather than later).

To be clear, this is not a perminent requirement.  I would LOVE for it
to be removed, and I am hoping it will be done within the next month
or so.  IMHO, having TF-M available with this detriment is superior to
not having it due to this issue.

If this is a dealbreaker, please let me know.

Thanks,
Jon

> 
> Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#804): https://lists.yoctoproject.org/g/meta-arm/message/804
Mute This Topic: https://lists.yoctoproject.org/mt/75033886/3617530
Group Owner: meta-arm+owner@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/meta-arm/unsub  [oe-patchwork@oe-patch.openembedded.org]
-=-=-=-=-=-=-=-=-=-=-=-
Fabien Parent July 16, 2020, 6:14 a.m.
Hi,

I'm using meta-arm for the OP-TEE recipe (and soon I will replace our
TF-A recipe to be based on the one from meta-arm). I just discovered
this change today by receiving multiple report of the following error
when trying to build an image based on our layer:
    ERROR: Layer 'meta-arm' depends on layer 'arm-toolchain', but this
layer is not enabled in your configuration
    Summary: There was 1 ERROR message shown, returning a non-zero exit code.

Usually the stable branches (dunfell in this case) don't add change
that could break other people's setup like adding a new hard
dependency. Most of the time the changes are bug-fixes, or minor
upgrades to packages.

Shall I consider meta-arm to not follow this rule, and in order to
never have breakage, pull a specific commit hash instead of pulling
the current release branch?

Thanks,
Fabien

On Thu, Jul 2, 2020 at 5:39 PM Jon Mason <jdmason@kudzu.us> wrote:
>
> On Thu, Jul 02, 2020 at 10:14:55AM +0100, Ross Burton wrote:
> > On Wed, 1 Jul 2020 at 19:08, Denys Dmytriyenko <denis@denix.org> wrote:
> > > meta-arm is meant to be a central place for shared components to be used by
> > > other BSPs. Kind of a community layer, if you like. And arm-toolchain is kind
> > > of a special layer and may not be desirable by all BSPs, so that would reduce
> > > overall usefulness of meta-arm layer. Each individual BSP (and meta-arm-bsp is
> > > one of those) is free to depend on arm-toolchain layer directly, if needed.
> >
> > Arguably, tfm should be in meta-arm for the same reasons that tfa is:
> > it's a shared component and not specific to a single BSP.
> >
> > The need for a binary toolchain is not ideal but simply adding the
> > layer doesn't cause it to be used by all recipes.  I propose that we
> > add this series now and evaluate the use of multiconfig to build a
> > second cross compiler in the future (sooner rather than later).
>
> To be clear, this is not a perminent requirement.  I would LOVE for it
> to be removed, and I am hoping it will be done within the next month
> or so.  IMHO, having TF-M available with this detriment is superior to
> not having it due to this issue.
>
> If this is a dealbreaker, please let me know.
>
> Thanks,
> Jon
>
> >
> > Ross
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#858): https://lists.yoctoproject.org/g/meta-arm/message/858
Mute This Topic: https://lists.yoctoproject.org/mt/75033886/3617530
Group Owner: meta-arm+owner@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/meta-arm/unsub  [oe-patchwork@oe-patch.openembedded.org]
-=-=-=-=-=-=-=-=-=-=-=-
Jon Mason July 17, 2020, 1:32 p.m.
On Thu, Jul 16, 2020 at 08:14:33AM +0200, Fabien Parent wrote:
> Hi,
> 
> I'm using meta-arm for the OP-TEE recipe (and soon I will replace our
> TF-A recipe to be based on the one from meta-arm). I just discovered
> this change today by receiving multiple report of the following error
> when trying to build an image based on our layer:
>     ERROR: Layer 'meta-arm' depends on layer 'arm-toolchain', but this
> layer is not enabled in your configuration
>     Summary: There was 1 ERROR message shown, returning a non-zero exit code.
> 
> Usually the stable branches (dunfell in this case) don't add change
> that could break other people's setup like adding a new hard
> dependency. Most of the time the changes are bug-fixes, or minor
> upgrades to packages.
> 
> Shall I consider meta-arm to not follow this rule, and in order to
> never have breakage, pull a specific commit hash instead of pulling
> the current release branch?

We've been very public about the dunfell branch not being a stable
branch. In fact, I even sent out an specific email to this list about
this very topic.  Please read
https://lists.yoctoproject.org/g/meta-arm/message/652

All of that being said, our intention is to never break the dunfell
branch (as we intend on using it for product SW releases).  We are in
the process of rolling out CI for this branch and this should assist
in this task.  Until we have a better setup in place, it is possible
issues might roll through.  I apologize if this causes problems, and
ask that you are patient with us.

Thanks,
Jon


> 
> Thanks,
> Fabien
> 
> On Thu, Jul 2, 2020 at 5:39 PM Jon Mason <jdmason@kudzu.us> wrote:
> >
> > On Thu, Jul 02, 2020 at 10:14:55AM +0100, Ross Burton wrote:
> > > On Wed, 1 Jul 2020 at 19:08, Denys Dmytriyenko <denis@denix.org> wrote:
> > > > meta-arm is meant to be a central place for shared components to be used by
> > > > other BSPs. Kind of a community layer, if you like. And arm-toolchain is kind
> > > > of a special layer and may not be desirable by all BSPs, so that would reduce
> > > > overall usefulness of meta-arm layer. Each individual BSP (and meta-arm-bsp is
> > > > one of those) is free to depend on arm-toolchain layer directly, if needed.
> > >
> > > Arguably, tfm should be in meta-arm for the same reasons that tfa is:
> > > it's a shared component and not specific to a single BSP.
> > >
> > > The need for a binary toolchain is not ideal but simply adding the
> > > layer doesn't cause it to be used by all recipes.  I propose that we
> > > add this series now and evaluate the use of multiconfig to build a
> > > second cross compiler in the future (sooner rather than later).
> >
> > To be clear, this is not a perminent requirement.  I would LOVE for it
> > to be removed, and I am hoping it will be done within the next month
> > or so.  IMHO, having TF-M available with this detriment is superior to
> > not having it due to this issue.
> >
> > If this is a dealbreaker, please let me know.
> >
> > Thanks,
> > Jon
> >
> > >
> > > Ross
> >
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#879): https://lists.yoctoproject.org/g/meta-arm/message/879
Mute This Topic: https://lists.yoctoproject.org/mt/75033886/3617530
Group Owner: meta-arm+owner@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/meta-arm/unsub  [oe-patchwork@oe-patch.openembedded.org]
-=-=-=-=-=-=-=-=-=-=-=-