[Buildroot] [PATCH v3 1/4] boot/arm-trusted-firmware: support alternate image files

[Buildroot] [PATCH v3 1/4] boot/arm-trusted-firmware: support alternate image files

[Etienne Carriere]

Some platform may generate specific boot image files instead of
the generic files *.bin  when building TF-A package. This change
introduces new configuration directive for the arm-trusted-firmware
boot package.

BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_IMAGE_NAMES is boolean.
When disabled, install boot image files are .../*.bin.
When enabled, BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL_IMAGE_NAMES shall
lists the names of the generated boot image files.

Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
---
Changes v2 -> v3:
 - Replace BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_IMAGE_NAMES and
   BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL_IMAGE_NAMES with unique config
   BR2_TARGET_ARM_TRUSTED_FIRMWARE_IMAGE_NAMES.

Changes v1 -> v2:
 - No change
---
 boot/arm-trusted-firmware/Config.in               | 7 +++++++
 boot/arm-trusted-firmware/arm-trusted-firmware.mk | 8 +++++++-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/boot/arm-trusted-firmware/Config.in b/boot/arm-trusted-firmware/Config.in
index beb95fbf06..f4ed430aec 100644
--- a/boot/arm-trusted-firmware/Config.in
+++ b/boot/arm-trusted-firmware/Config.in
@@ -124,6 +124,13 @@ config BR2_TARGET_ARM_TRUSTED_FIRMWARE_UBOOT_AS_BL33
 	  gets built before ATF, and that the appropriate BL33
 	  variable pointing to u-boot.bin is passed when building ATF.
 
+config BR2_TARGET_ARM_TRUSTED_FIRMWARE_IMAGE_NAMES
+        string "Image names"
+        default "*.bin"
+        help
+	  File names of the generated boot images to be copied to
+	  output directory images/.
+
 config BR2_TARGET_ARM_TRUSTED_FIRMWARE_ADDITIONAL_VARIABLES
 	string "Additional ATF build variables"
 	help
diff --git a/boot/arm-trusted-firmware/arm-trusted-firmware.mk b/boot/arm-trusted-firmware/arm-trusted-firmware.mk
index 9a23e3d336..c3625cd986 100644
--- a/boot/arm-trusted-firmware/arm-trusted-firmware.mk
+++ b/boot/arm-trusted-firmware/arm-trusted-firmware.mk
@@ -136,6 +136,12 @@ define ARM_TRUSTED_FIRMWARE_BL31_UBOOT_INSTALL_ELF
 endef
 endif
 
+define ARM_TRUSTED_FIRMWARE_BL_IMAGES_INSTALL
+        $(foreach f, $(call qstrip,$(BR2_TARGET_ARM_TRUSTED_FIRMWARE_IMAGE_NAMES)),
+		echo $(f) && $(INSTALL) -D -m 0644 -t $(BINARIES_DIR) $(ARM_TRUSTED_FIRMWARE_IMG_DIR)/$(f)
+        )
+endef
+
 define ARM_TRUSTED_FIRMWARE_BUILD_CMDS
 	$(ARM_TRUSTED_FIRMWARE_BUILD_FIPTOOL)
 	$(TARGET_MAKE_ENV) $(MAKE) -C $(@D) $(ARM_TRUSTED_FIRMWARE_MAKE_OPTS) \
@@ -144,7 +150,7 @@ define ARM_TRUSTED_FIRMWARE_BUILD_CMDS
 endef
 
 define ARM_TRUSTED_FIRMWARE_INSTALL_IMAGES_CMDS
-	cp -dpf $(ARM_TRUSTED_FIRMWARE_IMG_DIR)/*.bin $(BINARIES_DIR)/
+	$(ARM_TRUSTED_FIRMWARE_BL_IMAGES_INSTALL)
 	$(ARM_TRUSTED_FIRMWARE_BL31_UBOOT_INSTALL)
 	$(ARM_TRUSTED_FIRMWARE_BL31_UBOOT_INSTALL_ELF)
 endef
-- 
2.17.1

[Buildroot] [PATCH v3 2/4] configs/qemu_arm_vexpress_tz: Armv7-A emulation with TrustZone services

[Etienne Carriere]

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.

qemu_arm_vexpress_tz_defconfig differs from qemu_arm_vexpress_defconfig.
Supporting both secure and non-secure worlds on the Arm target mandates
a secure world, here OP-TEE OS, and a bootloader to boot both worlds,
here TF-A (boot/arm-trusted-firmware). Here non-secure Linux kernel is
booted through U-boot

  TF-A bootloader (BL1/BL2) => OP-TEE (BL32) => U-boot (BL33).
  | Executes as secure         | Secure         | Execs as Non-secure
  | Loads BL32/BL33 in RAM     | Jumps to BL33  | Always booted after
  | Jumps to BL32 once done    | as Non-secure  | secure world inits

Vexpress and vexpress-tz defconfigs also differs in that Qemu emulates
a Cortex-A9 in the former and a Cortex-A15 in the later. Cortex-A15
is the Armv7-A CPU used in upstream TF-A and OP-TEE OS packages hence
selected here.

Defconfig adds a fragment to the Linux kernel native configuration to
enable OP-TEE driver support.

Defconfig adds a fragment to the U-Boot native configuration set boot
command, enable semihosting and remove U-Boot persistent environment
storage support.

The defconfig also enables build of the Qemu emulator in case the
system installed Qemu does not yet support CPU TrustZone secure state.

Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
---
Changes v2 -> v3:
  - Rename board/config: qemu_armv7a_tz_virt => qemu_arm_vexpress_tz
  - Remove some useless configuration from the defconfig: Linux 9P;
    Qemu virtfs; TF-A log level; OP-TEE log level.
  - Add post_build.sh script to rename files in output/images/.
  - Detail diffs between vexpress and vexpress-tz defconfigs in commit.
  - Fix typo in defconfig about Linux version number.
  - Remove info about virtfs from board readme.txt file.
  - Update TF-A config from recent changes: image filenames; OP-TEE.

Changes v1 -> v2:
  - Bump kernel to 4.19.
  - Use kernel defconfig and add optee and 9p as config fragments.
  - Remove ARM_ARCH_MAJOR from platform configuration directive
    BR2_TARGET_ARM_TRUSTED_FIRMWARE_ADDITIONAL_VARIABLES.
---
 board/qemu/arm-vexpress-tz/linux.fragment |   3 +
 board/qemu/arm-vexpress-tz/post-build.sh  |  10 ++
 board/qemu/arm-vexpress-tz/readme.txt     | 135 ++++++++++++++++++++++
 board/qemu/arm-vexpress-tz/u-boot.config  |   7 ++
 configs/qemu_arm_vexpress_tz_defconfig    |  47 ++++++++
 5 files changed, 202 insertions(+)
 create mode 100644 board/qemu/arm-vexpress-tz/linux.fragment
 create mode 100755 board/qemu/arm-vexpress-tz/post-build.sh
 create mode 100644 board/qemu/arm-vexpress-tz/readme.txt
 create mode 100644 board/qemu/arm-vexpress-tz/u-boot.config
 create mode 100644 configs/qemu_arm_vexpress_tz_defconfig

diff --git a/board/qemu/arm-vexpress-tz/linux.fragment b/board/qemu/arm-vexpress-tz/linux.fragment
new file mode 100644
index 0000000000..1537d938f1
--- /dev/null
+++ b/board/qemu/arm-vexpress-tz/linux.fragment
@@ -0,0 +1,3 @@
+### Enable OP-TEE
+CONFIG_TEE=y
+CONFIG_OPTEE=y
diff --git a/board/qemu/arm-vexpress-tz/post-build.sh b/board/qemu/arm-vexpress-tz/post-build.sh
new file mode 100755
index 0000000000..7ead69a99a
--- /dev/null
+++ b/board/qemu/arm-vexpress-tz/post-build.sh
@@ -0,0 +1,10 @@
+#!/bin/sh
+
+set -u
+set -e
+
+# Rename boot images for the dear TF-A
+ln -sf u-boot.bin ${BINARIES_DIR}/bl33.bin
+ln -sf tee-header_v2.bin ${BINARIES_DIR}/bl32.bin
+ln -sf tee-pager_v2.bin ${BINARIES_DIR}/bl32_extra1.bin
+ln -sf tee-pageable_v2.bin ${BINARIES_DIR}/bl32_extra2.bin
diff --git a/board/qemu/arm-vexpress-tz/readme.txt b/board/qemu/arm-vexpress-tz/readme.txt
new file mode 100644
index 0000000000..95cd6da8c3
--- /dev/null
+++ b/board/qemu/arm-vexpress-tz/readme.txt
@@ -0,0 +1,135 @@
+Board qemu_arm_vexpress_tz builds a Qemu Armv7-A target system with
+OP-TEE running in the TrustZone secure world and a Linux based
+OS running in the non-secure world. The board configuration enable
+builds of the Qemu host Arm target emulator.
+
+  make qemu_arm_vexpress_tz_defconfig
+  make
+
+BIOS used in the Qemu host is the Arm Trusted Firmware-A (TF-A). TF-A
+uses Qemu semihosting file access to access boot image files. The
+Qemu platform is quite specific for that in TF-A and one needs to
+run the emulation from the image directory for TF-A to boot the
+secure and non-secure worlds.
+
+  cd output/images && ../host/bin/qemu-system-arm \
+	-machine virt -machine secure=on -cpu cortex-a15 \
+	-smp 1 -s -m 1024 -d unimp \
+	-serial stdio \
+	-netdev user,id=vmnic -device virtio-net-device,netdev=vmnic \
+	-semihosting-config enable,target=native \
+	-bios bl1.bin
+
+The boot stage traces (if any) followed by the login prompt will appear
+in the terminal that started Qemu.
+
+If you want to emulate more cores use "-smp {1|2|3|4}" to select the
+number of cores.
+
+Note "-netdev user,id=vmnic -device virtio-net-device,netdev=vmnic"
+brings network support that is used i.e. in OP-TEE regression tests.
+
+Tested with QEMU 2.12.0, and 3.1.0.
+
+-- Boot Details --
+
+TF-A is used as Qemu BIOS. Its BL1 image boots and load its BL2 image. In turn, this
+image loads the OP-TEE secure world (Armv7-A BL32 stage) and the U-boot as non-secure
+bootloader (BL33 stage).
+
+The Qemu natively host and loads in RAM the Qemu Arm target device tree. OP-TEE reads
+and modifes its content according to OP-TEE configuration.
+
+Enable TF-A traces from LOG_LEVEL (I.e LOG_LEVEL=40) from
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_ADDITIONAL_VARIABLES.
+
+-- OP-TEE Traces --
+
+Secure boot stages and/or secure runtime services may use a serial link for
+their traces.
+
+The Arm Trusted Firmware outputs its traces on the Qemu standard (first)
+serial  interface.
+
+The OP-TEE OS uses the Qemu second serial interface.
+
+To get the OP-TEE OS traces one shall append a second -serial argument after
+-serial stdio in the Qemu command line. I.e the following enables 2 serial
+consoles over telnet connections:
+
+  cd output/images && ../host/bin/qemu-system-arm \
+	-machine virt -machine secure=on -cpu cortex-a15 \
+	-smp 1 -s -m 1024 -d unimp \
+	-serial telnet:127.0.0.1:1235,server \
+	-serial telnet:127.0.0.1:1236,server \
+	-netdev user,id=vmnic -device virtio-net-device,netdev=vmnic \
+	-semihosting-config enable,target=native \
+	-bios bl1.bin
+
+Qemu is now waiting for the telnet connection. From another shell, open a
+telnet connection on the port for the U-boot and Linux consoles:
+  telnet 127.0.0.1 1235
+
+and again for the secure console
+  telnet 127.0.0.1 1236
+
+-- Using gdb --
+
+One can debug the OP-TEE secure world using GDB through the Qemu host.
+To do so, one can simply run the qemu-system-arm emulation then
+run a GDB client and connect the Qemu internal GDB server.
+
+The example below assumes we run Qemu and the GDB client from the same
+host computer. We use option -S of qemu-system-arm to make Qemu
+waiting for the GDB continue instruction before booting the images.
+
+From a first shell:
+  cd output/images && ../host/bin/qemu-system-arm \
+	-machine virt -machine secure=on -cpu cortex-a15 \
+	-smp 1 -s -m 1024 -d unimp \
+	-serial stdio \
+	-netdev user,id=vmnic -device virtio-net-device,netdev=vmnic \
+	-semihosting-config enable,target=native \
+	-bios bl1.bin \
+	-S
+
+From a second shell:
+  ./output/host/bin/arm-linux-gnueabihf-gd
+  GNU gdb (GNU Toolchain for the A-profile Architecture 8.2-2018-08 (arm-rel-8.23)) 8.1.1.20180704-git
+  Copyright (C) 2018 Free Software Foundation, Inc.
+  ...
+  For help, type "help".
+  Type "apropos word" to search for commands related to "word".
+  (gdb) 
+
+From this GDB console, connect target, load OP-TEE core symbols, set a
+breakpoint to its entry (__text_start) and start emulation:
+
+  (gdb) target remote 127.0.0.1:1234
+  (gdb) symbol-file ../build/optee_os-<reference>/out/arm/core/tee.elf
+  (gdb) hbreak __text_start
+  Hardware assisted breakpoint 1 at 0xe100000: file core/arch/arm/kernel/generic_entry_a32.S, line 246.
+  (gdb) cont
+  Continuing.
+  
+  Thread 1 hit Breakpoint 1, _start () at core/arch/arm/kernel/generic_entry_a32.S:246
+  246		bootargs_entry
+  (gdb) 
+
+
+Emulation has started, TF-A has loaded OP-TEE and U-boot images in memory and
+has booted OP-TEE. Emulation stopped at OP-TEE core entry.
+
+
+Note: Qemu hosts a GDB service listening to TCP port 1234, as set through
+qemu-system-arm commandline option -s.
+
+
+Note: GDB server used above (from image/host/bin) was built from Buildroot
+using the following extra configuration directives:
+
+    BR2_ENABLE_DEBUG=y
+    BR2_PACKAGE_GDB=y
+    BR2_PACKAGE_HOST_GDB=y
+    BR2_TOOLCHAIN_BUILDROOT_CXX=y
+    BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
diff --git a/board/qemu/arm-vexpress-tz/u-boot.config b/board/qemu/arm-vexpress-tz/u-boot.config
new file mode 100644
index 0000000000..fd74bf1fe7
--- /dev/null
+++ b/board/qemu/arm-vexpress-tz/u-boot.config
@@ -0,0 +1,7 @@
+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
+# Drop flash accesses
+CONFIG_ENV_IS_IN_FLASH=n
+CONFIG_MTD=n
+CONFIG_MTD_NOR_FLASH=n
diff --git a/configs/qemu_arm_vexpress_tz_defconfig b/configs/qemu_arm_vexpress_tz_defconfig
new file mode 100644
index 0000000000..3ea48768b0
--- /dev/null
+++ b/configs/qemu_arm_vexpress_tz_defconfig
@@ -0,0 +1,47 @@
+# 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"
+# Filesystems (support several boot config)
+BR2_TARGET_ROOTFS_CPIO=y
+BR2_TARGET_ROOTFS_CPIO_GZIP=y
+BR2_TARGET_ROOTFS_EXT2=y
+# Generic
+BR2_ROOTFS_POST_BUILD_SCRIPT="board/qemu/arm-vexpress-tz/post-build.sh"
+# Linux 4.19 series
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_19=y
+BR2_LINUX_KERNEL=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.19.16"
+BR2_LINUX_KERNEL_DEFCONFIG="vexpress"
+BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES="board/qemu/arm-vexpress-tz/linux.fragment"
+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
+BR2_TARGET_ARM_TRUSTED_FIRMWARE=y
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_GIT=y
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_REPO_URL="https://github.com/ARM-software/arm-trusted-firmware.git"
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_REPO_VERSION="v2.0"
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_PLATFORM="qemu"
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL32_OPTEE=y
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_UBOOT_AS_BL33=y
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_ADDITIONAL_VARIABLES="BL32_RAM_LOCATION=tdram"
+# OP-TEE components
+BR2_TARGET_OPTEE_OS=y
+BR2_TARGET_OPTEE_OS_PLATFORM="vexpress-qemu_virt"
+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/arm-vexpress-tz/u-boot.config"
+# Build Qemu emulator for the Arm target
+BR2_PACKAGE_HOST_QEMU=y
+BR2_PACKAGE_HOST_QEMU_SYSTEM_MODE=y
-- 
2.17.1

[Buildroot] [PATCH v3 3/4] support/testing: test can use the locally generated qemu host tool

[Etienne Carriere]

This change adds argument --local-emulator to run-tests to use a
locally built emulator for the runtime test. Target test shall provide
a config_emulator attribute unless what test is inconsistent.

Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
---
Changes v2 -> v3:
  - Add an argument to run-tests to use locally built emulator.
    Test can still enforce use of locally built emulator from
    boot method argument local=True|False (still defaults to False).

Changes v1 -> v2:
  - No commit not in v1 series.
---
 support/testing/infra/basetest.py |  5 ++++-
 support/testing/infra/emulator.py | 19 ++++++++++++++++---
 support/testing/run-tests         |  4 ++++
 3 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/support/testing/infra/basetest.py b/support/testing/infra/basetest.py
index a176bc328a..c59e0a3443 100644
--- a/support/testing/infra/basetest.py
+++ b/support/testing/infra/basetest.py
@@ -51,6 +51,8 @@ class BRConfigTest(unittest.TestCase):
 
     def setUp(self):
         self.show_msg("Starting")
+        if self.local_emulator:
+            self.config = self.config + self.config_emulator
         self.b = Builder(self.config, self.builddir, self.logtofile)
 
         if not self.keepbuilds:
@@ -78,7 +80,8 @@ class BRTest(BRConfigTest):
             self.show_msg("Building done")
 
         self.emulator = Emulator(self.builddir, self.downloaddir,
-                                 self.logtofile, self.timeout_multiplier)
+                                 self.logtofile, self.timeout_multiplier,
+                                 self.local_emulator)
 
     def tearDown(self):
         if self.emulator:
diff --git a/support/testing/infra/emulator.py b/support/testing/infra/emulator.py
index 802e89d4b4..13e19df497 100644
--- a/support/testing/infra/emulator.py
+++ b/support/testing/infra/emulator.py
@@ -1,14 +1,19 @@
 import pexpect
 
+import os
+
 import infra
 
 
 class Emulator(object):
 
-    def __init__(self, builddir, downloaddir, logtofile, timeout_multiplier):
+    def __init__(self, builddir, downloaddir, logtofile, timeout_multiplier,
+                 local_emulator):
         self.qemu = None
         self.downloaddir = downloaddir
         self.logfile = infra.open_log_file(builddir, "run", logtofile)
+        self.builddir = builddir
+        self.local_emulator = local_emulator
         # We use elastic runners on the cloud to runs our tests. Those runners
         # can take a long time to run the emulator. Use a timeout multiplier
         # when running the tests to avoid sporadic failures.
@@ -30,13 +35,21 @@ class Emulator(object):
     #
     # options: array of command line options to pass to Qemu
     #
-    def boot(self, arch, kernel=None, kernel_cmdline=None, options=None):
+    # local: if True, the locally built qemu host tool is used instead of a
+    # qemu host tool found from the PATH.
+    #
+    def boot(self, arch, kernel=None, kernel_cmdline=None, options=None,
+             local=None):
         if arch in ["armv7", "armv5"]:
             qemu_arch = "arm"
         else:
             qemu_arch = arch
 
-        qemu_cmd = ["qemu-system-{}".format(qemu_arch),
+        qemu_bin = "qemu-system-{}".format(qemu_arch)
+        if self.local_emulator or local:
+            qemu_bin = os.path.join(self.builddir, 'host', 'bin', qemu_bin)
+
+        qemu_cmd = [qemu_bin,
                     "-serial", "stdio",
                     "-display", "none"]
 
diff --git a/support/testing/run-tests b/support/testing/run-tests
index 813b927045..c667fc2e4f 100755
--- a/support/testing/run-tests
+++ b/support/testing/run-tests
@@ -31,6 +31,8 @@ def main():
                         help='BR2_JLEVEL to use for each testcase')
     parser.add_argument('--timeout-multiplier', type=int, default=1,
                         help='increase timeouts (useful for slow machines)')
+    parser.add_argument('--local-emulator', action='store_true',
+                        help='use a locally built emulator')
 
     args = parser.parse_args()
 
@@ -107,6 +109,8 @@ def main():
         return 1
     BRConfigTest.timeout_multiplier = args.timeout_multiplier
 
+    BRConfigTest.local_emulator = args.local_emulator
+
     nose2_args = ["-v",
                   "-N", str(args.testcases),
                   "-s", test_dir,
-- 
2.17.1

[Buildroot] [PATCH v3 4/4] support/testing: test_optee.py: test optee boot and testsuite

[Etienne Carriere]

Run a Qemu emulation over qemu_armv7a_tz_virt_defconfig and
run the embedded OP-TEE regression test suite (xtest).

Tool xtest dumps traces that contain '# ' (hash + space) which
corrupts infra/emulator.py sequence which use such traces to
find shell prompt when command is completed. To overcome the issue
the xtest traces are shown only if the test failed.

One can run the test from something like:

  $> support/testing/run-tests \
         -o output/optee-runtest -d output/dwl \
         tests.package.test_optee

Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
---
Changes v2 -> v3:
  - Test provides a config_emulator attribute and mandates use of
    the locally built emulator.
  - Update qemu defconfig filename.
  - Remove postprocessing of test image file since driven from the
    selected defconfig

Changes v1 -> v2:
  - Add argument local=True to test emulator to use the qemu host
    built from test configuration.
  - Fix typo in trace "Silent test takes a while, be patient..."
---
 support/testing/tests/package/test_optee.py | 42 +++++++++++++++++++++
 1 file changed, 42 insertions(+)
 create mode 100644 support/testing/tests/package/test_optee.py

diff --git a/support/testing/tests/package/test_optee.py b/support/testing/tests/package/test_optee.py
new file mode 100644
index 0000000000..44cee74fd8
--- /dev/null
+++ b/support/testing/tests/package/test_optee.py
@@ -0,0 +1,42 @@
+import os
+
+import infra.basetest
+
+# This test enforces locally built emulator to prevent old Qemu to
+# dump secure trace to stdio and corrupting trace synchro expected
+# through pexpect.
+
+class TestOptee(infra.basetest.BRTest):
+
+    with open(os.path.join(os.getcwd(), 'configs',
+                           'qemu_arm_vexpress_tz_defconfig'),
+              'r') as config_file:
+        config = "".join(line for line in config_file if line[:1] != '#') + \
+                 """
+                 BR2_PACKAGE_HOST_QEMU=y
+                 BR2_PACKAGE_HOST_QEMU_SYSTEM_MODE=y
+                 BR2_TOOLCHAIN_EXTERNAL=y
+                 """
+    config_emulator = ''
+
+    def test_run(self):
+
+        qemu_options = ['-machine', 'virt,secure=on']
+        qemu_options.extend(['-cpu', 'cortex-a15'])
+        qemu_options.extend(['-m', '1024'])
+        qemu_options.extend(['-semihosting-config', 'enable,target=native'])
+        qemu_options.extend(['-bios', 'bl1.bin'])
+
+        # This test expects Qemu is run from the image direcotry
+        os.chdir(os.path.join(self.builddir, 'images'))
+
+        self.emulator.boot(arch='armv7', options=qemu_options, local=True)
+        self.emulator.login()
+
+        # Trick traces since xtest prints "# " which corrupts emulator run
+        # method. Tests are dumped only if test fails.
+        cmd = 'echo "Silent test takes a while, be patient..."; ' + \
+              'xtest -t regression > /tmp/xtest.log ||' + \
+              '(cat /tmp/xtest.log && false)'
+        output, exit_code = self.emulator.run(cmd, timeout=240)
+        self.assertEqual(exit_code, 0)
-- 
2.17.1

[Buildroot] [PATCH v3 3/4] support/testing: test can use the locally generated qemu host tool

[Ricardo Martincoski]

Hello,

+ Arnout

On Fri, Mar 22, 2019 at 06:58 AM, Etienne Carriere wrote:

> This change adds argument --local-emulator to run-tests to use a
> locally built emulator for the runtime test. Target test shall provide
> a config_emulator attribute unless what test is inconsistent.
> 
> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
> ---
> Changes v2 -> v3:
>   - Add an argument to run-tests to use locally built emulator.
>     Test can still enforce use of locally built emulator from
>     boot method argument local=True|False (still defaults to False).

I am not strongly against it.
But let me ask:
Are you or someone else having trouble with any other test case when using
"old" qemu versions from host?

If the answer is no, maybe we should keep things simple and use a patch very
similar to v2 of this one, just adding the host-qemu to the test case config
fragment and the 'local' argument to Emulator.run.
I say similar to v2 because I think your implementation in v3 with the
'qemu_bin' variable is better than v2.

If the answer is yes, be aware that one could download the docker image that we
use in GitLab CI and run the tests inside it. This image has qemu 2.8.1 that
currently run all tests we have without any problem AFAIK.

IMO, we remove --local-emulator and add local=True and host-qemu to the config
fragment of any tests (currently only the one in the next patch) that needs a
qemu newer than 2.8.1. 


Another approach "to have an generic option to script run-tests to build the
emulator within the test config" (quoting your reply to v2) would be:
Instead of adding a command line argument to run-tests, create a new flag in
the test case class, perhaps named "build_emulator". If that flag is True, the
host-qemu is automatically added to the config fragment by the test infra. The
same flag could be propagated to the Emulator.init so we don't need to pass
'local' to Emulator.run.
If for some reason a flag (boolean) is not enough, for example if the host-qemu
would not always be set with same options (I don't know if that is the case),
the test case that needs the local build of emulator could pass config_emulator
and that would make the test infra to know that it needs to build and use the
locally built emulator. Again, no need to pass 'local' to Emulator.run or the
user to pass a command line argument.
This way the test case tells the test infra that it needs an emulator built
locally instead of the user that starts the test.
Thoughts?

[snip]
> @@ -30,13 +35,21 @@ class Emulator(object):
>      #
>      # options: array of command line options to pass to Qemu
>      #
> -    def boot(self, arch, kernel=None, kernel_cmdline=None, options=None):
> +    # local: if True, the locally built qemu host tool is used instead of a
> +    # qemu host tool found from the PATH.
> +    #
> +    def boot(self, arch, kernel=None, kernel_cmdline=None, options=None,
> +             local=None):

A better default value is local=False

>          if arch in ["armv7", "armv5"]:
>              qemu_arch = "arm"
>          else:
>              qemu_arch = arch
>  
> -        qemu_cmd = ["qemu-system-{}".format(qemu_arch),
> +        qemu_bin = "qemu-system-{}".format(qemu_arch)
> +        if self.local_emulator or local:
> +            qemu_bin = os.path.join(self.builddir, 'host', 'bin', qemu_bin)
> +
> +        qemu_cmd = [qemu_bin,
>                      "-serial", "stdio",
>                      "-display", "none"]


Regards,
Ricardo

[Buildroot] [PATCH v3 4/4] support/testing: test_optee.py: test optee boot and testsuite

[Ricardo Martincoski]

Hello,

Looks good, except for the chdir stuff.
Also a lot of nits below.

On Fri, Mar 22, 2019 at 06:58 AM, Etienne Carriere wrote:

[snip]
> ---
>  support/testing/tests/package/test_optee.py | 42 +++++++++++++++++++++
>  1 file changed, 42 insertions(+)
>  create mode 100644 support/testing/tests/package/test_optee.py

Please run flake8 and fix the warning it generates.
test_optee.py:9:1: E302 expected 2 blank lines, found 1

Please run 'make .gitlab-ci.yml'. BTW the same is also missing in the defconfig
patch 2.

> 
> diff --git a/support/testing/tests/package/test_optee.py b/support/testing/tests/package/test_optee.py
> new file mode 100644
> index 0000000000..44cee74fd8
> --- /dev/null
> +++ b/support/testing/tests/package/test_optee.py
> @@ -0,0 +1,42 @@
> +import os
> +
> +import infra.basetest
> +
> +# This test enforces locally built emulator to prevent old Qemu to
> +# dump secure trace to stdio and corrupting trace synchro expected
> +# through pexpect.
> +
> +class TestOptee(infra.basetest.BRTest):
> +
> +    with open(os.path.join(os.getcwd(), 'configs',
> +                           'qemu_arm_vexpress_tz_defconfig'),
> +              'r') as config_file:

Regarding the use of open(), I see no better option here.

Regarding the use of os.getcwd(), I would prefer to have my patch applied
before this one:
http://patchwork.ozlabs.org/patch/992697/
So here you could use:
    with open(infra.basepath('configs/qemu_armv7a_tz_virt_defconfig'), 'r') as config_file:
This way we would keep the logic to get any path in a single point in the test
infra.
But this suggestion depends on what the maintainers think about my patch.
If you like the idea you can add my patch to your series.

> +        config = "".join(line for line in config_file if line[:1] != '#') + \
> +                 """

nit: for consistence with all other test cases, please use one less indent:
        config = "".join(line for line in config_file if line[:1] != '#') + \
            """

> +                 BR2_PACKAGE_HOST_QEMU=y
> +                 BR2_PACKAGE_HOST_QEMU_SYSTEM_MODE=y

Shouldn't these 2 lines be in the config_emulator below ...

> +                 BR2_TOOLCHAIN_EXTERNAL=y
> +                 """
> +    config_emulator = ''

... like this?
     config_emulator = \
         """
         BR2_PACKAGE_HOST_QEMU=y
         BR2_PACKAGE_HOST_QEMU_SYSTEM_MODE=y
         """

But see my question on patch 3 before changing this.

> +
> +    def test_run(self):
> +
> +        qemu_options = ['-machine', 'virt,secure=on']
> +        qemu_options.extend(['-cpu', 'cortex-a15'])
> +        qemu_options.extend(['-m', '1024'])
> +        qemu_options.extend(['-semihosting-config', 'enable,target=native'])
> +        qemu_options.extend(['-bios', 'bl1.bin'])
> +
> +        # This test expects Qemu is run from the image direcotry

s/direcotry/directory/

> +        os.chdir(os.path.join(self.builddir, 'images'))

This is not good.
When running multiple test cases, it will make any test case that runs after
this one to fail, see:

$ ./support/testing/run-tests -o o -k \
  tests.core.test_post_scripts.TestPostScripts \
  tests.package.test_optee.TestOptee
20:14:02 TestOptee                                Starting
20:17:01 TestOptee                                Cleaning up
.20:17:01 TestPostScripts                          Starting
E
======================================================================
ERROR: test_run (tests.core.test_post_scripts.TestPostScripts)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ricardo/src/buildroot/support/testing/infra/basetest.py", line 76, in setUp
    super(BRTest, self).setUp()
  File "/home/ricardo/src/buildroot/support/testing/infra/basetest.py", line 62, in setUp
    self.b.configure(make_extra_opts=["BR2_EXTERNAL={}".format(":".join(self.br2_external))])
  File "/home/ricardo/src/buildroot/support/testing/infra/builder.py", line 48, in configure
    raise SystemError("Cannot olddefconfig")
SystemError: Cannot olddefconfig

A better solution is to add a new optional parameter to Emulator.boot method,
perhaps named "cwd" that defaults to None and is passed to pexpect.spawn(...,
cwd=cwd) (not tested).
This way the Emulator class is aware that qemu must run from a directory, only
for the test cases that pass this.

> +
> +        self.emulator.boot(arch='armv7', options=qemu_options, local=True)
> +        self.emulator.login()
> +
> +        # Trick traces since xtest prints "# " which corrupts emulator run
> +        # method. Tests are dumped only if test fails.
> +        cmd = 'echo "Silent test takes a while, be patient..."; ' + \
> +              'xtest -t regression > /tmp/xtest.log ||' + \
> +              '(cat /tmp/xtest.log && false)'
> +        output, exit_code = self.emulator.run(cmd, timeout=240)

'output' is currently not tested.
It's better to use the convention:
        _, exit_code = self.emulator.run(cmd, timeout=240)

> +        self.assertEqual(exit_code, 0)
> -- 
> 2.17.1


Regards,
Ricardo

[Buildroot] [PATCH v3 3/4] support/testing: test can use the locally generated qemu host tool

[Thomas Petazzoni]

Hello Ricardo and Etienne,

On Sat, 30 Mar 2019 00:30:01 -0300
Ricardo Martincoski <ricardo.martincoski@gmail.com> wrote:

> I am not strongly against it.
> But let me ask:
> Are you or someone else having trouble with any other test case when using
> "old" qemu versions from host?
> 
> If the answer is no, maybe we should keep things simple and use a patch very
> similar to v2 of this one, just adding the host-qemu to the test case config
> fragment and the 'local' argument to Emulator.run.
> I say similar to v2 because I think your implementation in v3 with the
> 'qemu_bin' variable is better than v2.

I totally agree here. Having this option --local-emulator doesn't make
much sense. We would have to use it for some tests, but not for some
other tests.

Instead, we want each test to know whether it needs a recent enough
version of Qemu, or whether the system-provided Qemu version is good
enough.

> Another approach "to have an generic option to script run-tests to build the
> emulator within the test config" (quoting your reply to v2) would be:
> Instead of adding a command line argument to run-tests, create a new flag in
> the test case class, perhaps named "build_emulator". If that flag is True, the
> host-qemu is automatically added to the config fragment by the test infra. The
> same flag could be propagated to the Emulator.init so we don't need to pass
> 'local' to Emulator.run.

Yes, something like that sounds good.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH v3 3/4] support/testing: test can use the locally generated qemu host tool

[Etienne Carriere]

Hello Ricardo,
Hello Thomas,

Thanks for your feedback and sorry for this late answers.

On Tue, 2 Apr 2019 at 09:06, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello Ricardo and Etienne,
>
> On Sat, 30 Mar 2019 00:30:01 -0300
> Ricardo Martincoski <ricardo.martincoski@gmail.com> wrote:
>
> > I am not strongly against it.
> > But let me ask:
> > Are you or someone else having trouble with any other test case when using
> > "old" qemu versions from host?
> >
> > If the answer is no, maybe we should keep things simple and use a patch very
> > similar to v2 of this one, just adding the host-qemu to the test case config
> > fragment and the 'local' argument to Emulator.run.
> > I say similar to v2 because I think your implementation in v3 with the
> > 'qemu_bin' variable is better than v2.

Up to my knowledge, when running qemu-system-arm without secure world
emulation, old Qemu versions are fine (I.e. v2.x).
But when emulating arm w/ trustzone (qemu-system-arm -machine
secure=on ...), one must use at least Qemu v2.10, and recommended
version is v3.1.
- v2.10 is necessary, because of commit b29fd33db578 ("target/arm: use
DISAS_EXIT for eret handling") that is mandated.
- v3.1 is recommended since commit fb23d693a3e0 ("hw/arm/virt: add DT
property /secure-chosen/stdout-path indicating secure UART"). Without
this fix, secure/non-secure world consoles are mixed resulting in
weird traces (unless one fully disables secure world runtime traces).

>
> I totally agree here. Having this option --local-emulator doesn't make
> much sense. We would have to use it for some tests, but not for some
> other tests.
>
> Instead, we want each test to know whether it needs a recent enough
> version of Qemu, or whether the system-provided Qemu version is good
> enough.

Fair enough.

>
> > Another approach "to have an generic option to script run-tests to build the
> > emulator within the test config" (quoting your reply to v2) would be:
> > Instead of adding a command line argument to run-tests, create a new flag in
> > the test case class, perhaps named "build_emulator". If that flag is True, the
> > host-qemu is automatically added to the config fragment by the test infra. The
> > same flag could be propagated to the Emulator.init so we don't need to pass
> > 'local' to Emulator.run.

Ok, I think I see your idea.
I'll come up with a v4 for this whole patch series.

Thanks again
etienne

>
> Yes, something like that sounds good.
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

[Buildroot] [PATCH v3 4/4] support/testing: test_optee.py: test optee boot and testsuite

[Etienne Carriere]

Hello Ricardo,

On Sat, 30 Mar 2019 at 04:33, Ricardo Martincoski
<ricardo.martincoski@gmail.com> wrote:
>
> Hello,
>
> Looks good, except for the chdir stuff.
> Also a lot of nits below.
>
> On Fri, Mar 22, 2019 at 06:58 AM, Etienne Carriere wrote:
>
> [snip]
> > ---
> >  support/testing/tests/package/test_optee.py | 42 +++++++++++++++++++++
> >  1 file changed, 42 insertions(+)
> >  create mode 100644 support/testing/tests/package/test_optee.py
>
> Please run flake8 and fix the warning it generates.
> test_optee.py:9:1: E302 expected 2 blank lines, found 1

Sure, sorry. Python newbie bad habit.

>
> Please run 'make .gitlab-ci.yml'. BTW the same is also missing in the defconfig
> patch 2.

Ok.

>
> >
> > diff --git a/support/testing/tests/package/test_optee.py b/support/testing/tests/package/test_optee.py
> > new file mode 100644
> > index 0000000000..44cee74fd8
> > --- /dev/null
> > +++ b/support/testing/tests/package/test_optee.py
> > @@ -0,0 +1,42 @@
> > +import os
> > +
> > +import infra.basetest
> > +
> > +# This test enforces locally built emulator to prevent old Qemu to
> > +# dump secure trace to stdio and corrupting trace synchro expected
> > +# through pexpect.
> > +
> > +class TestOptee(infra.basetest.BRTest):
> > +
> > +    with open(os.path.join(os.getcwd(), 'configs',
> > +                           'qemu_arm_vexpress_tz_defconfig'),
> > +              'r') as config_file:
>
> Regarding the use of open(), I see no better option here.
>
> Regarding the use of os.getcwd(), I would prefer to have my patch applied
> before this one:
> http://patchwork.ozlabs.org/patch/992697/
> So here you could use:
>     with open(infra.basepath('configs/qemu_armv7a_tz_virt_defconfig'), 'r') as config_file:
> This way we would keep the logic to get any path in a single point in the test
> infra.
> But this suggestion depends on what the maintainers think about my patch.
> If you like the idea you can add my patch to your series.

Ok, thanks, it will be more consistent with the runtime env.
Maybe I could simply merge your proposal in my change (and append your
s-o-b tag to it), if you agree.

>
> > +        config = "".join(line for line in config_file if line[:1] != '#') + \
> > +                 """
>
> nit: for consistence with all other test cases, please use one less indent:
>         config = "".join(line for line in config_file if line[:1] != '#') + \
>             """

ok.

>
> > +                 BR2_PACKAGE_HOST_QEMU=y
> > +                 BR2_PACKAGE_HOST_QEMU_SYSTEM_MODE=y
>
> Shouldn't these 2 lines be in the config_emulator below ...
>
> > +                 BR2_TOOLCHAIN_EXTERNAL=y
> > +                 """
> > +    config_emulator = ''
>
> ... like this?
>      config_emulator = \
>          """
>          BR2_PACKAGE_HOST_QEMU=y
>          BR2_PACKAGE_HOST_QEMU_SYSTEM_MODE=y
>          """

yes. true.

> But see my question on patch 3 before changing this.
>

true again, I think I will remove this config_emulator from the test
case and move it to a generic config in basetest.py.


>
> > +
> > +    def test_run(self):
> > +
> > +        qemu_options = ['-machine', 'virt,secure=on']
> > +        qemu_options.extend(['-cpu', 'cortex-a15'])
> > +        qemu_options.extend(['-m', '1024'])
> > +        qemu_options.extend(['-semihosting-config', 'enable,target=native'])
> > +        qemu_options.extend(['-bios', 'bl1.bin'])
> > +
> > +        # This test expects Qemu is run from the image direcotry
>
> s/direcotry/directory/

thanks.

>
> > +        os.chdir(os.path.join(self.builddir, 'images'))
>
> This is not good.
> When running multiple test cases, it will make any test case that runs after
> this one to fail, see:
>
> $ ./support/testing/run-tests -o o -k \
>   tests.core.test_post_scripts.TestPostScripts \
>   tests.package.test_optee.TestOptee
> 20:14:02 TestOptee                                Starting
> 20:17:01 TestOptee                                Cleaning up
> .20:17:01 TestPostScripts                          Starting
> E
> ======================================================================
> ERROR: test_run (tests.core.test_post_scripts.TestPostScripts)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/home/ricardo/src/buildroot/support/testing/infra/basetest.py", line 76, in setUp
>     super(BRTest, self).setUp()
>   File "/home/ricardo/src/buildroot/support/testing/infra/basetest.py", line 62, in setUp
>     self.b.configure(make_extra_opts=["BR2_EXTERNAL={}".format(":".join(self.br2_external))])
>   File "/home/ricardo/src/buildroot/support/testing/infra/builder.py", line 48, in configure
>     raise SystemError("Cannot olddefconfig")
> SystemError: Cannot olddefconfig
>
> A better solution is to add a new optional parameter to Emulator.boot method,
> perhaps named "cwd" that defaults to None and is passed to pexpect.spawn(...,
> cwd=cwd) (not tested).
> This way the Emulator class is aware that qemu must run from a directory, only
> for the test cases that pass this.

Ok. Indeed my proposal is bad.
I will go this way, and try to come up with something not too ugly.

>
> > +
> > +        self.emulator.boot(arch='armv7', options=qemu_options, local=True)
> > +        self.emulator.login()
> > +
> > +        # Trick traces since xtest prints "# " which corrupts emulator run
> > +        # method. Tests are dumped only if test fails.
> > +        cmd = 'echo "Silent test takes a while, be patient..."; ' + \
> > +              'xtest -t regression > /tmp/xtest.log ||' + \
> > +              '(cat /tmp/xtest.log && false)'
> > +        output, exit_code = self.emulator.run(cmd, timeout=240)
>
> 'output' is currently not tested.
> It's better to use the convention:
>         _, exit_code = self.emulator.run(cmd, timeout=240)

Ok thanks, will fix.

>
> > +        self.assertEqual(exit_code, 0)
> > --
> > 2.17.1
>
>
> Regards,
> Ricardo

Thanks again for your feedback.

Regards,
etienne

[Buildroot] [PATCH v3 4/4] support/testing: test_optee.py: test optee boot and testsuite

[Ricardo Martincoski]

Hello,

On Wed, Apr 03, 2019 at 07:19 AM, Etienne Carriere wrote:

[snip]
>> > +class TestOptee(infra.basetest.BRTest):
>> > +
>> > +    with open(os.path.join(os.getcwd(), 'configs',
>> > +                           'qemu_arm_vexpress_tz_defconfig'),
>> > +              'r') as config_file:
>>
>> Regarding the use of open(), I see no better option here.
>>
>> Regarding the use of os.getcwd(), I would prefer to have my patch applied
>> before this one:
>> http://patchwork.ozlabs.org/patch/992697/
>> So here you could use:
>>     with open(infra.basepath('configs/qemu_armv7a_tz_virt_defconfig'), 'r') as config_file:
>> This way we would keep the logic to get any path in a single point in the test
>> infra.
>> But this suggestion depends on what the maintainers think about my patch.
>> If you like the idea you can add my patch to your series.
> 
> Ok, thanks, it will be more consistent with the runtime env.
> Maybe I could simply merge your proposal in my change (and append your
> s-o-b tag to it), if you agree.

I prefer my patch to stay as a separate commit because it changes how run-tests
can be called. Currently we can chdir to one buildroot tree and call run-tests
from another buildroot tree. Currently we also need to be in the buildroot top
dir when we call run-tests. After that patch when run-tests is called it will
execute in (and consequently test) the buildroot tree it belongs to, no matter
which is the current directory when run-tests is called.
That patch can still be applied with 'git am -3'.

But feel free to just grab only part of the code from there if you want to. No
need for my SoB if you use only part of it. Maybe something like this is enough:

def basepath(relpath=""):
    return os.path.join(os.getcwd(), relpath)

This way we have all calls to os.getcwd() in support/testing/infra/__init__.py
and I resend my patch later.

But also feel free to not do this right now. Up to you.


Regards,
Ricardo

[Buildroot] [PATCH v3 4/4] support/testing: test_optee.py: test optee boot and testsuite

[Etienne Carriere]

On Thu, 4 Apr 2019 at 05:30, Ricardo Martincoski
<ricardo.martincoski@gmail.com> wrote:
>
> Hello,
>
> On Wed, Apr 03, 2019 at 07:19 AM, Etienne Carriere wrote:
>
> [snip]
> >> > +class TestOptee(infra.basetest.BRTest):
> >> > +
> >> > +    with open(os.path.join(os.getcwd(), 'configs',
> >> > +                           'qemu_arm_vexpress_tz_defconfig'),
> >> > +              'r') as config_file:
> >>
> >> Regarding the use of open(), I see no better option here.
> >>
> >> Regarding the use of os.getcwd(), I would prefer to have my patch applied
> >> before this one:
> >> http://patchwork.ozlabs.org/patch/992697/
> >> So here you could use:
> >>     with open(infra.basepath('configs/qemu_armv7a_tz_virt_defconfig'), 'r') as config_file:
> >> This way we would keep the logic to get any path in a single point in the test
> >> infra.
> >> But this suggestion depends on what the maintainers think about my patch.
> >> If you like the idea you can add my patch to your series.
> >
> > Ok, thanks, it will be more consistent with the runtime env.
> > Maybe I could simply merge your proposal in my change (and append your
> > s-o-b tag to it), if you agree.
>
> I prefer my patch to stay as a separate commit because it changes how run-tests
> can be called. (...)

Oh, yes, sorry! I misunderstood your previous comment.
Sure, I won't merge your change and mine :)
Thanks for the clarification. I'll focus on this cwd() issue you
suggest and o which extend I need to take your proposal into account
in my change.

Regards,
etienne

> (...) Currently we can chdir to one buildroot tree and call run-tests
> from another buildroot tree. Currently we also need to be in the buildroot top
> dir when we call run-tests. After that patch when run-tests is called it will
> execute in (and consequently test) the buildroot tree it belongs to, no matter
> which is the current directory when run-tests is called.
> That patch can still be applied with 'git am -3'.
>
> But feel free to just grab only part of the code from there if you want to. No
> need for my SoB if you use only part of it. Maybe something like this is enough:
>
> def basepath(relpath=""):
>     return os.path.join(os.getcwd(), relpath)
>
> This way we have all calls to os.getcwd() in support/testing/infra/__init__.py
> and I resend my patch later.
>
> But also feel free to not do this right now. Up to you.
>
>
> Regards,
> Ricardo

[Buildroot] [PATCH v3 2/4] configs/qemu_arm_vexpress_tz: Armv7-A emulation with TrustZone services

[Arnout Vandecappelle]

 Hi Etienne,

On 22/03/2019 10:58, Etienne Carriere 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.
> 
> qemu_arm_vexpress_tz_defconfig differs from qemu_arm_vexpress_defconfig.
> Supporting both secure and non-secure worlds on the Arm target mandates
> a secure world, here OP-TEE OS, and a bootloader to boot both worlds,
> here TF-A (boot/arm-trusted-firmware). Here non-secure Linux kernel is
> booted through U-boot
> 
>   TF-A bootloader (BL1/BL2) => OP-TEE (BL32) => U-boot (BL33).
>   | Executes as secure         | Secure         | Execs as Non-secure
>   | Loads BL32/BL33 in RAM     | Jumps to BL33  | Always booted after
>   | Jumps to BL32 once done    | as Non-secure  | secure world inits
> 
> Vexpress and vexpress-tz defconfigs also differs in that Qemu emulates
> a Cortex-A9 in the former and a Cortex-A15 in the later. Cortex-A15
> is the Armv7-A CPU used in upstream TF-A and OP-TEE OS packages hence
> selected here.
> 
> Defconfig adds a fragment to the Linux kernel native configuration to
> enable OP-TEE driver support.
> 
> Defconfig adds a fragment to the U-Boot native configuration set boot
> command, enable semihosting and remove U-Boot persistent environment
> storage support.
> 
> The defconfig also enables build of the Qemu emulator in case the
> system installed Qemu does not yet support CPU TrustZone secure state.
> 
> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>

 Applied to master, thanks, but with some changes...

 First of all, thank you for the very extensive and clear commit message and
readme file.


[snip]
> +Board qemu_arm_vexpress_tz builds a Qemu Armv7-A target system with
> +OP-TEE running in the TrustZone secure world and a Linux based
> +OS running in the non-secure world. The board configuration enable
> +builds of the Qemu host Arm target emulator.
> +
> +  make qemu_arm_vexpress_tz_defconfig
> +  make
> +
> +BIOS used in the Qemu host is the Arm Trusted Firmware-A (TF-A). TF-A
> +uses Qemu semihosting file access to access boot image files. The
> +Qemu platform is quite specific for that in TF-A and one needs to
> +run the emulation from the image directory for TF-A to boot the
> +secure and non-secure worlds.

 This semihosting approach is not so nice, because it only works on qemu. It
would be nicer to have a single image that contains everything (except bl1 I
guess) and use that as virtual flash, so it matches what would happen on a real
board. But this is not a bad start, and it might make debugging the optee part
easier.

> +
> +  cd output/images && ../host/bin/qemu-system-arm \
> +	-machine virt -machine secure=on -cpu cortex-a15 \
> +	-smp 1 -s -m 1024 -d unimp \
> +	-serial stdio \
> +	-netdev user,id=vmnic -device virtio-net-device,netdev=vmnic \
> +	-semihosting-config enable,target=native \
> +	-bios bl1.bin

 I'm a bit worried that the script in the toolchains-builder will not be able to
parse this. But because of the cd, it will anyway not work, so OK. It anyway
looks a lot nicer like this than how it's done in the other readmes.

[snip]
> @@ -0,0 +1,47 @@
> +# Architecture
> +BR2_arm=y
> +BR2_cortex_a15=y
> +BR2_ARM_ENABLE_NEON=y
> +BR2_ARM_ENABLE_VFP=y
> +BR2_ARM_FPU_VFPV3D16=y
> +# System

 Please add an empty line before the different sections.

> +BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
> +# Filesystems (support several boot config)
> +BR2_TARGET_ROOTFS_CPIO=y
> +BR2_TARGET_ROOTFS_CPIO_GZIP=y
> +BR2_TARGET_ROOTFS_EXT2=y

 There's no reason at all to add ext2 and tar, so I removed both of them. If you
want to support several boot configs, it should be mentioned in the readme file
how to do that.

> +# Generic
> +BR2_ROOTFS_POST_BUILD_SCRIPT="board/qemu/arm-vexpress-tz/post-build.sh"
> +# Linux 4.19 series
> +BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_19=y
> +BR2_LINUX_KERNEL=y
> +BR2_LINUX_KERNEL_CUSTOM_VERSION=y
> +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.19.16"
> +BR2_LINUX_KERNEL_DEFCONFIG="vexpress"
> +BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES="board/qemu/arm-vexpress-tz/linux.fragment"
> +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
> +BR2_TARGET_ARM_TRUSTED_FIRMWARE=y
> +BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_GIT=y
> +BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_REPO_URL="https://github.com/ARM-software/arm-trusted-firmware.git"
> +BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_REPO_VERSION="v2.0"

 There is a version selection available now, so I used that instead of the git
download.

 BTW, our current ATF version is still v1.4, maybe it should be bumped?

> +BR2_TARGET_ARM_TRUSTED_FIRMWARE_PLATFORM="qemu"
> +BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL32_OPTEE=y
> +BR2_TARGET_ARM_TRUSTED_FIRMWARE_UBOOT_AS_BL33=y
> +BR2_TARGET_ARM_TRUSTED_FIRMWARE_ADDITIONAL_VARIABLES="BL32_RAM_LOCATION=tdram"
> +# OP-TEE components
> +BR2_TARGET_OPTEE_OS=y
> +BR2_TARGET_OPTEE_OS_PLATFORM="vexpress-qemu_virt"
> +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

 You have to specify the U-Boot version. I'm not sure what you tested with, but
I used 2019.01 and it worked.

> +BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y
> +BR2_TARGET_UBOOT_BOARD_DEFCONFIG="qemu_arm"
> +BR2_TARGET_UBOOT_CONFIG_FRAGMENT_FILES="board/qemu/arm-vexpress-tz/u-boot.config"
> +# Build Qemu emulator for the Arm target

 I changed this in what we use everywhere else: host-qemu for gitlab testing

 Regards,
 Arnout

> +BR2_PACKAGE_HOST_QEMU=y
> +BR2_PACKAGE_HOST_QEMU_SYSTEM_MODE=y
> 

[Buildroot] [PATCH v3 1/4] boot/arm-trusted-firmware: support alternate image files

[Arnout Vandecappelle]

On 22/03/2019 10:58, Etienne Carriere wrote:
> Some platform may generate specific boot image files instead of
> the generic files *.bin  when building TF-A package.

 This is still very vague, and it doesn't have any in-tree user. Therefore,
we're not prepared to merge this patch. Do you have a concrete example,
preferably with a defconfig that actually makes use of it?

 I've therefore marked this patch as Changes Requested.

 Regards,
 Arnout

> This change
> introduces new configuration directive for the arm-trusted-firmware
> boot package.
> 
> BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_IMAGE_NAMES is boolean.
> When disabled, install boot image files are .../*.bin.
> When enabled, BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL_IMAGE_NAMES shall
> lists the names of the generated boot image files.
> 
> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
[snip]

[Buildroot] [PATCH v3 2/4] configs/qemu_arm_vexpress_tz: Armv7-A emulation with TrustZone services

[Etienne Carriere]

On Sun, 27 Oct 2019 at 15:55, Arnout Vandecappelle <arnout@mind.be> wrote:
>
>  Hi Etienne,
>
> On 22/03/2019 10:58, Etienne Carriere 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.
> >
> > qemu_arm_vexpress_tz_defconfig differs from qemu_arm_vexpress_defconfig.
> > Supporting both secure and non-secure worlds on the Arm target mandates
> > a secure world, here OP-TEE OS, and a bootloader to boot both worlds,
> > here TF-A (boot/arm-trusted-firmware). Here non-secure Linux kernel is
> > booted through U-boot
> >
> >   TF-A bootloader (BL1/BL2) => OP-TEE (BL32) => U-boot (BL33).
> >   | Executes as secure         | Secure         | Execs as Non-secure
> >   | Loads BL32/BL33 in RAM     | Jumps to BL33  | Always booted after
> >   | Jumps to BL32 once done    | as Non-secure  | secure world inits
> >
> > Vexpress and vexpress-tz defconfigs also differs in that Qemu emulates
> > a Cortex-A9 in the former and a Cortex-A15 in the later. Cortex-A15
> > is the Armv7-A CPU used in upstream TF-A and OP-TEE OS packages hence
> > selected here.
> >
> > Defconfig adds a fragment to the Linux kernel native configuration to
> > enable OP-TEE driver support.
> >
> > Defconfig adds a fragment to the U-Boot native configuration set boot
> > command, enable semihosting and remove U-Boot persistent environment
> > storage support.
> >
> > The defconfig also enables build of the Qemu emulator in case the
> > system installed Qemu does not yet support CPU TrustZone secure state.
> >
> > Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
>
>  Applied to master, thanks, but with some changes...
>
> [snip]
> > +Board qemu_arm_vexpress_tz builds a Qemu Armv7-A target system with
> > +OP-TEE running in the TrustZone secure world and a Linux based
> > +OS running in the non-secure world. The board configuration enable
> > +builds of the Qemu host Arm target emulator.
> > +
> > +  make qemu_arm_vexpress_tz_defconfig
> > +  make
> > +
> > +BIOS used in the Qemu host is the Arm Trusted Firmware-A (TF-A). TF-A
> > +uses Qemu semihosting file access to access boot image files. The
> > +Qemu platform is quite specific for that in TF-A and one needs to
> > +run the emulation from the image directory for TF-A to boot the
> > +secure and non-secure worlds.
>
>  This semihosting approach is not so nice, because it only works on qemu. It
> would be nicer to have a single image that contains everything (except bl1 I
> guess) and use that as virtual flash, so it matches what would happen on a real
> board. But this is not a bad start, and it might make debugging the optee part
> easier.
>
> > +
> > +  cd output/images && ../host/bin/qemu-system-arm \
> > +     -machine virt -machine secure=on -cpu cortex-a15 \
> > +     -smp 1 -s -m 1024 -d unimp \
> > +     -serial stdio \
> > +     -netdev user,id=vmnic -device virtio-net-device,netdev=vmnic \
> > +     -semihosting-config enable,target=native \
> > +     -bios bl1.bin
>
>  I'm a bit worried that the script in the toolchains-builder will not be able to
> parse this. But because of the cd, it will anyway not work, so OK. It anyway
> looks a lot nicer like this than how it's done in the other readmes.

Thanks,

>
> [snip]
> > @@ -0,0 +1,47 @@
> > +# Architecture
> > +BR2_arm=y
> > +BR2_cortex_a15=y
> > +BR2_ARM_ENABLE_NEON=y
> > +BR2_ARM_ENABLE_VFP=y
> > +BR2_ARM_FPU_VFPV3D16=y
> > +# System
>
>  Please add an empty line before the different sections.
>
> > +BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
> > +# Filesystems (support several boot config)
> > +BR2_TARGET_ROOTFS_CPIO=y
> > +BR2_TARGET_ROOTFS_CPIO_GZIP=y
> > +BR2_TARGET_ROOTFS_EXT2=y
>
>  There's no reason at all to add ext2 and tar, so I removed both of them. If you
> want to support several boot configs, it should be mentioned in the readme file
> how to do that.
>
> > +# Generic
> > +BR2_ROOTFS_POST_BUILD_SCRIPT="board/qemu/arm-vexpress-tz/post-build.sh"
> > +# Linux 4.19 series
> > +BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_19=y
> > +BR2_LINUX_KERNEL=y
> > +BR2_LINUX_KERNEL_CUSTOM_VERSION=y
> > +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.19.16"
> > +BR2_LINUX_KERNEL_DEFCONFIG="vexpress"
> > +BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES="board/qemu/arm-vexpress-tz/linux.fragment"
> > +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
> > +BR2_TARGET_ARM_TRUSTED_FIRMWARE=y
> > +BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_GIT=y
> > +BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_REPO_URL="https://github.com/ARM-software/arm-trusted-firmware.git"
> > +BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_REPO_VERSION="v2.0"
>
>  There is a version selection available now, so I used that instead of the git
> download.
>
>  BTW, our current ATF version is still v1.4, maybe it should be bumped?
>
> > +BR2_TARGET_ARM_TRUSTED_FIRMWARE_PLATFORM="qemu"
> > +BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL32_OPTEE=y
> > +BR2_TARGET_ARM_TRUSTED_FIRMWARE_UBOOT_AS_BL33=y
> > +BR2_TARGET_ARM_TRUSTED_FIRMWARE_ADDITIONAL_VARIABLES="BL32_RAM_LOCATION=tdram"
> > +# OP-TEE components
> > +BR2_TARGET_OPTEE_OS=y
> > +BR2_TARGET_OPTEE_OS_PLATFORM="vexpress-qemu_virt"
> > +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
>
>  You have to specify the U-Boot version. I'm not sure what you tested with, but
> I used 2019.01 and it worked.

Would be nice to use BR2_TARGET_UBOOT_LATEST_VERSION.
BR2_TARGET_UBOOT_LATEST_VERSION=y

As for the linux kernel, i wonder if the generic config would be better?


>
> > +BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y
> > +BR2_TARGET_UBOOT_BOARD_DEFCONFIG="qemu_arm"
> > +BR2_TARGET_UBOOT_CONFIG_FRAGMENT_FILES="board/qemu/arm-vexpress-tz/u-boot.config"
> > +# Build Qemu emulator for the Arm target
>
>  I changed this in what we use everywhere else: host-qemu for gitlab testing

Thanks.

Regards,
Etienne

>
>  Regards,
>  Arnout
>
> > +BR2_PACKAGE_HOST_QEMU=y
> > +BR2_PACKAGE_HOST_QEMU_SYSTEM_MODE=y
> >

[Buildroot] [PATCH v3 2/4] configs/qemu_arm_vexpress_tz: Armv7-A emulation with TrustZone services

[Etienne Carriere]

On Tue, 29 Oct 2019 at 09:08, Etienne Carriere
<etienne.carriere@linaro.org> wrote:
>
> On Sun, 27 Oct 2019 at 15:55, Arnout Vandecappelle <arnout@mind.be> wrote:
> > [snip]
> >
> > > +BR2_TARGET_UBOOT=y
> >
> >  You have to specify the U-Boot version. I'm not sure what you tested with, but
> > I used 2019.01 and it worked.
>
> Would be nice to use BR2_TARGET_UBOOT_LATEST_VERSION.
> BR2_TARGET_UBOOT_LATEST_VERSION=y
>
> As for the linux kernel, i wonder if the generic config would be better?

Sorry: mail popped from my fingers while I was typing.

I meant, would it be better if the qemu/tz defconfig is based on:
BR2_TARGET_UBOOT_LATEST_VERSION=y
BR2_LINUX_KERNEL_LATEST_VERSION=y
BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG=y

Regards,
Etienne

[Buildroot] [PATCH v3 1/4] boot/arm-trusted-firmware: support alternate image files

[Etienne Carriere]

Hello Thomans and all,

On Sun, 27 Oct 2019 at 15:59, Arnout Vandecappelle <arnout@mind.be> wrote:
>
>
>
> On 22/03/2019 10:58, Etienne Carriere wrote:
> > Some platform may generate specific boot image files instead of
> > the generic files *.bin  when building TF-A package.
>
>  This is still very vague, and it doesn't have any in-tree user. Therefore,
> we're not prepared to merge this patch. Do you have a concrete example,
> preferably with a defconfig that actually makes use of it?

Well, I will consider when there is an in-tree board that needs this :)

Actually, this is some kind of equivalent for optee-os
BR2_TARGET_OPTEE_OS_IMAGE_NAMES
or even u-boot BR2_TARGET_UBOOT_FORMAT_CUSTOM.

Regards,
Etienne

>  I've therefore marked this patch as Changes Requested.
>
>  Regards,
>  Arnout
>
> > This change
> > introduces new configuration directive for the arm-trusted-firmware
> > boot package.
> >
> > BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_IMAGE_NAMES is boolean.
> > When disabled, install boot image files are .../*.bin.
> > When enabled, BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL_IMAGE_NAMES shall
> > lists the names of the generated boot image files.
> >
> > Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
> [snip]

[Buildroot] [PATCH v3 2/4] configs/qemu_arm_vexpress_tz: Armv7-A emulation with TrustZone services

[Arnout Vandecappelle]

On 29/10/2019 09:11, Etienne Carriere wrote:
> On Tue, 29 Oct 2019 at 09:08, Etienne Carriere
> <etienne.carriere@linaro.org> wrote:
>>
>> On Sun, 27 Oct 2019 at 15:55, Arnout Vandecappelle <arnout@mind.be> wrote:
>>> [snip]
>>>
>>>> +BR2_TARGET_UBOOT=y
>>>
>>>  You have to specify the U-Boot version. I'm not sure what you tested with, but
>>> I used 2019.01 and it worked.
>>
>> Would be nice to use BR2_TARGET_UBOOT_LATEST_VERSION.
>> BR2_TARGET_UBOOT_LATEST_VERSION=y
>>
>> As for the linux kernel, i wonder if the generic config would be better?
> 
> Sorry: mail popped from my fingers while I was typing.
> 
> I meant, would it be better if the qemu/tz defconfig is based on:
> BR2_TARGET_UBOOT_LATEST_VERSION=y
> BR2_LINUX_KERNEL_LATEST_VERSION=y
> BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG=y

 You original submission had this, and that didn't build because some of the
config options were invalid. That shows that you *have* to have the version.

 Regards,
 Arnout

[Buildroot] [PATCH v3 2/4] configs/qemu_arm_vexpress_tz: Armv7-A emulation with TrustZone services

[Thomas Petazzoni]

Hello Etienne,

On Fri, 22 Mar 2019 10:58:16 +0100
Etienne Carriere <etienne.carriere@linaro.org> wrote:

>  board/qemu/arm-vexpress-tz/linux.fragment |   3 +
>  board/qemu/arm-vexpress-tz/post-build.sh  |  10 ++
>  board/qemu/arm-vexpress-tz/readme.txt     | 135 ++++++++++++++++++++++
>  board/qemu/arm-vexpress-tz/u-boot.config  |   7 ++
>  configs/qemu_arm_vexpress_tz_defconfig    |  47 ++++++++
>  5 files changed, 202 insertions(+)

This defconfig causes a build failure, reported at
https://gitlab.com/buildroot.org/buildroot/-/jobs/389451835, like this:

486 Traceback (most recent call last):
487   File "scripts/pem_to_pub_c.py", line 61, in <module>
488     main()
489   File "scripts/pem_to_pub_c.py", line 24, in main
490     from Crypto.PublicKey import RSA
491 ImportError: No module named 'Crypto'

Could you have a look ?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH v3 2/4] configs/qemu_arm_vexpress_tz: Armv7-A emulation with TrustZone services

[Etienne Carriere]

Hello Thomas and all,

My best wishes for this new year to you and your beloved.


On Sat, 28 Dec 2019 at 12:35, Thomas Petazzoni <thomas.petazzoni@bootlin.com>
wrote:

> Hello Etienne,
>
> On Fri, 22 Mar 2019 10:58:16 +0100
> Etienne Carriere <etienne.carriere@linaro.org> wrote:
>
> >  board/qemu/arm-vexpress-tz/linux.fragment |   3 +
> >  board/qemu/arm-vexpress-tz/post-build.sh  |  10 ++
> >  board/qemu/arm-vexpress-tz/readme.txt     | 135 ++++++++++++++++++++++
> >  board/qemu/arm-vexpress-tz/u-boot.config  |   7 ++
> >  configs/qemu_arm_vexpress_tz_defconfig    |  47 ++++++++
> >  5 files changed, 202 insertions(+)
>
> This defconfig causes a build failure, reported at
> https://gitlab.com/buildroot.org/buildroot/-/jobs/389451835, like this:
>
> 486 Traceback (most recent call last):
> 487   File "scripts/pem_to_pub_c.py", line 61, in <module>
> 488     main()
> 489   File "scripts/pem_to_pub_c.py", line 24, in main
> 490     from Crypto.PublicKey import RSA
> 491 ImportError: No module named 'Crypto'
>
> Could you have a look ?
>

This issue was reported by Romain [1] when I posted an upgrade from
optee-3.5.0 to 3.7.0 in BR.
Actually, I'm still not sure I really understand the issue since optee-os.mk
already specifies pycrypto as a dependency.

OPTEE_OS_DEPENDENCIES = host-openssl host-python-pycrypto
host-python-pyelftools

Maybe it is an issue related to python versioning (2 vs 3)?
I'll try to have a look in the coming... days, but I quite busy on some
other topics.
Will do my best :|

Regards,
Etienne

[1]
http://buildroot-busybox.2317881.n4.nabble.com/PATCH-1-5-boot-optee-os-bump-version-to-3-7-0-tp237817p239519.html



> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200107/1b4a1431/attachment.html>

[Buildroot] [PATCH v3 2/4] configs/qemu_arm_vexpress_tz: Armv7-A emulation with TrustZone services

[Romain Naour]

Hi Etienne,

Le 07/01/2020 ? 08:56, Etienne Carriere a ?crit?:
> Hello Thomas and all,
> 
> My best wishes?for this new year to you and your beloved.
> 
> 
> On Sat, 28 Dec 2019 at 12:35, Thomas Petazzoni <thomas.petazzoni@bootlin.com
> <mailto:thomas.petazzoni@bootlin.com>> wrote:
> 
>     Hello Etienne,
> 
>     On Fri, 22 Mar 2019 10:58:16 +0100
>     Etienne Carriere <etienne.carriere@linaro.org
>     <mailto:etienne.carriere@linaro.org>> wrote:
> 
>     >? board/qemu/arm-vexpress-tz/linux.fragment |? ?3 +
>     >? board/qemu/arm-vexpress-tz/post-build.sh? |? 10 ++
>     >? board/qemu/arm-vexpress-tz/readme.txt? ? ?| 135 ++++++++++++++++++++++
>     >? board/qemu/arm-vexpress-tz/u-boot.config? |? ?7 ++
>     >? configs/qemu_arm_vexpress_tz_defconfig? ? |? 47 ++++++++
>     >? 5 files changed, 202 insertions(+)
> 
>     This defconfig causes a build failure, reported at
>     https://gitlab.com/buildroot.org/buildroot/-/jobs/389451835, like this:
> 
>     486 Traceback (most recent call last):
>     487? ?File "scripts/pem_to_pub_c.py", line 61, in <module>
>     488? ? ?main()
>     489? ?File "scripts/pem_to_pub_c.py", line 24, in main
>     490? ? ?from Crypto.PublicKey import RSA
>     491 ImportError: No module named 'Crypto'
> 
>     Could you have a look ?
> 
> 
> This issue was reported by Romain [1] when I posted an upgrade from optee-3.5.0
> to 3.7.0 in BR.
> Actually, I'm still not sure?I really understand the issue since optee-os.mk
> <http://optee-os.mk> already specifies pycrypto as a dependency.
> 
> OPTEE_OS_DEPENDENCIES = host-openssl host-python-pycrypto host-python-pyelftools
> 
> Maybe it is an issue related to?python?versioning (2 vs 3)?
> I'll try to have a look in the coming... days, but I quite busy on some other
> topics.
> Will do my best :|

Indeed, this is an issue related to host-python dependencies.

Since optee-3.7.0 all scripts are python3 only [1] but the optee package still
depends on host-python (python2).

But even if we modify to use host-python3, we still need host-python3 modules
being build for python3 (host-python-pycrypto host-python-pyelftools). Since we
can't build host python modules for both python2 and python3, the issue appear
again when host-python (python2) is used as host python interpreter.

This is a similar issue that for mesa3d where host-python3-make package was
introduced to be able to build. We can fixes this issue by adding
host-python3-pycrypto host-python3-pyelftools package (and reverse dependencies
if any).

I guess we don't have the issue only if python3 and pycrypto pyelftools are
installed on the host.

[1]
https://github.com/OP-TEE/optee_os/commit/bbaeed4dc6258006e846543197b8aff95d80abbf

Best regards,
Romain

> 
> Regards,
> Etienne
> 
> [1]
> http://buildroot-busybox.2317881.n4.nabble.com/PATCH-1-5-boot-optee-os-bump-version-to-3-7-0-tp237817p239519.html
> 
> ?
> 
>     Best regards,
> 
>     Thomas
>     -- 
>     Thomas Petazzoni, CTO, Bootlin
>     Embedded Linux and Kernel engineering
>     https://bootlin.com
> 
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 

[Buildroot] [PATCH v3 2/4] configs/qemu_arm_vexpress_tz: Armv7-A emulation with TrustZone services

[Romain Naour]

Hi Etienne,

Le 09/02/2020 ? 18:55, Romain Naour a ?crit?:
> Hi Etienne,
> 
> Le 07/01/2020 ? 08:56, Etienne Carriere a ?crit?:
>> Hello Thomas and all,
>>
>> My best wishes?for this new year to you and your beloved.
>>
>>
>> On Sat, 28 Dec 2019 at 12:35, Thomas Petazzoni <thomas.petazzoni@bootlin.com
>> <mailto:thomas.petazzoni@bootlin.com>> wrote:
>>
>>     Hello Etienne,
>>
>>     On Fri, 22 Mar 2019 10:58:16 +0100
>>     Etienne Carriere <etienne.carriere@linaro.org
>>     <mailto:etienne.carriere@linaro.org>> wrote:
>>
>>     >? board/qemu/arm-vexpress-tz/linux.fragment |? ?3 +
>>     >? board/qemu/arm-vexpress-tz/post-build.sh? |? 10 ++
>>     >? board/qemu/arm-vexpress-tz/readme.txt? ? ?| 135 ++++++++++++++++++++++
>>     >? board/qemu/arm-vexpress-tz/u-boot.config? |? ?7 ++
>>     >? configs/qemu_arm_vexpress_tz_defconfig? ? |? 47 ++++++++
>>     >? 5 files changed, 202 insertions(+)
>>
>>     This defconfig causes a build failure, reported at
>>     https://gitlab.com/buildroot.org/buildroot/-/jobs/389451835, like this:
>>
>>     486 Traceback (most recent call last):
>>     487? ?File "scripts/pem_to_pub_c.py", line 61, in <module>
>>     488? ? ?main()
>>     489? ?File "scripts/pem_to_pub_c.py", line 24, in main
>>     490? ? ?from Crypto.PublicKey import RSA
>>     491 ImportError: No module named 'Crypto'
>>
>>     Could you have a look ?
>>
>>
>> This issue was reported by Romain [1] when I posted an upgrade from optee-3.5.0
>> to 3.7.0 in BR.
>> Actually, I'm still not sure?I really understand the issue since optee-os.mk
>> <http://optee-os.mk> already specifies pycrypto as a dependency.
>>
>> OPTEE_OS_DEPENDENCIES = host-openssl host-python-pycrypto host-python-pyelftools
>>
>> Maybe it is an issue related to?python?versioning (2 vs 3)?
>> I'll try to have a look in the coming... days, but I quite busy on some other
>> topics.
>> Will do my best :|
> 
> Indeed, this is an issue related to host-python dependencies.
> 
> Since optee-3.7.0 all scripts are python3 only [1] but the optee package still
> depends on host-python (python2).
> 
> But even if we modify to use host-python3, we still need host-python3 modules
> being build for python3 (host-python-pycrypto host-python-pyelftools). Since we
> can't build host python modules for both python2 and python3, the issue appear
> again when host-python (python2) is used as host python interpreter.
> 
> This is a similar issue that for mesa3d where host-python3-make package was
> introduced to be able to build. We can fixes this issue by adding
> host-python3-pycrypto host-python3-pyelftools package (and reverse dependencies
> if any).
> 
> I guess we don't have the issue only if python3 and pycrypto pyelftools are
> installed on the host.
> 
> [1]
> https://github.com/OP-TEE/optee_os/commit/bbaeed4dc6258006e846543197b8aff95d80abbf

I tried to build this defconfig with host-python3 as default python interpreter
(by selecting python3 on the target) but there are several other issues:

First python-pycrypto doesn't work with python-3.8 due to time.clock() that was
removed from python 3.8.

There is a patch pending:
https://github.com/dlitz/pycrypto/pull/296/commits/6d41ad025331afce9e495d7be3205730ddfa8f07

The build continue up to optee-test package:

>>> optee-test 3.7.0 Building
Traceback (most recent call last):
  File "../../scripts/file_to_c.py", line 48, in <module>
[...]
TypeError: cannot use a str to initialize an array with typecode 'B'

So, it seems the optee stack is not in good shape due to python 3.8 bump.

Can you take a look?

Best regards,
Romain

> 
> Best regards,
> Romain
> 
>>
>> Regards,
>> Etienne
>>
>> [1]
>> http://buildroot-busybox.2317881.n4.nabble.com/PATCH-1-5-boot-optee-os-bump-version-to-3-7-0-tp237817p239519.html
>>
>> ?
>>
>>     Best regards,
>>
>>     Thomas
>>     -- 
>>     Thomas Petazzoni, CTO, Bootlin
>>     Embedded Linux and Kernel engineering
>>     https://bootlin.com
>>
>>
>> _______________________________________________
>> buildroot mailing list
>> buildroot at busybox.net
>> http://lists.busybox.net/mailman/listinfo/buildroot
>>
>