* [Buildroot] [PATCH v4 2/7] optee-client: new package
2019-01-30 10:47 [Buildroot] [PATCH v4 1/7] boot/optee-os: new package Etienne Carriere
@ 2019-01-30 10:47 ` Etienne Carriere
2019-02-17 20:52 ` Thomas Petazzoni
2019-01-30 10:47 ` [Buildroot] [PATCH v4 3/7] optee-examples: " Etienne Carriere
` (5 subsequent siblings)
6 siblings, 1 reply; 25+ messages in thread
From: Etienne Carriere @ 2019-01-30 10:47 UTC (permalink / raw)
To: buildroot
OP-TEE client API library and supplicant daemon from the
OP-TEE project are packaged in package/optee-client. An init script
launches the tee-supplicant deamon. Package is added to the
Security menu of BR configuration.
This change references in Buildroot the today's latest OP-TEE
revision release tagged 3.4.0.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
---
Changes v3 -> v4:
- Upgrade from OP-TEE release 3.3.0 to 3.4.0.
Changes v2 -> v3:
- Add an entry in file DEVELOPERS.
- Clean Config.in layout and description sections.
- Drop BR2_PACKAGE_OPTEE_CLIENT_SYNCED_VERSION.
- Clean optee-client.mk layout.
- Remove OPTEE_CLIENT_INSTALL_STAGING indirection.
- Replace optee-client.hash with per-version optee-client.hash files.
- Support the released 3.x tags from OP-TEE project.
- Correct license tag (client is BSD-2-Clause instead of BSD-3-Clause).
- Rewrite the init script to use start-stop-daemon
Changes v1 -> v2:
- Add option BR2_PACKAGE_OPTEE_CLIENT_SYNCED_VERSION to ensure
OP-TEE client version is synced with OP-TEE OS version when
the later if enabled.
- Remove useless OPTEE_CLIENT_INSTALL_IMAGE=YES.
---
DEVELOPERS | 1 +
package/Config.in | 1 +
package/optee-client/3.4.0/optee-client.hash | 4 ++
package/optee-client/Config.in | 55 ++++++++++++++++++++++++++++
package/optee-client/S30optee | 49 +++++++++++++++++++++++++
package/optee-client/optee-client.mk | 25 +++++++++++++
6 files changed, 135 insertions(+)
create mode 100644 package/optee-client/3.4.0/optee-client.hash
create mode 100644 package/optee-client/Config.in
create mode 100644 package/optee-client/S30optee
create mode 100644 package/optee-client/optee-client.mk
diff --git a/DEVELOPERS b/DEVELOPERS
index ac608e5..f028179 100644
--- a/DEVELOPERS
+++ b/DEVELOPERS
@@ -683,6 +683,7 @@ F: package/szip/
N: Etienne Carriere <etienne.carriere@linaro.org>
F: boot/optee-os/
+F: package/optee-client/
N: Eugene Tarassov <eugene@largest.net>
F: package/tcf-agent/
diff --git a/package/Config.in b/package/Config.in
index 5036421..ae9f557 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -2077,6 +2077,7 @@ endmenu
menu "Security"
source "package/checkpolicy/Config.in"
+ source "package/optee-client/Config.in"
source "package/paxtest/Config.in"
source "package/policycoreutils/Config.in"
source "package/refpolicy/Config.in"
diff --git a/package/optee-client/3.4.0/optee-client.hash b/package/optee-client/3.4.0/optee-client.hash
new file mode 100644
index 0000000..0da25ce
--- /dev/null
+++ b/package/optee-client/3.4.0/optee-client.hash
@@ -0,0 +1,4 @@
+# From https://github.com/OP-TEE/optee_client/archive/3.4.0.tar.gz
+sha256 7c131a44f4d73acb8816fba88bcd7e6a18537f0a522ae426a20e2ca7dc46a6ec optee-client-3.4.0.tar.gz
+# Locally computed
+sha256 fda8385993f112d7ca61b88b54ba5b4cbeec7e43a0f9b317d5186703c1985e8f LICENSE
diff --git a/package/optee-client/Config.in b/package/optee-client/Config.in
new file mode 100644
index 0000000..99cac63
--- /dev/null
+++ b/package/optee-client/Config.in
@@ -0,0 +1,55 @@
+config BR2_PACKAGE_OPTEE_CLIENT
+ bool "optee-client"
+ help
+ Enable the OP-TEE client package that brings non-secure
+ client application resources for OP-TEE support. OP-TEE
+ client is a component delivered by the OP-TEE project.
+
+ The client API library allows application to invoke
+ trusted applications hosted in the OP-TEE OS secure world.
+ The supplicant provides services hosted by the non-secure
+ world and invoked by the secure world.
+
+ https://github.com/OP-TEE/optee_client
+
+if BR2_PACKAGE_OPTEE_CLIENT
+
+choice
+ prompt "version"
+ default BR2_PACKAGE_OPTEE_CLIENT_LATEST
+ help
+ Select the version of OP-TEE client you want to use
+
+config BR2_PACKAGE_OPTEE_CLIENT_LATEST
+ bool "3.4.0"
+ help
+ This fetches the registered release tag from the
+ OP-TEE official Git repository.
+
+config BR2_PACKAGE_OPTEE_CLIENT_CUSTOM_GIT
+ bool "Custom Git repository"
+ help
+ Sync with a specific OP-TEE Git repository.
+
+endchoice
+
+if BR2_PACKAGE_OPTEE_CLIENT_CUSTOM_GIT
+
+config BR2_PACKAGE_OPTEE_CLIENT_CUSTOM_REPO_URL
+ string "URL of custom repository"
+
+config BR2_PACKAGE_OPTEE_CLIENT_CUSTOM_REPO_VERSION
+ string "Custom repository version"
+ help
+ Revision to use in the typical format used by
+ Git E.G. a sha id, a tag, branch, ..
+
+endif
+
+config BR2_PACKAGE_OPTEE_CLIENT_VERSION
+ string
+ default "3.4.0" if BR2_PACKAGE_OPTEE_CLIENT_LATEST
+ default BR2_PACKAGE_OPTEE_CLIENT_CUSTOM_REPO_VERSION \
+ if BR2_PACKAGE_OPTEE_CLIENT_CUSTOM_GIT
+
+endif #BR2_PACKAGE_OPTEE_CLIENT
diff --git a/package/optee-client/S30optee b/package/optee-client/S30optee
new file mode 100644
index 0000000..17e6d6d
--- /dev/null
+++ b/package/optee-client/S30optee
@@ -0,0 +1,49 @@
+#!/bin/sh
+
+DAEMON="tee-supplicant"
+PIDFILE="/var/run/$DAEMON.pid"
+
+DAEMON_ARGS="-d /dev/teepriv0"
+
+start() {
+ printf 'Starting %s: ' "$DAEMON"
+ start-stop-daemon -S -q -p "$PIDFILE" -x "/usr/sbin/$DAEMON" \
+ -- $DAEMON_ARGS
+ status=$?
+ if [ "$status" -eq 0 ]; then
+ echo "OK"
+ else
+ echo "FAIL"
+ fi
+ return "$status"
+}
+
+stop() {
+ printf 'Stopping %s: ' "$DAEMON"
+ start-stop-daemon -K -q -p "$PIDFILE"
+ status=$?
+ if [ "$status" -eq 0 ]; then
+ echo "OK"
+ else
+ echo "FAIL"
+ fi
+ return "$status"
+}
+
+restart() {
+ stop
+ sleep 1
+ start
+}
+
+case "$1" in
+ start|stop|restart)
+ "$1";;
+ reload)
+ # Restart, since there is no true "reload" feature (does not
+ # reconfigure/restart on SIGHUP, just closes all open files).
+ restart;;
+ *)
+ echo "Usage: $0 {start|stop|restart|reload}"
+ exit 1
+esac
diff --git a/package/optee-client/optee-client.mk b/package/optee-client/optee-client.mk
new file mode 100644
index 0000000..5cd741b
--- /dev/null
+++ b/package/optee-client/optee-client.mk
@@ -0,0 +1,25 @@
+################################################################################
+#
+# optee-client
+#
+################################################################################
+
+OPTEE_CLIENT_VERSION = $(call qstrip,$(BR2_PACKAGE_OPTEE_CLIENT_VERSION))
+OPTEE_CLIENT_LICENSE = BSD-2-Clause
+OPTEE_CLIENT_LICENSE_FILES = LICENSE
+OPTEE_CLIENT_INSTALL_STAGING = YES
+
+ifeq ($(BR2_PACKAGE_OPTEE_CLIENT_CUSTOM_GIT),y)
+OPTEE_CLIENT_SITE = $(call qstrip,$(BR2_PACKAGE_OPTEE_CLIENT_CUSTOM_REPO_URL))
+OPTEE_CLIENT_SITE_METHOD = git
+BR_NO_CHECK_HASH_FOR += $(OPTEE_CLIENT_SOURCE)
+else
+OPTEE_CLIENT_SITE = $(call github,OP-TEE,optee_client,$(OPTEE_CLIENT_VERSION))
+endif
+
+define OPTEE_CLIENT_INSTALL_INIT_SYSV
+ $(INSTALL) -m 0755 -D $(OPTEE_CLIENT_PKGDIR)/S30optee \
+ $(TARGET_DIR)/etc/init.d/S30optee
+endef
+
+$(eval $(cmake-package))
^ permalink raw reply related [flat|nested] 25+ messages in thread* [Buildroot] [PATCH v4 2/7] optee-client: new package
2019-01-30 10:47 ` [Buildroot] [PATCH v4 2/7] optee-client: " Etienne Carriere
@ 2019-02-17 20:52 ` Thomas Petazzoni
0 siblings, 0 replies; 25+ messages in thread
From: Thomas Petazzoni @ 2019-02-17 20:52 UTC (permalink / raw)
To: buildroot
Hello ?tienne,
I have applied to the next branch after a few changes (see below), but
there are some build failures with some configurations, which will have
to be fixed. I'm giving more details below as well.
On Wed, 30 Jan 2019 11:47:24 +0100
Etienne Carriere <etienne.carriere@linaro.org> wrote:
> diff --git a/package/optee-client/3.4.0/optee-client.hash b/package/optee-client/3.4.0/optee-client.hash
> new file mode 100644
> index 0000000..0da25ce
> --- /dev/null
> +++ b/package/optee-client/3.4.0/optee-client.hash
> @@ -0,0 +1,4 @@
> +# From https://github.com/OP-TEE/optee_client/archive/3.4.0.tar.gz
> +sha256 7c131a44f4d73acb8816fba88bcd7e6a18537f0a522ae426a20e2ca7dc46a6ec optee-client-3.4.0.tar.gz
> +# Locally computed
> +sha256 fda8385993f112d7ca61b88b54ba5b4cbeec7e43a0f9b317d5186703c1985e8f LICENSE
> diff --git a/package/optee-client/Config.in b/package/optee-client/Config.in
> new file mode 100644
> index 0000000..99cac63
> --- /dev/null
> +++ b/package/optee-client/Config.in
> @@ -0,0 +1,55 @@
> +config BR2_PACKAGE_OPTEE_CLIENT
> + bool "optee-client"
The following dependency:
depends on !BR2_STATIC_LIBS
is needed, because optee-client tries to unconditionally build a shared
library, instead of obeying to the standard
BUILD_SHARED_LIBS/BUILD_STATIC_LIBS CMake variables.
> +if BR2_PACKAGE_OPTEE_CLIENT
> +
> +choice
> + prompt "version"
> + default BR2_PACKAGE_OPTEE_CLIENT_LATEST
> + help
> + Select the version of OP-TEE client you want to use
> +
> +config BR2_PACKAGE_OPTEE_CLIENT_LATEST
> + bool "3.4.0"
> + help
> + This fetches the registered release tag from the
> + OP-TEE official Git repository.
> +
> +config BR2_PACKAGE_OPTEE_CLIENT_CUSTOM_GIT
> + bool "Custom Git repository"
> + help
> + Sync with a specific OP-TEE Git repository.
> +
> +endchoice
I don't really see why a version selection was needed, so I've dropped
it entirely. Is there anything really HW/SoC specific in optee-client ?
There are two build failures that I noticed.
With the following defconfig:
BR2_arm=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y
BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/tarballs/armv5-ctng-linux-gnueabi.tar.xz"
BR2_TOOLCHAIN_EXTERNAL_CUSTOM_PREFIX="armv5-ctng-linux-gnueabi"
BR2_TOOLCHAIN_EXTERNAL_GCC_4_8=y
BR2_TOOLCHAIN_EXTERNAL_HEADERS_3_12=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM_GLIBC=y
BR2_TOOLCHAIN_EXTERNAL_CXX=y
BR2_INIT_NONE=y
BR2_SYSTEM_BIN_SH_NONE=y
# BR2_PACKAGE_BUSYBOX is not set
BR2_PACKAGE_OPTEE_CLIENT=y
# BR2_TARGET_ROOTFS_TAR is not set
You will get:
/home/thomas/projets/outputs/armv5-ctng-linux-gnueabi/build/optee-client-3.4.0/libteec/src/tee_client_api.c: In function 'TEEC_InitializeContext':
/home/thomas/projets/outputs/armv5-ctng-linux-gnueabi/build/optee-client-3.4.0/libteec/src/tee_client_api.c:149:28: error: 'gen_caps' may be used uninitialized in this function [-Werror=maybe-uninitialized]
ctx->reg_mem = gen_caps & TEE_GEN_CAP_REG_MEM;
^
cc1: all warnings being treated as errors
With this other defconfig:
BR2_or1k=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y
BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.net/toolchains/tarballs/br-openrisc-full-2018.02-925-gd4158df.tar.bz2"
BR2_TOOLCHAIN_EXTERNAL_GCC_5=y
BR2_TOOLCHAIN_EXTERNAL_HEADERS_4_16=y
BR2_TOOLCHAIN_EXTERNAL_LOCALE=y
# BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS_DEBUG is not set
BR2_TOOLCHAIN_EXTERNAL_CXX=y
BR2_INIT_NONE=y
BR2_SYSTEM_BIN_SH_NONE=y
# BR2_PACKAGE_BUSYBOX is not set
BR2_PACKAGE_OPTEE_CLIENT=y
# BR2_TARGET_ROOTFS_TAR is not set
You will get this failure:
/home/thomas/projets/buildroot/output/build/optee-client-3.4.0/libteec/src/tee_client_api.c: In function ?TEEC_OpenSession?:
/home/thomas/projets/buildroot/output/build/optee-client-3.4.0/libteec/src/tee_client_api.c:507:8: error: cast increases required alignment of target type [-Werror=cast-align]
arg = (struct tee_ioctl_open_session_arg *)buf;
^
/home/thomas/projets/buildroot/output/build/optee-client-3.4.0/libteec/src/tee_client_api.c: In function ?TEEC_InvokeCommand?:
/home/thomas/projets/buildroot/output/build/optee-client-3.4.0/libteec/src/tee_client_api.c:581:8: error: cast increases required alignment of target type [-Werror=cast-align]
arg = (struct tee_ioctl_invoke_arg *)buf;
^
cc1: all warnings being treated as errors
Since I wanted to move forward with merging the OP-TEE support, I
applied this patch despite these build failures (a number of other
configurations are building fine), but we will need those build issues
to be resolved.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] [PATCH v4 3/7] optee-examples: new package
2019-01-30 10:47 [Buildroot] [PATCH v4 1/7] boot/optee-os: new package Etienne Carriere
2019-01-30 10:47 ` [Buildroot] [PATCH v4 2/7] optee-client: " Etienne Carriere
@ 2019-01-30 10:47 ` Etienne Carriere
2019-02-17 21:28 ` Thomas Petazzoni
2019-01-30 10:47 ` [Buildroot] [PATCH v4 4/7] optee-test: " Etienne Carriere
` (4 subsequent siblings)
6 siblings, 1 reply; 25+ messages in thread
From: Etienne Carriere @ 2019-01-30 10:47 UTC (permalink / raw)
To: buildroot
This package generates embedded Linux based OS userland client
applications and OP-TEE OS trusted applications all embedded in
the file system. These applications shows how to use the APIs
OP-TEE OS is based on, both in the non secure and secure worlds.
Package is added next to the OP-TEE client package in the BR
package configuration.
This change references in Buildroot the today's latest OP-TEE
revision release tagged 3.4.0 with an added patch to fix an issue
reported by recent GCC toolchains.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
---
Changes v3 -> v4:
- Upgrade from OP-TEE release 3.3.0 to 3.4.0.
Changes v2 -> v3:
- Add an entry in file DEVELOPERS.
- Clean Config.in layout and description sections.
- Drop BR2_PACKAGE_OPTEE_EXAMPLES_SYNCED_VERSION.
- Clean optee-examples.mk layout.
- Replace common optee-examples.hash with per-version .hash files.
- Simplify install command in iotee-test.mk
- Patch optee_test 3.3.0 against an issue in the CMake files.
- Remove dependency of BR2_PACKAGE_OPTEE_EXAMPLES. As the package
depends on BR2_TARGET_OPTEE_OS, leave it to optee-os to define
the supported architectures.
Changes v1 -> v2:
- Replace BR2_arm with BR2_ARM_CPU_ARMV7 as OP-TEE supports only
BR2_ARM_CPU_ARMV7 architectures among the 32bit Arm machines.
- Select OP-TEE client and add dependency on OP-TEE OS.
- Add option BR2_PACKAGE_OPTEE_EXAMPLES_SYNCED_VERSION to ensure
OP-TEE examples version is synced with OP-TEE OS version.
- Do not force output build directory, rely on native path: out/.
- Replace if/endif with depends on in Config.in.
- Remove useless OPTEE_EXAMPLES_INSTALL_STAGING=YES.
- Add package official URL in Config.in package description.
---
DEVELOPERS | 1 +
package/Config.in | 1 +
.../0001-fix-deprecated-size_t-type-for-size.patch | 37 ++++++++++++++
package/optee-examples/3.4.0/optee-examples.hash | 4 ++
package/optee-examples/Config.in | 59 ++++++++++++++++++++++
package/optee-examples/optee-examples.mk | 44 ++++++++++++++++
6 files changed, 146 insertions(+)
create mode 100644 package/optee-examples/3.4.0/0001-fix-deprecated-size_t-type-for-size.patch
create mode 100644 package/optee-examples/3.4.0/optee-examples.hash
create mode 100644 package/optee-examples/Config.in
create mode 100644 package/optee-examples/optee-examples.mk
diff --git a/DEVELOPERS b/DEVELOPERS
index f028179..5efb4ad 100644
--- a/DEVELOPERS
+++ b/DEVELOPERS
@@ -684,6 +684,7 @@ F: package/szip/
N: Etienne Carriere <etienne.carriere@linaro.org>
F: boot/optee-os/
F: package/optee-client/
+F: package/optee-examples/
N: Eugene Tarassov <eugene@largest.net>
F: package/tcf-agent/
diff --git a/package/Config.in b/package/Config.in
index ae9f557..1c3ceab 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -2078,6 +2078,7 @@ endmenu
menu "Security"
source "package/checkpolicy/Config.in"
source "package/optee-client/Config.in"
+ source "package/optee-examples/Config.in"
source "package/paxtest/Config.in"
source "package/policycoreutils/Config.in"
source "package/refpolicy/Config.in"
diff --git a/package/optee-examples/3.4.0/0001-fix-deprecated-size_t-type-for-size.patch b/package/optee-examples/3.4.0/0001-fix-deprecated-size_t-type-for-size.patch
new file mode 100644
index 0000000..ba1716a
--- /dev/null
+++ b/package/optee-examples/3.4.0/0001-fix-deprecated-size_t-type-for-size.patch
@@ -0,0 +1,37 @@
+commit fca0caba591f31f66325826c74acd26aefd52dee
+Author: Etienne Carriere <etienne.carriere@linaro.org>
+Date: Tue Dec 18 22:35:16 2018 +0100
+
+ secure_storage: fix deprecated size_t type for size
+
+ size_t types is an deprecated type used in GPD API v1.0.
+ Update
+
+ Error reported by GCC 7.3-2018.05:
+ secure_storage_ta.c:203:6: warning: passing argument 4 of 'TEE_ReadObjectData' from incompatible pointer type [-Wincompatible-pointer-types]
+ &read_bytes);
+
+ Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
+
+diff --git a/secure_storage/ta/secure_storage_ta.c b/secure_storage/ta/secure_storage_ta.c
+index d120e47..3ccc12d 100644
+--- a/secure_storage/ta/secure_storage_ta.c
++++ b/secure_storage/ta/secure_storage_ta.c
+@@ -146,7 +146,7 @@ static TEE_Result read_raw_object(uint32_t param_types, TEE_Param params[4])
+ TEE_ObjectHandle object;
+ TEE_ObjectInfo object_info;
+ TEE_Result res;
+- size_t read_bytes;
++ uint32_t read_bytes;
+ char *obj_id;
+ size_t obj_id_sz;
+ char *data;
+@@ -202,7 +202,7 @@ static TEE_Result read_raw_object(uint32_t param_types, TEE_Param params[4])
+ res = TEE_ReadObjectData(object, data, object_info.dataSize,
+ &read_bytes);
+ if (res != TEE_SUCCESS || read_bytes != object_info.dataSize) {
+- EMSG("TEE_ReadObjectData failed 0x%08x, read %u over %u",
++ EMSG("TEE_ReadObjectData failed 0x%08x, read %" PRIu32 " over %u",
+ res, read_bytes, object_info.dataSize);
+ goto exit;
+ }
diff --git a/package/optee-examples/3.4.0/optee-examples.hash b/package/optee-examples/3.4.0/optee-examples.hash
new file mode 100644
index 0000000..077fd97
--- /dev/null
+++ b/package/optee-examples/3.4.0/optee-examples.hash
@@ -0,0 +1,4 @@
+# From https://github.com/linaro-swg/optee_examples/archive/3.4.0.tar.gz
+sha256 d833753980ac438c1675787857bb8352997352212334274de9419770097ce039 optee-examples-3.4.0.tar.gz
+# Locally computed
+sha256 6f1ef8449cb82ae79d2155605f7985bdf0f08e7ab5007de9b4362e8bf28733b9 LICENSE
diff --git a/package/optee-examples/Config.in b/package/optee-examples/Config.in
new file mode 100644
index 0000000..a240e54
--- /dev/null
+++ b/package/optee-examples/Config.in
@@ -0,0 +1,59 @@
+config BR2_PACKAGE_OPTEE_EXAMPLES
+ bool "optee-examples"
+ depends on BR2_TARGET_OPTEE_OS
+ select BR2_PACKAGE_OPTEE_CLIENT
+ help
+ Enable the OP-TEE examples package that brings examples of
+ implementation of OP-TEE non-secure client applications and
+ secure trusted applications. OP-TEE examples is a
+ component delivered by the OP-TEE project.
+
+ Trusted application binary files are installed in the target
+ directory /lib/optee_armtz as other trusted applications.
+ At runtime OP-TEE OS can load trusted applications from this
+ non-secure filesystem/directory into the secure world for
+ execution.
+
+ https://github.com/linaro-swg/optee_examples
+
+if BR2_PACKAGE_OPTEE_EXAMPLES
+
+choice
+ prompt "version"
+ default BR2_PACKAGE_OPTEE_EXAMPLES_LATEST
+ help
+ Select the version of OP-TEE exmaples you want to use
+
+config BR2_PACKAGE_OPTEE_EXAMPLES_LATEST
+ bool "3.4.0"
+ help
+ This fetches the registered release tag from the
+ OP-TEE official Git repository.
+
+config BR2_PACKAGE_OPTEE_EXAMPLES_CUSTOM_GIT
+ bool "Custom Git repository"
+ help
+ Sync with a specific OP-TEE Git repository.
+
+endchoice
+
+if BR2_PACKAGE_OPTEE_EXAMPLES_CUSTOM_GIT
+
+config BR2_PACKAGE_OPTEE_EXAMPLES_CUSTOM_REPO_URL
+ string "URL of custom repository"
+
+config BR2_PACKAGE_OPTEE_EXAMPLES_CUSTOM_REPO_VERSION
+ string "Custom repository version"
+ help
+ Revision to use in the typical format used by
+ Git E.G. a sha id, a tag, branch, ..
+
+endif
+
+config BR2_PACKAGE_OPTEE_EXAMPLES_VERSION
+ string
+ default "3.4.0" if BR2_PACKAGE_OPTEE_EXAMPLES_LATEST
+ default BR2_PACKAGE_OPTEE_EXAMPLES_CUSTOM_REPO_VERSION \
+ if BR2_PACKAGE_OPTEE_EXAMPLES_CUSTOM_GIT
+
+endif #BR2_PACKAGE_OPTEE_EXAMPLES
diff --git a/package/optee-examples/optee-examples.mk b/package/optee-examples/optee-examples.mk
new file mode 100644
index 0000000..38701d4
--- /dev/null
+++ b/package/optee-examples/optee-examples.mk
@@ -0,0 +1,44 @@
+################################################################################
+#
+# optee-examples
+#
+################################################################################
+
+OPTEE_EXAMPLES_VERSION = $(call qstrip,$(BR2_PACKAGE_OPTEE_EXAMPLES_VERSION))
+OPTEE_EXAMPLES_LICENSE = BSD-2-Clause
+OPTEE_EXAMPLES_LICENSE_FILES = LICENSE
+
+OPTEE_EXAMPLES_DEPENDENCIES = optee-client optee-os
+
+ifeq ($(BR2_PACKAGE_OPTEE_EXAMPLES_CUSTOM_GIT),y)
+OPTEE_EXAMPLES_SITE = $(call qstrip,$(BR2_PACKAGE_OPTEE_EXAMPLES_CUSTOM_REPO_URL))
+OPTEE_EXAMPLES_SITE_METHOD = git
+BR_NO_CHECK_HASH_FOR += $(OPTEE_EXAMPLES_SOURCE)
+else
+OPTEE_EXAMPLES_SITE = $(call github,linaro-swg,optee_examples,$(OPTEE_EXAMPLES_VERSION))
+endif
+
+ifeq ($(BR2_aarch64),y)
+OPTEE_EXAMPLES_SDK = $(STAGING_DIR)/lib/optee/export-ta_arm64
+endif
+ifeq ($(BR2_arm),y)
+OPTEE_EXAMPLES_SDK = $(STAGING_DIR)/lib/optee/export-ta_arm32
+endif
+
+# Trusted Application are not built from CMake due to ta_dev_kit dependencies.
+# We must build and install them on target.
+define OPTEE_EXAMPLES_BUILD_TAS
+ @$(foreach f,$(wildcard $(@D)/*/ta/Makefile), \
+ $(TARGET_CONFIGURE_OPTS) \
+ $(MAKE) CROSS_COMPILE=$(TARGET_CROSS) \
+ TA_DEV_KIT_DIR=$(OPTEE_EXAMPLES_SDK) \
+ O=out -C $(dir $f) all &&) true
+endef
+define OPTEE_EXAMPLES_INSTALL_TAS
+ @mkdir -p $(TARGET_DIR)/lib/optee_armtz
+ @$(INSTALL) -D -m 444 -t $(TARGET_DIR)/lib/optee_armtz $(@D)/*/ta/out/*.ta
+endef
+OPTEE_EXAMPLES_POST_BUILD_HOOKS += OPTEE_EXAMPLES_BUILD_TAS
+OPTEE_EXAMPLES_POST_INSTALL_TARGET_HOOKS += OPTEE_EXAMPLES_INSTALL_TAS
+
+$(eval $(cmake-package))
^ permalink raw reply related [flat|nested] 25+ messages in thread* [Buildroot] [PATCH v4 3/7] optee-examples: new package
2019-01-30 10:47 ` [Buildroot] [PATCH v4 3/7] optee-examples: " Etienne Carriere
@ 2019-02-17 21:28 ` Thomas Petazzoni
2019-02-19 7:25 ` Etienne Carriere
0 siblings, 1 reply; 25+ messages in thread
From: Thomas Petazzoni @ 2019-02-17 21:28 UTC (permalink / raw)
To: buildroot
Hello ?tienne,
On Wed, 30 Jan 2019 11:47:25 +0100
Etienne Carriere <etienne.carriere@linaro.org> wrote:
> This package generates embedded Linux based OS userland client
> applications and OP-TEE OS trusted applications all embedded in
> the file system. These applications shows how to use the APIs
> OP-TEE OS is based on, both in the non secure and secure worlds.
>
> Package is added next to the OP-TEE client package in the BR
> package configuration.
>
> This change references in Buildroot the today's latest OP-TEE
> revision release tagged 3.4.0 with an added patch to fix an issue
> reported by recent GCC toolchains.
>
> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
I have applied to next, but with a number of changes, see below.
> diff --git a/package/optee-examples/3.4.0/0001-fix-deprecated-size_t-type-for-size.patch b/package/optee-examples/3.4.0/0001-fix-deprecated-size_t-type-for-size.patch
> new file mode 100644
> index 0000000..ba1716a
> --- /dev/null
> +++ b/package/optee-examples/3.4.0/0001-fix-deprecated-size_t-type-for-size.patch
> @@ -0,0 +1,37 @@
> +commit fca0caba591f31f66325826c74acd26aefd52dee
> +Author: Etienne Carriere <etienne.carriere@linaro.org>
> +Date: Tue Dec 18 22:35:16 2018 +0100
> +
> + secure_storage: fix deprecated size_t type for size
> +
> + size_t types is an deprecated type used in GPD API v1.0.
> + Update
> +
> + Error reported by GCC 7.3-2018.05:
> + secure_storage_ta.c:203:6: warning: passing argument 4 of 'TEE_ReadObjectData' from incompatible pointer type [-Wincompatible-pointer-types]
> + &read_bytes);
> +
> + Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Patches should be generated with "git format-patch" and not "git show".
Indeed, patches generated by "git format-patch" can conveniently be
applied by "git am".
I've re-generated the patch to use the proper format.
> diff --git a/package/optee-examples/3.4.0/optee-examples.hash b/package/optee-examples/3.4.0/optee-examples.hash
> new file mode 100644
> index 0000000..077fd97
> --- /dev/null
> +++ b/package/optee-examples/3.4.0/optee-examples.hash
> @@ -0,0 +1,4 @@
> +# From https://github.com/linaro-swg/optee_examples/archive/3.4.0.tar.gz
> +sha256 d833753980ac438c1675787857bb8352997352212334274de9419770097ce039 optee-examples-3.4.0.tar.gz
> +# Locally computed
> +sha256 6f1ef8449cb82ae79d2155605f7985bdf0f08e7ab5007de9b4362e8bf28733b9 LICENSE
> diff --git a/package/optee-examples/Config.in b/package/optee-examples/Config.in
> new file mode 100644
> index 0000000..a240e54
> --- /dev/null
> +++ b/package/optee-examples/Config.in
> @@ -0,0 +1,59 @@
> +config BR2_PACKAGE_OPTEE_EXAMPLES
> + bool "optee-examples"
> + depends on BR2_TARGET_OPTEE_OS
In fact, building OP-TEE itself is not sufficient, because this does
not guarantee the SDK has been built, so I have added a:
select BR2_TARGET_OPTEE_OS_SDK
here.
> + select BR2_PACKAGE_OPTEE_CLIENT
This now depends on !BR2_STATIC_LIBS, so I've propagated this
dependency.
> + help
> + Enable the OP-TEE examples package that brings examples of
> + implementation of OP-TEE non-secure client applications and
> + secure trusted applications. OP-TEE examples is a
> + component delivered by the OP-TEE project.
> +
> + Trusted application binary files are installed in the target
> + directory /lib/optee_armtz as other trusted applications.
> + At runtime OP-TEE OS can load trusted applications from this
> + non-secure filesystem/directory into the secure world for
> + execution.
> +
> + https://github.com/linaro-swg/optee_examples
> +
> +if BR2_PACKAGE_OPTEE_EXAMPLES
> +
> +choice
> + prompt "version"
> + default BR2_PACKAGE_OPTEE_EXAMPLES_LATEST
> + help
> + Select the version of OP-TEE exmaples you want to use
> +
> +config BR2_PACKAGE_OPTEE_EXAMPLES_LATEST
> + bool "3.4.0"
> + help
> + This fetches the registered release tag from the
> + OP-TEE official Git repository.
> +
> +config BR2_PACKAGE_OPTEE_EXAMPLES_CUSTOM_GIT
> + bool "Custom Git repository"
> + help
> + Sync with a specific OP-TEE Git repository.
> +
> +endchoice
Here as well, I don't think the version selection makes a lot of sense,
so I dropped it.
> +ifeq ($(BR2_aarch64),y)
> +OPTEE_EXAMPLES_SDK = $(STAGING_DIR)/lib/optee/export-ta_arm64
> +endif
> +ifeq ($(BR2_arm),y)
Changed:
endif
ifeq ($(BR2_arm),y)
to just:
else ifeq ($(BR2_arm),y)
> +OPTEE_EXAMPLES_SDK = $(STAGING_DIR)/lib/optee/export-ta_arm32
> +endif
> +
> +# Trusted Application are not built from CMake due to ta_dev_kit dependencies.
> +# We must build and install them on target.
> +define OPTEE_EXAMPLES_BUILD_TAS
> + @$(foreach f,$(wildcard $(@D)/*/ta/Makefile), \
> + $(TARGET_CONFIGURE_OPTS) \
> + $(MAKE) CROSS_COMPILE=$(TARGET_CROSS) \
> + TA_DEV_KIT_DIR=$(OPTEE_EXAMPLES_SDK) \
> + O=out -C $(dir $f) all &&) true
Convoluted syntax here. Changed to:
$(foreach f,$(wildcard $(@D)/*/ta/Makefile), \
$(TARGET_CONFIGURE_OPTS) \
$(MAKE) CROSS_COMPILE=$(TARGET_CROSS) \
TA_DEV_KIT_DIR=$(OPTEE_EXAMPLES_SDK) \
O=out -C $(dir $f) all
)
Also: could this be fixed upstream, so that the CMake build system
builds/installs everything ?
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] [PATCH v4 3/7] optee-examples: new package
2019-02-17 21:28 ` Thomas Petazzoni
@ 2019-02-19 7:25 ` Etienne Carriere
0 siblings, 0 replies; 25+ messages in thread
From: Etienne Carriere @ 2019-02-19 7:25 UTC (permalink / raw)
To: buildroot
Hello Thomas,
On Sun, 17 Feb 2019 at 22:28, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello ?tienne,
>
> On Wed, 30 Jan 2019 11:47:25 +0100
> Etienne Carriere <etienne.carriere@linaro.org> wrote:
>
> > This package generates embedded Linux based OS userland client
> > applications and OP-TEE OS trusted applications all embedded in
> > the file system. These applications shows how to use the APIs
> > OP-TEE OS is based on, both in the non secure and secure worlds.
> >
> > Package is added next to the OP-TEE client package in the BR
> > package configuration.
> >
> > This change references in Buildroot the today's latest OP-TEE
> > revision release tagged 3.4.0 with an added patch to fix an issue
> > reported by recent GCC toolchains.
> >
> > Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
>
> I have applied to next, but with a number of changes, see below.
>
>
> > diff --git a/package/optee-examples/3.4.0/0001-fix-deprecated-size_t-type-for-size.patch b/package/optee-examples/3.4.0/0001-fix-deprecated-size_t-type-for-size.patch
> > new file mode 100644
> > index 0000000..ba1716a
> > --- /dev/null
> > +++ b/package/optee-examples/3.4.0/0001-fix-deprecated-size_t-type-for-size.patch
> > @@ -0,0 +1,37 @@
> > +commit fca0caba591f31f66325826c74acd26aefd52dee
> > +Author: Etienne Carriere <etienne.carriere@linaro.org>
> > +Date: Tue Dec 18 22:35:16 2018 +0100
> > +
> > + secure_storage: fix deprecated size_t type for size
> > +
> > + size_t types is an deprecated type used in GPD API v1.0.
> > + Update
> > +
> > + Error reported by GCC 7.3-2018.05:
> > + secure_storage_ta.c:203:6: warning: passing argument 4 of 'TEE_ReadObjectData' from incompatible pointer type [-Wincompatible-pointer-types]
> > + &read_bytes);
> > +
> > + Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
>
> Patches should be generated with "git format-patch" and not "git show".
> Indeed, patches generated by "git format-patch" can conveniently be
> applied by "git am".
>
> I've re-generated the patch to use the proper format.
Ok, sorry, I'll be careful for the next ones.
>
> > diff --git a/package/optee-examples/3.4.0/optee-examples.hash b/package/optee-examples/3.4.0/optee-examples.hash
> > new file mode 100644
> > index 0000000..077fd97
> > --- /dev/null
> > +++ b/package/optee-examples/3.4.0/optee-examples.hash
> > @@ -0,0 +1,4 @@
> > +# From https://github.com/linaro-swg/optee_examples/archive/3.4.0.tar.gz
> > +sha256 d833753980ac438c1675787857bb8352997352212334274de9419770097ce039 optee-examples-3.4.0.tar.gz
> > +# Locally computed
> > +sha256 6f1ef8449cb82ae79d2155605f7985bdf0f08e7ab5007de9b4362e8bf28733b9 LICENSE
> > diff --git a/package/optee-examples/Config.in b/package/optee-examples/Config.in
> > new file mode 100644
> > index 0000000..a240e54
> > --- /dev/null
> > +++ b/package/optee-examples/Config.in
> > @@ -0,0 +1,59 @@
> > +config BR2_PACKAGE_OPTEE_EXAMPLES
> > + bool "optee-examples"
> > + depends on BR2_TARGET_OPTEE_OS
>
> In fact, building OP-TEE itself is not sufficient, because this does
> not guarantee the SDK has been built, so I have added a:
>
> select BR2_TARGET_OPTEE_OS_SDK
>
> here.
>
> > + select BR2_PACKAGE_OPTEE_CLIENT
>
> This now depends on !BR2_STATIC_LIBS, so I've propagated this
> dependency.
>
> > + help
> > + Enable the OP-TEE examples package that brings examples of
> > + implementation of OP-TEE non-secure client applications and
> > + secure trusted applications. OP-TEE examples is a
> > + component delivered by the OP-TEE project.
> > +
> > + Trusted application binary files are installed in the target
> > + directory /lib/optee_armtz as other trusted applications.
> > + At runtime OP-TEE OS can load trusted applications from this
> > + non-secure filesystem/directory into the secure world for
> > + execution.
> > +
> > + https://github.com/linaro-swg/optee_examples
> > +
> > +if BR2_PACKAGE_OPTEE_EXAMPLES
> > +
> > +choice
> > + prompt "version"
> > + default BR2_PACKAGE_OPTEE_EXAMPLES_LATEST
> > + help
> > + Select the version of OP-TEE exmaples you want to use
> > +
> > +config BR2_PACKAGE_OPTEE_EXAMPLES_LATEST
> > + bool "3.4.0"
> > + help
> > + This fetches the registered release tag from the
> > + OP-TEE official Git repository.
> > +
> > +config BR2_PACKAGE_OPTEE_EXAMPLES_CUSTOM_GIT
> > + bool "Custom Git repository"
> > + help
> > + Sync with a specific OP-TEE Git repository.
> > +
> > +endchoice
>
> Here as well, I don't think the version selection makes a lot of sense,
> so I dropped it.
Fair.
>
>
> > +ifeq ($(BR2_aarch64),y)
> > +OPTEE_EXAMPLES_SDK = $(STAGING_DIR)/lib/optee/export-ta_arm64
> > +endif
> > +ifeq ($(BR2_arm),y)
>
> Changed:
>
> endif
> ifeq ($(BR2_arm),y)
>
> to just:
>
> else ifeq ($(BR2_arm),y)
>
> > +OPTEE_EXAMPLES_SDK = $(STAGING_DIR)/lib/optee/export-ta_arm32
> > +endif
> > +
> > +# Trusted Application are not built from CMake due to ta_dev_kit dependencies.
> > +# We must build and install them on target.
> > +define OPTEE_EXAMPLES_BUILD_TAS
> > + @$(foreach f,$(wildcard $(@D)/*/ta/Makefile), \
> > + $(TARGET_CONFIGURE_OPTS) \
> > + $(MAKE) CROSS_COMPILE=$(TARGET_CROSS) \
> > + TA_DEV_KIT_DIR=$(OPTEE_EXAMPLES_SDK) \
> > + O=out -C $(dir $f) all &&) true
>
> Convoluted syntax here. Changed to:
>
> $(foreach f,$(wildcard $(@D)/*/ta/Makefile), \
> $(TARGET_CONFIGURE_OPTS) \
> $(MAKE) CROSS_COMPILE=$(TARGET_CROSS) \
> TA_DEV_KIT_DIR=$(OPTEE_EXAMPLES_SDK) \
> O=out -C $(dir $f) all
> )
>
> Also: could this be fixed upstream, so that the CMake build system
> builds/installs everything ?
That a tricky part. The binaries that executes in the secure world, that is
Trusted Application, i.e those built from the optee-test package as well
as the OP-TEE OS core (optee-os) uses build sequence written with
GNU Makefile that we (I mean people contributing to op-tee) did not
manage yet to port to CMake. This is an open task and it would greatly
help integration of OP-TEE in many build env, but it is not available yet.
Sorry
Best regards,
etienne
>
> Thanks!
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] [PATCH v4 4/7] optee-test: new package
2019-01-30 10:47 [Buildroot] [PATCH v4 1/7] boot/optee-os: new package Etienne Carriere
2019-01-30 10:47 ` [Buildroot] [PATCH v4 2/7] optee-client: " Etienne Carriere
2019-01-30 10:47 ` [Buildroot] [PATCH v4 3/7] optee-examples: " Etienne Carriere
@ 2019-01-30 10:47 ` Etienne Carriere
2019-02-17 21:50 ` Thomas Petazzoni
2019-02-17 21:51 ` Thomas Petazzoni
2019-01-30 10:47 ` [Buildroot] [PATCH v4 5/7] optee-benchmark: " Etienne Carriere
` (3 subsequent siblings)
6 siblings, 2 replies; 25+ messages in thread
From: Etienne Carriere @ 2019-01-30 10:47 UTC (permalink / raw)
To: buildroot
OP-TEE test package provide test materials as part of the OP-TEE
project helping platforms to verify their OP-TEE components
against a set of regression and performance tests.
Package is added in the BR package configuration next to the
OP-TEE client package.
This change references in Buildroot the today's latest OP-TEE
revision release tagged 3.4.0 with an added patch to fix an issue
reported by recent GCC toolchains.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
---
Changes v3 -> v4:
- Upgrade from OP-TEE release 3.3.0 to 3.4.0. Local patches for 3.3.0
are not applicable. Add a local patch to fix a loop optimization
issue reported by recent GCC.
Changes v2 -> v3:
- Add an entry in file DEVELOPERS.
- Clean Config.in layout and description sections.
- Drop BR2_PACKAGE_OPTEE_TEST_SYNCED_VERSION.
- Clean optee-test.mk layout.
- Replace common optee-test.hash with per-version .hash files.
- Patch optee_benchmark 3.3.0 against an issue reported by GCC warns.
- Remove dependency of BR2_PACKAGE_OPTEE_EXAMPLES and Arm architecture.
As the package depends on BR2_TARGET_OPTEE_OS, leave it to optee-os
to define the supported architectures.
Changes v1 -> v2:
- Replace BR2_arm with BR2_ARM_CPU_ARMV7 as OP-TEE supports only
BR2_ARM_CPU_ARMV7 architectures among the 32bit Arm machines.
- Add missing dependency on BR2_TARGET_OPTEE_OS and select
BR2_PACKAGE_OPTEE_CLIENT when enabled.
- Add option BR2_PACKAGE_OPTEE_TEST_SYNCED_VERSION to ensure
OP-TEE test version is synced with OP-TEE OS version.
- Fix official repo URL in Config.in package description.
- Remove useless OPTEE_TEST_INSTALL_STAGING=YES.
- Do not force output build directory and rely on native one: out/.
---
DEVELOPERS | 1 +
package/Config.in | 1 +
...-regression-4100-update-string-conversion.patch | 67 ++++++++++++++++++++++
package/optee-test/3.4.0/optee-test.hash | 4 ++
package/optee-test/Config.in | 63 ++++++++++++++++++++
package/optee-test/optee-test.mk | 45 +++++++++++++++
6 files changed, 181 insertions(+)
create mode 100644 package/optee-test/3.4.0/0001-regression-4100-update-string-conversion.patch
create mode 100644 package/optee-test/3.4.0/optee-test.hash
create mode 100644 package/optee-test/Config.in
create mode 100644 package/optee-test/optee-test.mk
diff --git a/DEVELOPERS b/DEVELOPERS
index 5efb4ad..f572224 100644
--- a/DEVELOPERS
+++ b/DEVELOPERS
@@ -685,6 +685,7 @@ N: Etienne Carriere <etienne.carriere@linaro.org>
F: boot/optee-os/
F: package/optee-client/
F: package/optee-examples/
+F: package/optee-test/
N: Eugene Tarassov <eugene@largest.net>
F: package/tcf-agent/
diff --git a/package/Config.in b/package/Config.in
index 1c3ceab..fb71fe7 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -2079,6 +2079,7 @@ menu "Security"
source "package/checkpolicy/Config.in"
source "package/optee-client/Config.in"
source "package/optee-examples/Config.in"
+ source "package/optee-test/Config.in"
source "package/paxtest/Config.in"
source "package/policycoreutils/Config.in"
source "package/refpolicy/Config.in"
diff --git a/package/optee-test/3.4.0/0001-regression-4100-update-string-conversion.patch b/package/optee-test/3.4.0/0001-regression-4100-update-string-conversion.patch
new file mode 100644
index 0000000..094262d
--- /dev/null
+++ b/package/optee-test/3.4.0/0001-regression-4100-update-string-conversion.patch
@@ -0,0 +1,67 @@
+commit 662c802aa6c154a26e1d218fd768e92e6ee9a6d9
+Author: Etienne Carriere <etienne.carriere@linaro.org>
+Date: Wed Jan 30 10:13:59 2019 +0100
+
+ regression 4100: update string conversion loop
+
+ Change the loop used to convert string into numerical value.
+ The original loop was fine but its implementation hits toolchain
+ unsafe-loop-optimizations feature. The new implementation
+ proposed here simplifies a bit the loop and prevents toolchain
+ from complaining when directive -Werror=unsafe-loop-optimizations
+ is enabled.
+
+ Issue reported by the Buildroot cross toolchain [1] with the
+ following error traces:
+
+ build/armv7/build/optee-test-3.4.0/host/xtest/regression_4100.c:447:8: error: missed loop optimization, the loop counter may overflow [-Werror=unsafe-loop-optimizations]
+ while (spos) {
+ ^
+ build/optee-test-3.4.0/host/xtest/regression_4100.c:454:6: error: missed loop optimization, the loop counter may overflow [-Werror=unsafe-loop-optimizations]
+ if (!spos)
+ ^
+
+ [1] arm-buildroot-linux-uclibcgnueabihf-gcc.br_real (Buildroot 2019.02-git-00933-gb75e93c) 7.4.0
+
+ Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
+
+diff --git a/host/xtest/regression_4100.c b/host/xtest/regression_4100.c
+index b477f38..88346d4 100644
+--- a/host/xtest/regression_4100.c
++++ b/host/xtest/regression_4100.c
+@@ -445,21 +445,24 @@ static TEEC_Result convert_from_string(ADBG_Case_t *c, TEEC_Session *s,
+ return TEEC_ERROR_OUT_OF_MEMORY;
+
+ while (spos) {
+- spos--;
+- nibble = digit_value(str[spos]);
+- if (nibble == -1)
++ nibble = digit_value(str[spos - 1]);
++ if (nibble == -1) {
++ spos--;
+ break;
++ }
+ os[ospos] = nibble;
+
+- if (!spos)
+- break;
++ if (spos > 1) {
++ nibble = digit_value(str[spos - 2]);
++ if (nibble == -1) {
++ spos -= 2;
++ break;
++ }
++ os[ospos] |= nibble << 4;
++ ospos--;
++ spos--;
++ }
+ spos--;
+- nibble = digit_value(str[spos]);
+- if (nibble == -1)
+- break;
+-
+- os[ospos] |= nibble << 4;
+- ospos--;
+ }
+
+ if (spos)
diff --git a/package/optee-test/3.4.0/optee-test.hash b/package/optee-test/3.4.0/optee-test.hash
new file mode 100644
index 0000000..c8ae51b
--- /dev/null
+++ b/package/optee-test/3.4.0/optee-test.hash
@@ -0,0 +1,4 @@
+# From https://github.com/OP-TEE/optee_test/archive/3.4.0.tar.gz
+sha256 755904c5b845763a2460c32c21100a57c713009b6b88cc3fc21f0e5be8645e2b optee-test-3.4.0.tar.gz
+# Locally computed
+sha256 6e6810981f0ddab9e0d44399d0700a15d9f760a3c2843cc866659c2074139ae7 LICENSE.md
diff --git a/package/optee-test/Config.in b/package/optee-test/Config.in
new file mode 100644
index 0000000..fc9a632
--- /dev/null
+++ b/package/optee-test/Config.in
@@ -0,0 +1,63 @@
+config BR2_PACKAGE_OPTEE_TEST
+ bool "optee-test"
+ depends on BR2_TARGET_OPTEE_OS
+ select BR2_PACKAGE_OPTEE_CLIENT
+ help
+ This build option enables OP-TEE test package from the
+ OP-TEE project. It helps platforms to verify the OP-TEE
+ installation against a set of regression and performance
+ tests.
+
+ The package generates userspace test applications and
+ data files for the Linux userland. It also generates
+ OP-TEE trusted applications.
+
+ Trusted application binary files are installed in the target
+ directory /lib/optee_armtz as other trusted applications.
+ At runtime OP-TEE OS can load trusted applications from this
+ non-secure filesystem/directory into the secure world for
+ execution.
+
+ http://github.com/OP-TEE/optee_test
+
+if BR2_PACKAGE_OPTEE_TEST
+
+choice
+ prompt "version"
+ default BR2_PACKAGE_OPTEE_TEST_LATEST
+ help
+ Select the version of OP-TEE test you want to use
+
+config BR2_PACKAGE_OPTEE_TEST_LATEST
+ bool "3.4.0"
+ help
+ This fetches the registered release tag from the
+ OP-TEE official Git repository.
+
+config BR2_PACKAGE_OPTEE_TEST_CUSTOM_GIT
+ bool "Custom Git repository"
+ help
+ Sync with a specific OP-TEE Git repository.
+
+endchoice
+
+if BR2_PACKAGE_OPTEE_TEST_CUSTOM_GIT
+
+config BR2_PACKAGE_OPTEE_TEST_CUSTOM_REPO_URL
+ string "URL of custom repository"
+
+config BR2_PACKAGE_OPTEE_TEST_CUSTOM_REPO_VERSION
+ string "Custom repository version"
+ help
+ Revision to use in the typical format used by
+ Git E.G. a sha id, a tag, branch, ..
+
+endif
+
+config BR2_PACKAGE_OPTEE_TEST_VERSION
+ string
+ default "3.4.0" if BR2_PACKAGE_OPTEE_TEST_LATEST
+ default BR2_PACKAGE_OPTEE_TEST_CUSTOM_REPO_VERSION \
+ if BR2_PACKAGE_OPTEE_TEST_CUSTOM_GIT
+
+endif #BR2_PACKAGE_OPTEE_TEST
diff --git a/package/optee-test/optee-test.mk b/package/optee-test/optee-test.mk
new file mode 100644
index 0000000..0ec7238
--- /dev/null
+++ b/package/optee-test/optee-test.mk
@@ -0,0 +1,45 @@
+################################################################################
+#
+# optee-test
+#
+################################################################################
+
+OPTEE_TEST_VERSION = $(call qstrip,$(BR2_PACKAGE_OPTEE_TEST_VERSION))
+OPTEE_TEST_LICENSE = GPL-2.0, BSD-2-Clause,
+OPTEE_TEST_LICENSE_FILES = LICENSE.md
+
+OPTEE_TEST_DEPENDENCIES = optee-client optee-os
+
+ifeq ($(BR2_PACKAGE_OPTEE_TEST_CUSTOM_GIT),y)
+OPTEE_TEST_SITE = $(call qstrip,$(BR2_PACKAGE_OPTEE_TEST_CUSTOM_REPO_URL))
+OPTEE_TEST_SITE_METHOD = git
+BR_NO_CHECK_HASH_FOR += $(OPTEE_TEST_SOURCE)
+else
+OPTEE_TEST_SITE = $(call github,OP-TEE,optee_test,$(OPTEE_TEST_VERSION))
+endif
+
+ifeq ($(BR2_aarch64),y)
+OPTEE_TEST_SDK = $(STAGING_DIR)/lib/optee/export-ta_arm64
+endif
+ifeq ($(BR2_arm),y)
+OPTEE_TEST_SDK = $(STAGING_DIR)/lib/optee/export-ta_arm32
+endif
+OPTEE_TEST_CONF_OPTS = -DOPTEE_TEST_SDK=$(OPTEE_TEST_SDK)
+
+# Trusted Application are not built from CMake due to ta_dev_kit dependencies.
+# We must build and install them on target.
+define OPTEE_TEST_BUILD_TAS
+ @$(foreach f,$(wildcard $(@D)/ta/*/Makefile), \
+ $(TARGET_CONFIGURE_OPTS) \
+ $(MAKE) CROSS_COMPILE=$(TARGET_CROSS) \
+ TA_DEV_KIT_DIR=$(OPTEE_TEST_SDK) \
+ -C $(dir $f) all &&) true
+endef
+define OPTEE_TEST_INSTALL_TAS
+ @mkdir -p $(TARGET_DIR)/lib/optee_armtz
+ @$(INSTALL) -D -m 444 -t $(TARGET_DIR)/lib/optee_armtz $(@D)/ta/*/*.ta
+endef
+OPTEE_TEST_POST_BUILD_HOOKS += OPTEE_TEST_BUILD_TAS
+OPTEE_TEST_POST_INSTALL_TARGET_HOOKS += OPTEE_TEST_INSTALL_TAS
+
+$(eval $(cmake-package))
^ permalink raw reply related [flat|nested] 25+ messages in thread* [Buildroot] [PATCH v4 4/7] optee-test: new package
2019-01-30 10:47 ` [Buildroot] [PATCH v4 4/7] optee-test: " Etienne Carriere
@ 2019-02-17 21:50 ` Thomas Petazzoni
2019-02-17 21:51 ` Thomas Petazzoni
1 sibling, 0 replies; 25+ messages in thread
From: Thomas Petazzoni @ 2019-02-17 21:50 UTC (permalink / raw)
To: buildroot
On Wed, 30 Jan 2019 11:47:26 +0100
Etienne Carriere <etienne.carriere@linaro.org> wrote:
> OP-TEE test package provide test materials as part of the OP-TEE
> project helping platforms to verify their OP-TEE components
> against a set of regression and performance tests.
>
> Package is added in the BR package configuration next to the
> OP-TEE client package.
>
> This change references in Buildroot the today's latest OP-TEE
> revision release tagged 3.4.0 with an added patch to fix an issue
> reported by recent GCC toolchains.
>
> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
>
> ---
> Changes v3 -> v4:
> - Upgrade from OP-TEE release 3.3.0 to 3.4.0. Local patches for 3.3.0
> are not applicable. Add a local patch to fix a loop optimization
> issue reported by recent GCC.
Applied to next with the same changes as for optee-examples:
[Thomas:
- drop version selection
- propagate !BR2_STATIC_LIBS dependency of optee-client
- make sure BR2_TARGET_OPTEE_OS_SDK is selected
- use a patch generated by git format-patch
- simplify the construct to build the examples]
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 25+ messages in thread* [Buildroot] [PATCH v4 4/7] optee-test: new package
2019-01-30 10:47 ` [Buildroot] [PATCH v4 4/7] optee-test: " Etienne Carriere
2019-02-17 21:50 ` Thomas Petazzoni
@ 2019-02-17 21:51 ` Thomas Petazzoni
2019-02-19 7:18 ` Etienne Carriere
1 sibling, 1 reply; 25+ messages in thread
From: Thomas Petazzoni @ 2019-02-17 21:51 UTC (permalink / raw)
To: buildroot
Hello,
On Wed, 30 Jan 2019 11:47:26 +0100
Etienne Carriere <etienne.carriere@linaro.org> wrote:
> +ifeq ($(BR2_aarch64),y)
> +OPTEE_TEST_SDK = $(STAGING_DIR)/lib/optee/export-ta_arm64
> +endif
> +ifeq ($(BR2_arm),y)
> +OPTEE_TEST_SDK = $(STAGING_DIR)/lib/optee/export-ta_arm32
> +endif
Second thought about this: this the SDK is installed by OPTEE-OS, it
should perhaps be boot/optee-os/optee-os.mk that provides a variable
pointing to the SDK. It can then be used by all packages that use the
SDK instead of duplicating this OPTEE-OS specific knowledge in all
users of the SDK.
Could you fix this by a set of follow-up patches ?
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] [PATCH v4 4/7] optee-test: new package
2019-02-17 21:51 ` Thomas Petazzoni
@ 2019-02-19 7:18 ` Etienne Carriere
0 siblings, 0 replies; 25+ messages in thread
From: Etienne Carriere @ 2019-02-19 7:18 UTC (permalink / raw)
To: buildroot
On Sun, 17 Feb 2019 at 22:51, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello,
>
> On Wed, 30 Jan 2019 11:47:26 +0100
> Etienne Carriere <etienne.carriere@linaro.org> wrote:
>
> > +ifeq ($(BR2_aarch64),y)
> > +OPTEE_TEST_SDK = $(STAGING_DIR)/lib/optee/export-ta_arm64
> > +endif
> > +ifeq ($(BR2_arm),y)
> > +OPTEE_TEST_SDK = $(STAGING_DIR)/lib/optee/export-ta_arm32
> > +endif
>
> Second thought about this: this the SDK is installed by OPTEE-OS, it
> should perhaps be boot/optee-os/optee-os.mk that provides a variable
> pointing to the SDK. It can then be used by all packages that use the
> SDK instead of duplicating this OPTEE-OS specific knowledge in all
> users of the SDK.
>
> Could you fix this by a set of follow-up patches ?
Ok, will do. Indeed would look better.
Regards,
Etienne
>
> Thanks!
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] [PATCH v4 5/7] optee-benchmark: new package
2019-01-30 10:47 [Buildroot] [PATCH v4 1/7] boot/optee-os: new package Etienne Carriere
` (2 preceding siblings ...)
2019-01-30 10:47 ` [Buildroot] [PATCH v4 4/7] optee-test: " Etienne Carriere
@ 2019-01-30 10:47 ` Etienne Carriere
2019-02-17 22:08 ` Thomas Petazzoni
2019-01-30 10:47 ` [Buildroot] [PATCH v4 6/7] configs/qemu_armv7a_tz_virt: Armv7-A emulation with TrustZone services Etienne Carriere
` (2 subsequent siblings)
6 siblings, 1 reply; 25+ messages in thread
From: Etienne Carriere @ 2019-01-30 10:47 UTC (permalink / raw)
To: buildroot
OP-TEE performance benchmark tools for the OP-TEE project.
This packages generates embedded Linux based OS materials used
to retrieve execution timing information on invocation of the
OP-TEE secure services.
It is added next to the OP-TEE client package in BR configuration.
This change references in Buildroot the today's latest OP-TEE
revision release tagged 3.4.0.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
---
Changes v3 -> v4:
- Upgrade from OP-TEE release 3.3.0 to 3.4.0. No local patch required.
Changes v2 -> v3:
- Add an entry in file DEVELOPERS.
- Clean Config.in layout and description sections.
- Drop BR2_PACKAGE_OPTEE_BENCHMARK_SYNCED_VERSION.
- Clean optee-benchmark.mk layout.
- Replace common optee-benchmark.hash with per-version .hash files.
- Add a patch on 3.3.0 to fix an issue reported through GCC warns.
Changes v1 -> v2:
- Add dependency on OP-TEE client.
- Add option BR2_PACKAGE_OPTEE_BENCHMARK_SYNCED_VERSION to ensure
OP-TEE benchmark version is synced with OP-TEE client version.
- Remove useless OPTEE_BENCHMARK_INSTALL_STAGING and
OPTEE_BENCHMARK_INSTALL_IMAGES.
- Remove unused BR2_PACKAGE_OPTEE_BENCHMARK_GIT_REFERENCE.
- Remove useless _INSTALL_STAGING/_INSTALL_IMAGES=YES.
---
DEVELOPERS | 1 +
package/Config.in | 1 +
package/optee-benchmark/3.4.0/optee-benchmark.hash | 2 +
package/optee-benchmark/Config.in | 55 ++++++++++++++++++++++
package/optee-benchmark/optee-benchmark.mk | 22 +++++++++
5 files changed, 81 insertions(+)
create mode 100644 package/optee-benchmark/3.4.0/optee-benchmark.hash
create mode 100644 package/optee-benchmark/Config.in
create mode 100644 package/optee-benchmark/optee-benchmark.mk
diff --git a/DEVELOPERS b/DEVELOPERS
index f572224..ef359c9 100644
--- a/DEVELOPERS
+++ b/DEVELOPERS
@@ -683,6 +683,7 @@ F: package/szip/
N: Etienne Carriere <etienne.carriere@linaro.org>
F: boot/optee-os/
+F: package/optee-benchmark/
F: package/optee-client/
F: package/optee-examples/
F: package/optee-test/
diff --git a/package/Config.in b/package/Config.in
index fb71fe7..c9b1178 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -2077,6 +2077,7 @@ endmenu
menu "Security"
source "package/checkpolicy/Config.in"
+ source "package/optee-benchmark/Config.in"
source "package/optee-client/Config.in"
source "package/optee-examples/Config.in"
source "package/optee-test/Config.in"
diff --git a/package/optee-benchmark/3.4.0/optee-benchmark.hash b/package/optee-benchmark/3.4.0/optee-benchmark.hash
new file mode 100644
index 0000000..c3c41b6
--- /dev/null
+++ b/package/optee-benchmark/3.4.0/optee-benchmark.hash
@@ -0,0 +1,2 @@
+# From https://github.com/linaro-swg/optee_benchmark/archive/3.4.0.tar.gz
+sha256 e5e868a06a9dcc8cc444b3e72c65f57670b0811091be62edbe0d03d13c75e716 optee-benchmark-3.4.0.tar.gz
diff --git a/package/optee-benchmark/Config.in b/package/optee-benchmark/Config.in
new file mode 100644
index 0000000..b3a598e
--- /dev/null
+++ b/package/optee-benchmark/Config.in
@@ -0,0 +1,55 @@
+config BR2_PACKAGE_OPTEE_BENCHMARK
+ bool "optee-benchmark"
+ select BR2_PACKAGE_OPTEE_CLIENT
+ select BR2_PACKAGE_LIBYAML
+ help
+ Enable the OP-TEE benchmark package that brings facilities
+ for profiling traversal and execution timings when
+ invoking OP-TEE. OP-TEE benchmark is a component delivered
+ by the OP-TEE project.
+
+ http://github.com/linaro-swg/optee_benchmark
+
+if BR2_PACKAGE_OPTEE_BENCHMARK
+
+choice
+ prompt "version"
+ default BR2_PACKAGE_OPTEE_BENCHMARK_LATEST
+ help
+ Select the version of OP-TEE benchmark you want to use
+
+config BR2_PACKAGE_OPTEE_BENCHMARK_LATEST
+ bool "3.4.0"
+ help
+ This fetches the registered release tag from the
+ OP-TEE official Git repository.
+
+config BR2_PACKAGE_OPTEE_BENCHMARK_CUSTOM_GIT
+ bool "Custom Git repository"
+ help
+ Sync with a specific OP-TEE Git repository.
+
+endchoice
+
+if BR2_PACKAGE_OPTEE_BENCHMARK_CUSTOM_GIT
+
+config BR2_PACKAGE_OPTEE_BENCHMARK_CUSTOM_REPO_URL
+ string "URL of custom repository"
+ help
+ Specific location of the reference source tree Git repository.
+
+config BR2_PACKAGE_OPTEE_BENCHMARK_CUSTOM_REPO_VERSION
+ string "Custom repository version"
+ help
+ Revision to use in the typical format used by
+ Git E.G. a sha id, a tag, branch, ..
+
+endif
+
+config BR2_PACKAGE_OPTEE_BENCHMARK_VERSION
+ string
+ default "3.4.0" if BR2_PACKAGE_OPTEE_BENCHMARK_LATEST
+ default BR2_PACKAGE_OPTEE_BENCHMARK_CUSTOM_REPO_VERSION \
+ if BR2_PACKAGE_OPTEE_BENCHMARK_CUSTOM_GIT
+
+endif #BR2_PACKAGE_OPTEE_BENCHMARK
diff --git a/package/optee-benchmark/optee-benchmark.mk b/package/optee-benchmark/optee-benchmark.mk
new file mode 100644
index 0000000..8eef0f6
--- /dev/null
+++ b/package/optee-benchmark/optee-benchmark.mk
@@ -0,0 +1,22 @@
+################################################################################
+#
+# optee-benchmarch
+#
+################################################################################
+
+OPTEE_BENCHMARK_VERSION = $(call qstrip,$(BR2_PACKAGE_OPTEE_BENCHMARK_VERSION))
+OPTEE_BENCHMARK_LICENSE = BSD-2-Clause
+
+OPTEE_BENCHMARK_DEPENDENCIES = optee-client libyaml
+
+ifeq ($(BR2_PACKAGE_OPTEE_BENCHMARK_LATEST),y)
+OPTEE_BENCHMARK_SITE = $(call github,linaro-swg,optee_benchmark,$(OPTEE_BENCHMARK_VERSION))
+endif
+
+ifeq ($(BR2_PACKAGE_OPTEE_BENCHMARK_CUSTOM_GIT),y)
+OPTEE_BENCHMARK_SITE = $(call qstrip,$(BR2_PACKAGE_OPTEE_BENCHMARK_CUSTOM_REPO_URL))
+OPTEE_BENCHMARK_SITE_METHOD = git
+BR_NO_CHECK_HASH_FOR += $(OPTEE_BENCHMARK_SOURCE)
+endif
+
+$(eval $(cmake-package))
^ permalink raw reply related [flat|nested] 25+ messages in thread* [Buildroot] [PATCH v4 5/7] optee-benchmark: new package
2019-01-30 10:47 ` [Buildroot] [PATCH v4 5/7] optee-benchmark: " Etienne Carriere
@ 2019-02-17 22:08 ` Thomas Petazzoni
2019-02-19 7:26 ` Etienne Carriere
0 siblings, 1 reply; 25+ messages in thread
From: Thomas Petazzoni @ 2019-02-17 22:08 UTC (permalink / raw)
To: buildroot
Hello,
On Wed, 30 Jan 2019 11:47:27 +0100
Etienne Carriere <etienne.carriere@linaro.org> wrote:
> OP-TEE performance benchmark tools for the OP-TEE project.
>
> This packages generates embedded Linux based OS materials used
> to retrieve execution timing information on invocation of the
> OP-TEE secure services.
>
> It is added next to the OP-TEE client package in BR configuration.
>
> This change references in Buildroot the today's latest OP-TEE
> revision release tagged 3.4.0.
>
> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
>
> ---
> Changes v3 -> v4:
> - Upgrade from OP-TEE release 3.3.0 to 3.4.0. No local patch required.
I have applied to next with the following changes:
[Thomas:
- drop version selection
- propagate the dependency of optee-client]
Another thing I noticed is that your .hash files do not have the hashes
for the license files. Could you send a patch adding those ?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 25+ messages in thread* [Buildroot] [PATCH v4 5/7] optee-benchmark: new package
2019-02-17 22:08 ` Thomas Petazzoni
@ 2019-02-19 7:26 ` Etienne Carriere
2019-03-05 8:02 ` Etienne Carriere
0 siblings, 1 reply; 25+ messages in thread
From: Etienne Carriere @ 2019-02-19 7:26 UTC (permalink / raw)
To: buildroot
On Sun, 17 Feb 2019 at 23:08, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello,
>
> On Wed, 30 Jan 2019 11:47:27 +0100
> Etienne Carriere <etienne.carriere@linaro.org> wrote:
>
> > OP-TEE performance benchmark tools for the OP-TEE project.
> >
> > This packages generates embedded Linux based OS materials used
> > to retrieve execution timing information on invocation of the
> > OP-TEE secure services.
> >
> > It is added next to the OP-TEE client package in BR configuration.
> >
> > This change references in Buildroot the today's latest OP-TEE
> > revision release tagged 3.4.0.
> >
> > Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
> >
> > ---
> > Changes v3 -> v4:
> > - Upgrade from OP-TEE release 3.3.0 to 3.4.0. No local patch required.
>
> I have applied to next with the following changes:
>
> [Thomas:
> - drop version selection
> - propagate the dependency of optee-client]
>
> Another thing I noticed is that your .hash files do not have the hashes
> for the license files. Could you send a patch adding those ?
Sure, will do.
Thanks,
etienne
>
> Thanks,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] [PATCH v4 5/7] optee-benchmark: new package
2019-02-19 7:26 ` Etienne Carriere
@ 2019-03-05 8:02 ` Etienne Carriere
0 siblings, 0 replies; 25+ messages in thread
From: Etienne Carriere @ 2019-03-05 8:02 UTC (permalink / raw)
To: buildroot
On Tue, 19 Feb 2019 at 08:26, Etienne Carriere
<etienne.carriere@linaro.org> wrote:
>
> On Sun, 17 Feb 2019 at 23:08, Thomas Petazzoni
> <thomas.petazzoni@bootlin.com> wrote:
> >
> > Hello,
> >
> > On Wed, 30 Jan 2019 11:47:27 +0100
> > Etienne Carriere <etienne.carriere@linaro.org> wrote:
> >
> > > OP-TEE performance benchmark tools for the OP-TEE project.
> > >
> > > This packages generates embedded Linux based OS materials used
> > > to retrieve execution timing information on invocation of the
> > > OP-TEE secure services.
> > >
> > > It is added next to the OP-TEE client package in BR configuration.
> > >
> > > This change references in Buildroot the today's latest OP-TEE
> > > revision release tagged 3.4.0.
> > >
> > > Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
> > >
> > > ---
> > > Changes v3 -> v4:
> > > - Upgrade from OP-TEE release 3.3.0 to 3.4.0. No local patch required.
> >
> > I have applied to next with the following changes:
> >
> > [Thomas:
> > - drop version selection
> > - propagate the dependency of optee-client]
> >
> > Another thing I noticed is that your .hash files do not have the hashes
> > for the license files. Could you send a patch adding those ?
>
> Sure, will do.
For info, the package currently lacks of LICENSE file.
This should be fixed in next OP-TEE release 3.5.0.
Hash file will be updated when bumping to that version.
Regards,
etienne
>
> Thanks,
> etienne
>
> >
> > Thanks,
> >
> > Thomas
> > --
> > Thomas Petazzoni, CTO, Bootlin
> > Embedded Linux and Kernel engineering
> > https://bootlin.com
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] [PATCH v4 6/7] configs/qemu_armv7a_tz_virt: Armv7-A emulation with TrustZone services
2019-01-30 10:47 [Buildroot] [PATCH v4 1/7] boot/optee-os: new package Etienne Carriere
` (3 preceding siblings ...)
2019-01-30 10:47 ` [Buildroot] [PATCH v4 5/7] optee-benchmark: " Etienne Carriere
@ 2019-01-30 10:47 ` Etienne Carriere
2019-02-17 22:12 ` Thomas Petazzoni
2019-01-30 10:47 ` [Buildroot] [PATCH v4 7/7] configs/qemu_aarch64_tz_virt: AArch64 " Etienne Carriere
2019-02-10 16:14 ` [Buildroot] [PATCH v4 1/7] boot/optee-os: new package Thomas Petazzoni
6 siblings, 1 reply; 25+ messages in thread
From: Etienne Carriere @ 2019-01-30 10:47 UTC (permalink / raw)
To: buildroot
This change introduces a Qemu board for an Armv7-A target executing
with OP-TEE secure world services.
The target Linux based normal world embeds the standard minimal
filesystem with OP-TEE non-secure components embedded files from
OP-TEE test, examples and benchmark packages.
The Linux custom configuration is dumped from the vexpress_defconfig
with few added fragments: OP-TEE driver and 9p for virtual filesystem to
ease file manipulation and exchanges through Qemu virtfs support.
The standard way for booting OP-TEE with a non-secure world companion
use the Arm Trusted Firmware-A as bootloader. OP-TEE OS provides the
BL32 image and U-boot the BL33 image. The proposed board enables OP-TEE
and U-boot build for this. However package boot/arm-trusted-firmware
needs few change support building Armv7-A targets.
Therefore the proposed board allows one to build the images but not
yet to run the target with the built Qemu host tool.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
---
Changes v3 -> v4
- No change.
Changes v2 -> v3
- New change to introduce a board that at least builds Armv7-A OP-TEE.
---
board/qemu/armv7a-tz-virt/linux.config | 167 ++++++++++++++++++++++++++++++++
board/qemu/armv7a-tz-virt/readme.txt | 11 +++
board/qemu/armv7a-tz-virt/u-boot.config | 3 +
configs/qemu_armv7a_tz_virt_defconfig | 41 ++++++++
4 files changed, 222 insertions(+)
create mode 100644 board/qemu/armv7a-tz-virt/linux.config
create mode 100644 board/qemu/armv7a-tz-virt/readme.txt
create mode 100644 board/qemu/armv7a-tz-virt/u-boot.config
create mode 100644 configs/qemu_armv7a_tz_virt_defconfig
diff --git a/board/qemu/armv7a-tz-virt/linux.config b/board/qemu/armv7a-tz-virt/linux.config
new file mode 100644
index 0000000..62ece0c
--- /dev/null
+++ b/board/qemu/armv7a-tz-virt/linux.config
@@ -0,0 +1,167 @@
+# CONFIG_LOCALVERSION_AUTO is not set
+CONFIG_SYSVIPC=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=14
+CONFIG_CGROUPS=y
+CONFIG_CPUSETS=y
+# CONFIG_UTS_NS is not set
+# CONFIG_IPC_NS is not set
+# CONFIG_PID_NS is not set
+# CONFIG_NET_NS is not set
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_PROFILING=y
+CONFIG_OPROFILE=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+# CONFIG_LBDAF is not set
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_IOSCHED_DEADLINE is not set
+# CONFIG_IOSCHED_CFQ is not set
+CONFIG_ARCH_VEXPRESS=y
+CONFIG_ARCH_VEXPRESS_DCSCB=y
+CONFIG_ARCH_VEXPRESS_TC2_PM=y
+# CONFIG_SWP_EMULATE is not set
+CONFIG_SMP=y
+CONFIG_HAVE_ARM_ARCH_TIMER=y
+CONFIG_MCPM=y
+CONFIG_VMSPLIT_2G=y
+CONFIG_NR_CPUS=8
+CONFIG_ARM_PSCI=y
+CONFIG_AEABI=y
+CONFIG_CMA=y
+CONFIG_ZBOOT_ROM_TEXT=0x0
+CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_CMDLINE="console=ttyAMA0"
+CONFIG_CPU_IDLE=y
+CONFIG_CPU_IDLE_MULTIPLE_DRIVERS=y
+CONFIG_VFP=y
+CONFIG_NEON=y
+# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_IP_PNP_BOOTP=y
+# CONFIG_IPV6 is not set
+# CONFIG_WIRELESS is not set
+CONFIG_NET_9P=y
+CONFIG_NET_9P_VIRTIO=y
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_DEVTMPFS=y
+CONFIG_MTD=y
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_CFI_INTELEXT=y
+CONFIG_MTD_CFI_AMDSTD=y
+CONFIG_MTD_PHYSMAP=y
+CONFIG_MTD_PHYSMAP_OF=y
+CONFIG_MTD_PLATRAM=y
+CONFIG_MTD_UBI=y
+CONFIG_PROC_DEVICETREE=y
+CONFIG_VIRTIO_BLK=y
+# CONFIG_SCSI_PROC_FS is not set
+CONFIG_BLK_DEV_SD=y
+CONFIG_SCSI_VIRTIO=y
+CONFIG_ATA=y
+# CONFIG_SATA_PMP is not set
+CONFIG_NETDEVICES=y
+CONFIG_VIRTIO_NET=y
+CONFIG_SMC91X=y
+CONFIG_SMSC911X=y
+# CONFIG_WLAN is not set
+CONFIG_INPUT_EVDEV=y
+# CONFIG_SERIO_SERPORT is not set
+CONFIG_SERIO_AMBAKMI=y
+CONFIG_LEGACY_PTY_COUNT=16
+CONFIG_SERIAL_AMBA_PL011=y
+CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
+CONFIG_VIRTIO_CONSOLE=y
+CONFIG_HW_RANDOM=y
+CONFIG_HW_RANDOM_VIRTIO=y
+CONFIG_I2C=y
+CONFIG_I2C_VERSATILE=y
+CONFIG_SENSORS_VEXPRESS=y
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_VEXPRESS=y
+CONFIG_FB=y
+CONFIG_FB_ARMCLCD=y
+CONFIG_FRAMEBUFFER_CONSOLE=y
+CONFIG_LOGO=y
+# CONFIG_LOGO_LINUX_MONO is not set
+# CONFIG_LOGO_LINUX_VGA16 is not set
+CONFIG_SOUND=y
+CONFIG_SND=y
+CONFIG_SND_MIXER_OSS=y
+CONFIG_SND_PCM_OSS=y
+# CONFIG_SND_DRIVERS is not set
+CONFIG_SND_ARMAACI=y
+CONFIG_HID_DRAGONRISE=y
+CONFIG_HID_GYRATION=y
+CONFIG_HID_TWINHAN=y
+CONFIG_HID_NTRIG=y
+CONFIG_HID_PANTHERLORD=y
+CONFIG_HID_PETALYNX=y
+CONFIG_HID_SAMSUNG=y
+CONFIG_HID_SONY=y
+CONFIG_HID_SUNPLUS=y
+CONFIG_HID_GREENASIA=y
+CONFIG_HID_SMARTJOYPLUS=y
+CONFIG_HID_TOPSEED=y
+CONFIG_HID_THRUSTMASTER=y
+CONFIG_HID_ZEROPLUS=y
+CONFIG_USB=y
+CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
+CONFIG_USB_MON=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_ISP1760=y
+CONFIG_MMC=y
+CONFIG_MMC_ARMMMCI=y
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_HEARTBEAT=y
+CONFIG_LEDS_TRIGGER_CPU=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_PL031=y
+CONFIG_VIRTIO_BALLOON=y
+CONFIG_VIRTIO_MMIO=y
+CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES=y
+CONFIG_EXT2_FS=y
+CONFIG_EXT3_FS=y
+# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
+# CONFIG_EXT3_FS_XATTR is not set
+CONFIG_EXT4_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_TMPFS=y
+#CONFIG_JFFS2_FS is not set
+CONFIG_UBIFS_FS=y
+CONFIG_CRAMFS=y
+CONFIG_SQUASHFS=y
+CONFIG_SQUASHFS_LZO=y
+CONFIG_NFS_FS=y
+CONFIG_ROOT_NFS=y
+CONFIG_9P_FS=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_DEBUG_INFO=y
+CONFIG_DEBUG_FS=y
+CONFIG_MAGIC_SYSRQ=y
+CONFIG_DEBUG_KERNEL=y
+CONFIG_DETECT_HUNG_TASK=y
+# CONFIG_SCHED_DEBUG is not set
+CONFIG_DEBUG_USER=y
+# CONFIG_CRYPTO_ANSI_CPRNG is not set
+# CONFIG_CRYPTO_HW is not set
+### Enable OP-TEE
+CONFIG_TEE=y
+CONFIG_OPTEE=y
+### Enable 9P VFS
+CONFIG_NET_9P=y
+CONFIG_NET_9P_VIRTIO=y
+CONFIG_9P_FS=y
+CONFIG_9P_FS_POSIX_ACL=y
diff --git a/board/qemu/armv7a-tz-virt/readme.txt b/board/qemu/armv7a-tz-virt/readme.txt
new file mode 100644
index 0000000..06b728f
--- /dev/null
+++ b/board/qemu/armv7a-tz-virt/readme.txt
@@ -0,0 +1,11 @@
+Board qemu_armv7a_tz_virt builds a Qemu Armv7-A target with
+OP-TEE running in the TrustZone secure world setup and a Linux based
+OS running in the non-secure world.
+
+This setup is usually booted with the Arm Trsuted Firmware-A (TF-A from
+package boot/arm-trusted-firmware). However the current Buildroot package
+needs few changes to build TF-A for OP-TEE support.
+
+Until BR arm-trusted-firmware is updated this board allows one to only
+build the secure and non-secure boot images if not the BIOS for the Qemu
+host.
diff --git a/board/qemu/armv7a-tz-virt/u-boot.config b/board/qemu/armv7a-tz-virt/u-boot.config
new file mode 100644
index 0000000..5588008
--- /dev/null
+++ b/board/qemu/armv7a-tz-virt/u-boot.config
@@ -0,0 +1,3 @@
+CONFIG_SYS_TEXT_BASE=0x60000000
+CONFIG_BOOTCOMMAND="fdt addr ${fdt_addr} && fdt resize 1000 && smhload zImage ${kernel_addr_r} && smhload rootfs.cpio.gz ${ramdisk_addr_r} ramdisk_addr_end && setenv bootargs console=ttyAMA0,115200 earlyprintk=serial,ttyAMA0,115200 && fdt chosen ${ramdisk_addr_r} ${ramdisk_addr_end} && bootz ${kernel_addr_r} - ${fdt_addr}"
+CONFIG_SEMIHOSTING=y
diff --git a/configs/qemu_armv7a_tz_virt_defconfig b/configs/qemu_armv7a_tz_virt_defconfig
new file mode 100644
index 0000000..ab52480
--- /dev/null
+++ b/configs/qemu_armv7a_tz_virt_defconfig
@@ -0,0 +1,41 @@
+# Architecture
+BR2_arm=y
+BR2_cortex_a15=y
+BR2_ARM_ENABLE_NEON=y
+BR2_ARM_ENABLE_VFP=y
+BR2_ARM_FPU_VFPV3D16=y
+# System
+BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
+# Filesystem
+BR2_TARGET_ROOTFS_CPIO=y
+BR2_TARGET_ROOTFS_CPIO_GZIP=y
+BR2_TARGET_ROOTFS_EXT2=y
+# Linux 4.16 series
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_16=y
+BR2_LINUX_KERNEL=y
+BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
+BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/armv7a-tz-virt/linux.config"
+BR2_LINUX_KERNEL_CUSTOM_VERSION=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.16.7"
+BR2_LINUX_KERNEL_DEFCONFIG="vexpress"
+BR2_LINUX_KERNEL_DTS_SUPPORT=y
+BR2_LINUX_KERNEL_INTREE_DTS_NAME="vexpress-v2p-ca15_a7"
+# TF-A for booting OP-TEE secure and uboot/linux non secure
+# POSTPONED: depends on boot/arm-trusted-firmware support for Armv7-A
+# OP-TEE components
+BR2_TARGET_OPTEE_OS=y
+BR2_TARGET_OPTEE_OS_PLATFORM="vexpress-qemu_virt"
+BR2_TARGET_OPTEE_OS_ADDITIONAL_VARIABLES="CFG_TEE_CORE_DEBUG=n CFG_UNWIND=n CFG_TEE_CORE_LOG_LEVEL=2"
+BR2_PACKAGE_OPTEE_CLIENT=y
+BR2_PACKAGE_OPTEE_TEST=y
+BR2_PACKAGE_OPTEE_EXAMPLES=y
+BR2_PACKAGE_OPTEE_BENCHMARK=y
+# U-boot for booting the dear Linux kernel
+BR2_TARGET_UBOOT=y
+BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y
+BR2_TARGET_UBOOT_BOARD_DEFCONFIG="qemu_arm"
+BR2_TARGET_UBOOT_CONFIG_FRAGMENT_FILES="board/qemu/armv7a-tz-virt/u-boot.config"
+# Qemu emulator for the Arm target
+BR2_PACKAGE_HOST_QEMU=y
+BR2_PACKAGE_HOST_QEMU_SYSTEM_MODE=y
+BR2_PACKAGE_HOST_QEMU_VIRTFS=y
^ permalink raw reply related [flat|nested] 25+ messages in thread* [Buildroot] [PATCH v4 6/7] configs/qemu_armv7a_tz_virt: Armv7-A emulation with TrustZone services
2019-01-30 10:47 ` [Buildroot] [PATCH v4 6/7] configs/qemu_armv7a_tz_virt: Armv7-A emulation with TrustZone services Etienne Carriere
@ 2019-02-17 22:12 ` Thomas Petazzoni
2019-02-18 18:14 ` Yann E. MORIN
2019-02-19 8:31 ` Arnout Vandecappelle
0 siblings, 2 replies; 25+ messages in thread
From: Thomas Petazzoni @ 2019-02-17 22:12 UTC (permalink / raw)
To: buildroot
Hello,
On Wed, 30 Jan 2019 11:47:28 +0100
Etienne Carriere <etienne.carriere@linaro.org> wrote:
> This change introduces a Qemu board for an Armv7-A target executing
> with OP-TEE secure world services.
>
> The target Linux based normal world embeds the standard minimal
> filesystem with OP-TEE non-secure components embedded files from
> OP-TEE test, examples and benchmark packages.
>
> The Linux custom configuration is dumped from the vexpress_defconfig
> with few added fragments: OP-TEE driver and 9p for virtual filesystem to
> ease file manipulation and exchanges through Qemu virtfs support.
>
> The standard way for booting OP-TEE with a non-secure world companion
> use the Arm Trusted Firmware-A as bootloader. OP-TEE OS provides the
> BL32 image and U-boot the BL33 image. The proposed board enables OP-TEE
> and U-boot build for this. However package boot/arm-trusted-firmware
> needs few change support building Armv7-A targets.
>
> Therefore the proposed board allows one to build the images but not
> yet to run the target with the built Qemu host tool.
>
> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
I don't know what is the opinion of Peter, Arnout and Yann, but I think
this PATCH 6/7 and PATCH 7/7, instead of adding more defconfigs should
instead add test cases to our runtime test infrastructure in
support/testing/. Indeed:
- We probably don't want to have Qemu defconfigs for every possible
feature in Buildroot
- A runtime test case, even if it's indeed a bit less visible than a
defconfig, still documents a configuration that "works" for a given
feature.
- A runtime test case allows to really runtime test the feature by
booting Qemu.
Etienne, would you be willing to convert those two configurations to
the runtime test infrastructure ?
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] [PATCH v4 6/7] configs/qemu_armv7a_tz_virt: Armv7-A emulation with TrustZone services
2019-02-17 22:12 ` Thomas Petazzoni
@ 2019-02-18 18:14 ` Yann E. MORIN
2019-02-18 21:28 ` Etienne Carriere
2019-02-19 8:31 ` Arnout Vandecappelle
1 sibling, 1 reply; 25+ messages in thread
From: Yann E. MORIN @ 2019-02-18 18:14 UTC (permalink / raw)
To: buildroot
Thomas, Etienne, All,
On 2019-02-17 23:12 +0100, Thomas Petazzoni spake thusly:
> On Wed, 30 Jan 2019 11:47:28 +0100
> Etienne Carriere <etienne.carriere@linaro.org> wrote:
> > This change introduces a Qemu board for an Armv7-A target executing
> > with OP-TEE secure world services.
> I don't know what is the opinion of Peter, Arnout and Yann, but I think
> this PATCH 6/7 and PATCH 7/7, instead of adding more defconfigs should
> instead add test cases to our runtime test infrastructure in
> support/testing/. Indeed:
>
> - We probably don't want to have Qemu defconfigs for every possible
> feature in Buildroot
However, I would not be opposed to having _one_ defconfig that can be
used as a reference / starting-point.
> - A runtime test case, even if it's indeed a bit less visible than a
> defconfig, still documents a configuration that "works" for a given
> feature.
> - A runtime test case allows to really runtime test the feature by
> booting Qemu.
Agreed: adding a runtiem test should indeed be provided, whether we have
a defconfig or not.
Regards,
Yann E. MORIN.
> Etienne, would you be willing to convert those two configurations to
> the runtime test infrastructure ?
>
> Thanks!
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] [PATCH v4 6/7] configs/qemu_armv7a_tz_virt: Armv7-A emulation with TrustZone services
2019-02-18 18:14 ` Yann E. MORIN
@ 2019-02-18 21:28 ` Etienne Carriere
2019-02-18 21:43 ` Thomas Petazzoni
0 siblings, 1 reply; 25+ messages in thread
From: Etienne Carriere @ 2019-02-18 21:28 UTC (permalink / raw)
To: buildroot
Hello all,
On Mon, 18 Feb 2019 at 19:14, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
>
> Thomas, Etienne, All,
>
> On 2019-02-17 23:12 +0100, Thomas Petazzoni spake thusly:
> > On Wed, 30 Jan 2019 11:47:28 +0100
> > Etienne Carriere <etienne.carriere@linaro.org> wrote:
> > > This change introduces a Qemu board for an Armv7-A target executing
> > > with OP-TEE secure world services.
> > I don't know what is the opinion of Peter, Arnout and Yann, but I think
> > this PATCH 6/7 and PATCH 7/7, instead of adding more defconfigs should
> > instead add test cases to our runtime test infrastructure in
> > support/testing/. Indeed:
> >
> > - We probably don't want to have Qemu defconfigs for every possible
> > feature in Buildroot
>
> However, I would not be opposed to having _one_ defconfig that can be
> used as a reference / starting-point.
Is the Qemu emulator the best candidate for such starting point.
I think it is as one can use it to experience Arm specific OP-TEE
package without needing specific HW but a standard Linux host.
I would have preferred proposing a change in the already available
Qemu Armv7 as qemu_arm_vexpress_defconfig is but I fear enabling
TrustZone support in Qemu will break other nice Qemu features ones
are used to (graphics?).
Maybe I can find a real HW for which BR can store a defconfig that
enables OP-TEE.
> > - A runtime test case, even if it's indeed a bit less visible than a
> > defconfig, still documents a configuration that "works" for a given
> > feature.
> > - A runtime test case allows to really runtime test the feature by
> > booting Qemu.
>
> Agreed: adding a runtiem test should indeed be provided, whether we have
> a defconfig or not.
>
>
> Regards,
> Yann E. MORIN.
>
> > Etienne, would you be willing to convert those two configurations to
> > the runtime test infrastructure ?
I think I can prepare that. Or I will ask few help on the ML if I
can't find my way.
The initial intention when adding these defconfig to my patch series was to
answer a request from patch v3 (i think) review where Thomas asked for
something that could b used to check OP-TEE at least builds, if possible boots,
from a BR build. I understand that maybe you though more of such
runtime test, rather than a defconfig.
Regards,
etienne
>
> >
> > Thanks!
> >
> > Thomas
> > --
> > Thomas Petazzoni, CTO, Bootlin
> > Embedded Linux and Kernel engineering
> > https://bootlin.com
>
> --
> .-----------------.--------------------.------------------.--------------------.
> | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
> | +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
> '------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] [PATCH v4 6/7] configs/qemu_armv7a_tz_virt: Armv7-A emulation with TrustZone services
2019-02-18 21:28 ` Etienne Carriere
@ 2019-02-18 21:43 ` Thomas Petazzoni
0 siblings, 0 replies; 25+ messages in thread
From: Thomas Petazzoni @ 2019-02-18 21:43 UTC (permalink / raw)
To: buildroot
Hello,
On Mon, 18 Feb 2019 22:28:10 +0100
Etienne Carriere <etienne.carriere@linaro.org> wrote:
> > However, I would not be opposed to having _one_ defconfig that can be
> > used as a reference / starting-point.
>
> Is the Qemu emulator the best candidate for such starting point.
> I think it is as one can use it to experience Arm specific OP-TEE
> package without needing specific HW but a standard Linux host.
>
> I would have preferred proposing a change in the already available
> Qemu Armv7 as qemu_arm_vexpress_defconfig is but I fear enabling
> TrustZone support in Qemu will break other nice Qemu features ones
> are used to (graphics?).
>
> Maybe I can find a real HW for which BR can store a defconfig that
> enables OP-TEE.
I think Yann didn't say that a Qemu defconfig was not good, he said
quite the opposite: that having one Qemu defconfig that uses OP-TEE
would be useful.
Note: I am not sure I agree because if we go down this road, we would
have lots of Qemu defconfigs demonstrating lots of different features.
> > > Etienne, would you be willing to convert those two configurations to
> > > the runtime test infrastructure ?
>
> I think I can prepare that. Or I will ask few help on the ML if I
> can't find my way.
Sure, feel free to ask questions. The runtime test infrastructure is
not documented, but there are numerous existing test cases that you
should help you getting started.
You can list existing tests by doing:
./support/testing/run-tests -l
and run one specific test by doing:
./support/testing/run-tests -d /path/to/some/build/dir tests.fs.test_ext.TestExt2
Option -k is really useful during development, as it keeps the build
artifacts instead of removing them once the test is completed.
> The initial intention when adding these defconfig to my patch series
> was to answer a request from patch v3 (i think) review where Thomas
> asked for something that could b used to check OP-TEE at least
> builds, if possible boots, from a BR build. I understand that maybe
> you though more of such runtime test, rather than a defconfig.
Yeah, maybe I wasn't clear back then, sorry about that.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] [PATCH v4 6/7] configs/qemu_armv7a_tz_virt: Armv7-A emulation with TrustZone services
2019-02-17 22:12 ` Thomas Petazzoni
2019-02-18 18:14 ` Yann E. MORIN
@ 2019-02-19 8:31 ` Arnout Vandecappelle
2019-03-05 9:14 ` Etienne Carriere
1 sibling, 1 reply; 25+ messages in thread
From: Arnout Vandecappelle @ 2019-02-19 8:31 UTC (permalink / raw)
To: buildroot
On 17/02/2019 23:12, Thomas Petazzoni wrote:
> Hello,
>
> On Wed, 30 Jan 2019 11:47:28 +0100
> Etienne Carriere <etienne.carriere@linaro.org> wrote:
>
>> This change introduces a Qemu board for an Armv7-A target executing
>> with OP-TEE secure world services.
>>
>> The target Linux based normal world embeds the standard minimal
>> filesystem with OP-TEE non-secure components embedded files from
>> OP-TEE test, examples and benchmark packages.
>>
>> The Linux custom configuration is dumped from the vexpress_defconfig
>> with few added fragments: OP-TEE driver and 9p for virtual filesystem to
>> ease file manipulation and exchanges through Qemu virtfs support.
>>
>> The standard way for booting OP-TEE with a non-secure world companion
>> use the Arm Trusted Firmware-A as bootloader. OP-TEE OS provides the
>> BL32 image and U-boot the BL33 image. The proposed board enables OP-TEE
>> and U-boot build for this. However package boot/arm-trusted-firmware
>> needs few change support building Armv7-A targets.
>>
>> Therefore the proposed board allows one to build the images but not
>> yet to run the target with the built Qemu host tool.
>>
>> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
>
> I don't know what is the opinion of Peter, Arnout and Yann, but I think
> this PATCH 6/7 and PATCH 7/7, instead of adding more defconfigs should
> instead add test cases to our runtime test infrastructure in
> support/testing/. Indeed:
>
> - We probably don't want to have Qemu defconfigs for every possible
> feature in Buildroot
I don't quite agree. I think we *do* want to have defconfigs that demonstrate
major features. For example, I like that we have qt5 defconfigs for several
platforms.
And for those defconfigs, obviously it is great if it can be qemu-based, as
Etienne pointed out. (For the Qt5 ones obviously they can't be qemu-based, and
indeed currently we don't have any qemu-based feature defconfigs.)
So IMO this TrustZone defconfig is a good thing.
>
> - A runtime test case, even if it's indeed a bit less visible than a
> defconfig, still documents a configuration that "works" for a given
> feature.
So I would propose a runtime test that uses that defconfig.
Regards,
Arnout
>
> - A runtime test case allows to really runtime test the feature by
> booting Qemu.
>
> Etienne, would you be willing to convert those two configurations to
> the runtime test infrastructure ?
>
> Thanks!
>
> Thomas
>
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] [PATCH v4 6/7] configs/qemu_armv7a_tz_virt: Armv7-A emulation with TrustZone services
2019-02-19 8:31 ` Arnout Vandecappelle
@ 2019-03-05 9:14 ` Etienne Carriere
2019-03-05 9:55 ` Thomas Petazzoni
0 siblings, 1 reply; 25+ messages in thread
From: Etienne Carriere @ 2019-03-05 9:14 UTC (permalink / raw)
To: buildroot
On Tue, 19 Feb 2019 at 09:31, Arnout Vandecappelle <arnout@mind.be> wrote:
>
>
>
> On 17/02/2019 23:12, Thomas Petazzoni wrote:
> > Hello,
> >
> > On Wed, 30 Jan 2019 11:47:28 +0100
> > Etienne Carriere <etienne.carriere@linaro.org> wrote:
> >
> >> This change introduces a Qemu board for an Armv7-A target executing
> >> with OP-TEE secure world services.
> >>
> >> The target Linux based normal world embeds the standard minimal
> >> filesystem with OP-TEE non-secure components embedded files from
> >> OP-TEE test, examples and benchmark packages.
> >>
> >> The Linux custom configuration is dumped from the vexpress_defconfig
> >> with few added fragments: OP-TEE driver and 9p for virtual filesystem to
> >> ease file manipulation and exchanges through Qemu virtfs support.
> >>
> >> The standard way for booting OP-TEE with a non-secure world companion
> >> use the Arm Trusted Firmware-A as bootloader. OP-TEE OS provides the
> >> BL32 image and U-boot the BL33 image. The proposed board enables OP-TEE
> >> and U-boot build for this. However package boot/arm-trusted-firmware
> >> needs few change support building Armv7-A targets.
> >>
> >> Therefore the proposed board allows one to build the images but not
> >> yet to run the target with the built Qemu host tool.
> >>
> >> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
> >
> > I don't know what is the opinion of Peter, Arnout and Yann, but I think
> > this PATCH 6/7 and PATCH 7/7, instead of adding more defconfigs should
> > instead add test cases to our runtime test infrastructure in
> > support/testing/. Indeed:
> >
> > - We probably don't want to have Qemu defconfigs for every possible
> > feature in Buildroot
>
> I don't quite agree. I think we *do* want to have defconfigs that demonstrate
> major features. For example, I like that we have qt5 defconfigs for several
> platforms.
>
> And for those defconfigs, obviously it is great if it can be qemu-based, as
> Etienne pointed out. (For the Qt5 ones obviously they can't be qemu-based, and
> indeed currently we don't have any qemu-based feature defconfigs.)
>
> So IMO this TrustZone defconfig is a good thing.
>
> >
> > - A runtime test case, even if it's indeed a bit less visible than a
> > defconfig, still documents a configuration that "works" for a given
> > feature.
>
> So I would propose a runtime test that uses that defconfig.
>
Dear all,
I've prepared something to test the optee on qemu/arm through the
runtime tests but few questions puzzle me.
1/ To use the board defconfig for the test, I created the file
support/test/conf/qemu_xxx_defconfig as a symlink to
configs/qemu_xxx_defconfig.
I'm not sure it is that nice. But it allowed to set the test config in
the test_opee.py using:
class TestOpteeXtest(infra.basetest.BRTest):
with open(infra.filepath('conf/qemu_armv7a_tz_virt_defconfig'),
'r') as config_file:
config = "".join(line for line in config_file if line[:1]!='#')
If you think there is another more convenient way, feel free to suggest.
2/ To share this test I need few preliminary changes in arm-trusted-firmware.
This will brings a series of dependent patches: tf-a updates + qemu
board defconfig + optee runtime test script.
The series depends on branch next, as dependent on OP-TEE packages.
That will make several versatile changes in a single patches series
over the next branch.
I plan to submit the series to the ML, for the next.
Tell me if you rather have this work be reviewed in 2 steps: first
tf-a changes, then once merged, qemu board and the optee runtime test.
Best regards,
etienne
>
> Regards,
> Arnout
>
>
> >
> > - A runtime test case allows to really runtime test the feature by
> > booting Qemu.
> >
> > Etienne, would you be willing to convert those two configurations to
> > the runtime test infrastructure ?
> >
> > Thanks!
> >
> > Thomas
> >
^ permalink raw reply [flat|nested] 25+ messages in thread* [Buildroot] [PATCH v4 6/7] configs/qemu_armv7a_tz_virt: Armv7-A emulation with TrustZone services
2019-03-05 9:14 ` Etienne Carriere
@ 2019-03-05 9:55 ` Thomas Petazzoni
2019-03-05 10:58 ` Etienne Carriere
0 siblings, 1 reply; 25+ messages in thread
From: Thomas Petazzoni @ 2019-03-05 9:55 UTC (permalink / raw)
To: buildroot
Hello ?tienne,
On Tue, 5 Mar 2019 10:14:07 +0100
Etienne Carriere <etienne.carriere@linaro.org> wrote:
> I've prepared something to test the optee on qemu/arm through the
> runtime tests but few questions puzzle me.
>
> 1/ To use the board defconfig for the test, I created the file
> support/test/conf/qemu_xxx_defconfig as a symlink to
> configs/qemu_xxx_defconfig.
> I'm not sure it is that nice. But it allowed to set the test config in
> the test_opee.py using:
>
> class TestOpteeXtest(infra.basetest.BRTest):
> with open(infra.filepath('conf/qemu_armv7a_tz_virt_defconfig'),
> 'r') as config_file:
> config = "".join(line for line in config_file if line[:1]!='#')
infra.filepath() is as simple as:
def filepath(relpath):
return os.path.join(os.getcwd(), "support/testing", relpath)
so you can just do:
with open(os.path.join(os.getcwd(), "configs/qemu_armv7a_tz_virt_defconfig"))
however, I see one down-side with this: defconfigs are usually using an
internal toolchain, so they take a long time to build. We typically try
to use external toolchains for most runtime tests, to make them faster
and therefore more usable. But perhaps you can take the defconfig +
inject a few lines of configuration to use an external toolchain.
> 2/ To share this test I need few preliminary changes in arm-trusted-firmware.
> This will brings a series of dependent patches: tf-a updates + qemu
> board defconfig + optee runtime test script.
> The series depends on branch next, as dependent on OP-TEE packages.
> That will make several versatile changes in a single patches series
> over the next branch.
>
> I plan to submit the series to the ML, for the next.
> Tell me if you rather have this work be reviewed in 2 steps: first
> tf-a changes, then once merged, qemu board and the optee runtime test.
Note: next is going to be merged back in master very soon now, since
2019.02 has been released.
If you already have all the changes, then please send them in one
single series, it makes it clearer why the preparation patches are
needed.
Also, I have seen your series improving various things in optee related
packages, I intend to have a look very soon.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 25+ messages in thread* [Buildroot] [PATCH v4 6/7] configs/qemu_armv7a_tz_virt: Armv7-A emulation with TrustZone services
2019-03-05 9:55 ` Thomas Petazzoni
@ 2019-03-05 10:58 ` Etienne Carriere
0 siblings, 0 replies; 25+ messages in thread
From: Etienne Carriere @ 2019-03-05 10:58 UTC (permalink / raw)
To: buildroot
On Tue, 5 Mar 2019 at 10:55, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello ?tienne,
>
> On Tue, 5 Mar 2019 10:14:07 +0100
> Etienne Carriere <etienne.carriere@linaro.org> wrote:
>
> > I've prepared something to test the optee on qemu/arm through the
> > runtime tests but few questions puzzle me.
> >
> > 1/ To use the board defconfig for the test, I created the file
> > support/test/conf/qemu_xxx_defconfig as a symlink to
> > configs/qemu_xxx_defconfig.
> > I'm not sure it is that nice. But it allowed to set the test config in
> > the test_opee.py using:
> >
> > class TestOpteeXtest(infra.basetest.BRTest):
> > with open(infra.filepath('conf/qemu_armv7a_tz_virt_defconfig'),
> > 'r') as config_file:
> > config = "".join(line for line in config_file if line[:1]!='#')
>
> infra.filepath() is as simple as:
>
> def filepath(relpath):
> return os.path.join(os.getcwd(), "support/testing", relpath)
>
> so you can just do:
>
> with open(os.path.join(os.getcwd(), "configs/qemu_armv7a_tz_virt_defconfig"))
>
Ok, i should have looked into :)
Thanks. I prefer to get rid of such symlink.
> however, I see one down-side with this: defconfigs are usually using an
> internal toolchain, so they take a long time to build. We typically try
> to use external toolchains for most runtime tests, to make them faster
> and therefore more usable. But perhaps you can take the defconfig +
> inject a few lines of configuration to use an external toolchain.
>
Great, I'll go this way: defconfig + extra toolchain directives.
> > 2/ To share this test I need few preliminary changes in arm-trusted-firmware.
> > This will brings a series of dependent patches: tf-a updates + qemu
> > board defconfig + optee runtime test script.
> > The series depends on branch next, as dependent on OP-TEE packages.
> > That will make several versatile changes in a single patches series
> > over the next branch.
> >
> > I plan to submit the series to the ML, for the next.
> > Tell me if you rather have this work be reviewed in 2 steps: first
> > tf-a changes, then once merged, qemu board and the optee runtime test.
>
> Note: next is going to be merged back in master very soon now, since
> 2019.02 has been released.
>
> If you already have all the changes, then please send them in one
> single series, it makes it clearer why the preparation patches are
> needed.
>
Fine, thank.
I'll send soon.
Regards,
etienne
>
> Also, I have seen your series improving various things in optee related
> packages, I intend to have a look very soon.
>
> Thanks!
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Buildroot] [PATCH v4 7/7] configs/qemu_aarch64_tz_virt: AArch64 emulation with TrustZone services
2019-01-30 10:47 [Buildroot] [PATCH v4 1/7] boot/optee-os: new package Etienne Carriere
` (4 preceding siblings ...)
2019-01-30 10:47 ` [Buildroot] [PATCH v4 6/7] configs/qemu_armv7a_tz_virt: Armv7-A emulation with TrustZone services Etienne Carriere
@ 2019-01-30 10:47 ` Etienne Carriere
2019-02-10 16:14 ` [Buildroot] [PATCH v4 1/7] boot/optee-os: new package Thomas Petazzoni
6 siblings, 0 replies; 25+ messages in thread
From: Etienne Carriere @ 2019-01-30 10:47 UTC (permalink / raw)
To: buildroot
This change introduces a Qemu board for an AArch64 target executing
with OP-TEE secure world services.
The target Linux based normal world embeds the standard minimal
filesystem with OP-TEE non-secure components embedded files from
OP-TEE client, test, examples and benchmark packages.
The Linux custom configuration is dumped from the qemu/aarch64-virt board
with few added fragments: OP-TEE driver and 9p for virtual filesystem to
ease file manipulation and exchanges through Qemu virtfs support.
The standard way for booting OP-TEE with a non-secure world companion
use the Arm Trusted Firmware-A as bootloader. OP-TEE OS provides the
BL32 image and U-boot the BL33 image. The proposed board enables OP-TEE
and U-boot build for this. However package boot/arm-trusted-firmware
needs few changes to build OP-TEE compliant TF-A images.
Therefore the proposed board allows one to build the images but not
yet to run the target with the built Qemu host tool.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
---
Changes v3 -> v4
- No change.
Changes v2 -> v3
- New change to introduce a board that at least builds Aarch64 OP-TEE.
---
board/qemu/aarch64-tz-virt/linux.config | 63 ++++++++++++++++++++++++++++++++
board/qemu/aarch64-tz-virt/readme.txt | 11 ++++++
board/qemu/aarch64-tz-virt/u-boot.config | 3 ++
configs/qemu_aarch64_tz_virt_defconfig | 47 ++++++++++++++++++++++++
4 files changed, 124 insertions(+)
create mode 100644 board/qemu/aarch64-tz-virt/linux.config
create mode 100644 board/qemu/aarch64-tz-virt/readme.txt
create mode 100644 board/qemu/aarch64-tz-virt/u-boot.config
create mode 100644 configs/qemu_aarch64_tz_virt_defconfig
diff --git a/board/qemu/aarch64-tz-virt/linux.config b/board/qemu/aarch64-tz-virt/linux.config
new file mode 100644
index 0000000..49b7ac6
--- /dev/null
+++ b/board/qemu/aarch64-tz-virt/linux.config
@@ -0,0 +1,63 @@
+CONFIG_SYSVIPC=y
+CONFIG_POSIX_MQUEUE=y
+CONFIG_NO_HZ_IDLE=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_TASKSTATS=y
+CONFIG_SCHED_AUTOGROUP=y
+CONFIG_PROFILING=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_BLK_DEV_BSGLIB=y
+CONFIG_ARCH_VEXPRESS=y
+CONFIG_TRANSPARENT_HUGEPAGE=y
+CONFIG_BINFMT_MISC=y
+CONFIG_COMPAT=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_PACKET_DIAG=y
+CONFIG_UNIX=y
+CONFIG_NET_KEY=y
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+CONFIG_IP_ADVANCED_ROUTER=y
+CONFIG_BRIDGE=m
+CONFIG_NET_SCHED=y
+CONFIG_VSOCKETS=y
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+CONFIG_VIRTIO_BLK=y
+CONFIG_BLK_DEV_SD=y
+CONFIG_CHR_DEV_SG=y
+CONFIG_SCSI_CONSTANTS=y
+CONFIG_SCSI_LOGGING=y
+CONFIG_SCSI_SCAN_ASYNC=y
+CONFIG_SCSI_VIRTIO=y
+CONFIG_ATA=y
+CONFIG_NETDEVICES=y
+CONFIG_DUMMY=y
+CONFIG_MACVLAN=y
+CONFIG_VIRTIO_NET=y
+CONFIG_NLMON=y
+CONFIG_VT_HW_CONSOLE_BINDING=y
+CONFIG_SERIAL_AMBA_PL011=y
+CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
+CONFIG_VIRTIO_CONSOLE=y
+CONFIG_HW_RANDOM=y
+CONFIG_HW_RANDOM_VIRTIO=y
+CONFIG_RTC_CLASS=y
+CONFIG_VIRTIO_MMIO=y
+CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES=y
+CONFIG_MAILBOX=y
+CONFIG_PL320_MBOX=y
+CONFIG_EXT4_FS=y
+CONFIG_TMPFS=y
+CONFIG_TMPFS_POSIX_ACL=y
+### Enable OP-TEE
+CONFIG_TEE=y
+CONFIG_OPTEE=y
+### Enable 9P VFS
+CONFIG_NET_9P=y
+CONFIG_NET_9P_VIRTIO=y
+CONFIG_9P_FS=y
+CONFIG_9P_FS_POSIX_ACL=y
+
diff --git a/board/qemu/aarch64-tz-virt/readme.txt b/board/qemu/aarch64-tz-virt/readme.txt
new file mode 100644
index 0000000..ec91d2e
--- /dev/null
+++ b/board/qemu/aarch64-tz-virt/readme.txt
@@ -0,0 +1,11 @@
+Board qemu_aarch64_tz_virt builds a Qemu Armv8-A target with
+OP-TEE running in the TrustZone secure wolrd setup and a Linux based
+OS running in the non-secure wolrd.
+
+This setup is usually booted with the Arm Trsuted Firmware-A (TF-A from
+package boot/arm-trusted-firmware). However the current Buildroot package
+needs few changes to build TF-A for OP-TEE support.
+
+Until BR arm-trusted-firmware is updated this board allows one to only
+build the secure and non-secure boot images if not the BIOS for the Qemu
+host.
diff --git a/board/qemu/aarch64-tz-virt/u-boot.config b/board/qemu/aarch64-tz-virt/u-boot.config
new file mode 100644
index 0000000..5588008
--- /dev/null
+++ b/board/qemu/aarch64-tz-virt/u-boot.config
@@ -0,0 +1,3 @@
+CONFIG_SYS_TEXT_BASE=0x60000000
+CONFIG_BOOTCOMMAND="fdt addr ${fdt_addr} && fdt resize 1000 && smhload zImage ${kernel_addr_r} && smhload rootfs.cpio.gz ${ramdisk_addr_r} ramdisk_addr_end && setenv bootargs console=ttyAMA0,115200 earlyprintk=serial,ttyAMA0,115200 && fdt chosen ${ramdisk_addr_r} ${ramdisk_addr_end} && bootz ${kernel_addr_r} - ${fdt_addr}"
+CONFIG_SEMIHOSTING=y
diff --git a/configs/qemu_aarch64_tz_virt_defconfig b/configs/qemu_aarch64_tz_virt_defconfig
new file mode 100644
index 0000000..9286d15
--- /dev/null
+++ b/configs/qemu_aarch64_tz_virt_defconfig
@@ -0,0 +1,47 @@
+# Architecture
+BR2_aarch64=y
+
+# System
+BR2_SYSTEM_DHCP="eth0"
+BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
+
+# Filesystem
+BR2_TARGET_ROOTFS_CPIO=y
+BR2_TARGET_ROOTFS_CPIO_GZIP=y
+BR2_TARGET_ROOTFS_EXT2=y
+BR2_TARGET_ROOTFS_EXT2_4=y
+# BR2_TARGET_ROOTFS_TAR is not set
+
+# Linux headers same as kernel, a 4.16 series
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_16=y
+
+# Kernel
+BR2_LINUX_KERNEL=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.16.7"
+BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
+BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/aarch64-tz-virt/linux.config"
+BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=y
+
+# TF-A for booting OP-TEE secure and uboot/linux non secure
+# POSTPONED: depends on boot/arm-trusted-firmware support for Armv7-A
+
+# OP-TEE components
+BR2_TARGET_OPTEE_OS=y
+BR2_TARGET_OPTEE_OS_PLATFORM="vexpress-qemu_armv8a"
+BR2_TARGET_OPTEE_OS_ADDITIONAL_VARIABLES="CFG_TEE_CORE_DEBUG=n CFG_UNWIND=n CFG_TEE_CORE_LOG_LEVEL=2"
+BR2_PACKAGE_OPTEE_CLIENT=y
+BR2_PACKAGE_OPTEE_TEST=y
+BR2_PACKAGE_OPTEE_EXAMPLES=y
+BR2_PACKAGE_OPTEE_BENCHMARK=y
+
+# Need a non-secure bootloader for the dear Linux kernel: U-boot? UEFI?
+BR2_TARGET_UBOOT=y
+BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y
+BR2_TARGET_UBOOT_BOARD_DEFCONFIG="qemu_arm64"
+BR2_TARGET_UBOOT_CONFIG_FRAGMENT_FILES="board/qemu/aarch64-tz-virt/u-boot.config"
+
+# Qemu emulator for the Arm target
+BR2_PACKAGE_HOST_QEMU=y
+BR2_PACKAGE_HOST_QEMU_SYSTEM_MODE=y
+BR2_PACKAGE_HOST_QEMU_VIRTFS=y
^ permalink raw reply related [flat|nested] 25+ messages in thread* [Buildroot] [PATCH v4 1/7] boot/optee-os: new package
2019-01-30 10:47 [Buildroot] [PATCH v4 1/7] boot/optee-os: new package Etienne Carriere
` (5 preceding siblings ...)
2019-01-30 10:47 ` [Buildroot] [PATCH v4 7/7] configs/qemu_aarch64_tz_virt: AArch64 " Etienne Carriere
@ 2019-02-10 16:14 ` Thomas Petazzoni
6 siblings, 0 replies; 25+ messages in thread
From: Thomas Petazzoni @ 2019-02-10 16:14 UTC (permalink / raw)
To: buildroot
On Wed, 30 Jan 2019 11:47:23 +0100
Etienne Carriere <etienne.carriere@linaro.org> wrote:
> OP-TEE OS is maintained by the OP-TEE project. It provides an
> open source solution for development and integration of secure
> services for Armv7-A and Armv8-A CPU based platforms supporting
> the TrustZone technology. This technology enables CPUs to
> concurrently host a secure world as the OP-TEE OS and a non-secure
> world as a Linux based OS.
>
> The OP-TEE project maintains other packages to leverage OP-TEE on
> Linux kernel based OSes. An OP-TEE interface driver is available
> in the Linux kernel since 4.12 upon CONFIG_OPTEE.
>
> This change references in Buildroot the today's latest OP-TEE
> revision release tagged 3.4.0.
>
> https://www.op-tee.org/
> https://github.com/OP-TEE/optee_os
>
> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
>
> ---
> Changes v3 -> v4
> - Upgrade from OP-TEE 3.3.0 to 3.4.0. No local patch required.
Applied to next with the following fixes:
[Thomas:
- pass CFG_ARM32_core=y when building for ARMv7, otherwise the build
fails
- add a check that verifies that BR2_TARGET_OPTEE_OS_PLATFORM is not
empty
- minor formatting fixes/adjustements.]
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 25+ messages in thread