[v4,6/7] configs/qemu_armv7a_tz_virt: Armv7-A emulation with TrustZone services

Message ID 1548845249-28201-6-git-send-email-etienne.carriere@linaro.org
State Superseded
Headers show
Series
  • [v4,1/7] boot/optee-os: new package
Related show

Commit Message

Etienne Carriere Jan. 30, 2019, 10:47 a.m.
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

Comments

Thomas Petazzoni Feb. 17, 2019, 10:12 p.m. | #1
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
Yann E. MORIN Feb. 18, 2019, 6:14 p.m. | #2
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
Etienne Carriere Feb. 18, 2019, 9:28 p.m. | #3
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.  |
> '------------------------------^-------^------------------^--------------------'
Thomas Petazzoni Feb. 18, 2019, 9:43 p.m. | #4
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
Arnout Vandecappelle (Essensium/Mind) Feb. 19, 2019, 8:31 a.m. | #5
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
>
Etienne Carriere March 5, 2019, 9:14 a.m. | #6
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
> >
Thomas Petazzoni March 5, 2019, 9:55 a.m. | #7
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
Etienne Carriere March 5, 2019, 10:58 a.m. | #8
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

Patch

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