OP-TEE / optee_os

Trusted side of the TEE
Other
1.59k stars 1.07k forks source link

OPTEE on Zybo Z7 10 #4833

Closed JensVankeirsbilck closed 3 years ago

JensVankeirsbilck commented 3 years ago

I'm trying to use OPTEE on my Zybo Z7 10 device, which is a zynq-7000 board. Since neither the Zybo nor the zynq7000 are a target of the optee build git, I have no choice but to clone the optee-os, optee-client and optee-text gits, build them myself and figure out how to get everything running.

1) Using the petalinux guide of Zybo, I'm able to have the device boot and run linux.

2) Using the command make PLATFORM=zynq7k CROSS_COMPILE="ccache arm-linux-gnueabihf-" ARCH=arm CFG_TEE_CORE_LOG_LEVEL=3 DEBUG=1 O=out/zynq7k I'm able to build optee-os, which results in several .bin files in out/zynq7k/core/

3) Just using make builds optee-client, which results in several folders in the out/ folder.

4) The command make CROSS_COMPILE="ccache arm-linux-gnueabihf-" ARCH=arm PLATFORM=zynq7k TA_DEV_KIT_DIR=$(OPTEE-OS)/out/zynq7k/export-ta_arm32 OPTEE_CLIENT_EXPORT=$(OPTEE-CLIENT)/out/export/usr DEBUG=1 builds optee-test, which results in several folders (one called xtest) in the out/ folder

Using the different parts, I tried to have OPTEE on my device. First, I transferred the tee-supplicant and the xtest binary to /usr/sbin of the rootfs partition of my SD card, so they are available in Linux. Next, based on this thread, I tried to boot everything:

  1. rebuilt optee-os, adding the build options CFG_DT_ADDR=0x02A00000 CFG_NS_ENTRY_ADDR=0x03000000
  2. used mkimage -A arm -O linux -C none -a 0x3E000000 -e 0x3E000000 -d tee.bin uTee to get the uTee file
  3. stopped the autoboot and executed the following commands: fatload mmc 0 0x03000000 zImage ; fatload mmc 0 0x02A00000 system.dtb ; fatload mmc 0:1 0x3E000000 uTee; setenv bootargs earlyprintk console=ttyPS0,115200 root=/dev/mmcblk0p2 rw rootwait ; bootm 0x3E000000 - 0x02A00000 ;

However, the bootm command does not execute but throws the error "Wrong Image format for bootm command". Now I'm stuck with the internet not providing any working solutions nor better explanation on how to either solve this issue or to get OPTEE running on this board. Any ideas on how to get OPTEE running on this zynq-7000 board?

PS: zImage and system.dtb are created during the petalinux build.

yanyan-wrs commented 3 years ago

It appears you're using bootm the wrong way. bootm reads the mkimage payload from the address of the 1st parameter, and it parses the header of the mkimage payload to get the load address. The payload address and load address are supposed to be away to avoid overwriting each other. The possible cause of the problem you observed is that bootm copies the content back to 0x3E00000 and overwrites the image header, so that when bootm looked for the image type in the header it can't tell the correct type. Disclaimer: I haven't read uboot code so it's my guess.

So what you should try is:

  1. read the payload to a low address (not overwriting your Linux and DTB image of course): fatload mmc 0:1 0x38000000;
  2. issue bootm like this: bootm 0x38000000 - 0x02a00000;
JensVankeirsbilck commented 3 years ago

Thanks for your reply, but I keep getting that error message. This makes me think my mkimage command is wrong, since it creates the uTee file...

Or... could the problem be caused by the fact that I'm using the BOOT.bin file generated by the petalinux project to do the initial booting?

yanyan-wrs commented 3 years ago

Thanks for your reply, but I keep getting that error message. This makes me think my mkimage command is wrong, since it creates the uTee file...

Or... could the problem be caused by the fact that I'm using the BOOT.bin file generated by the petalinux project to do the initial booting?

No I don't think mkimage or BOOT.bin generated by petalinux did anything wrong. uTee is faking itself as Linux payload so that u-boot will just handle control and pass arguments the way as it does for Linux. Every u-boot with bootm shall behave the same way. Can you dump the first dozens of bytes of the uTee image to make sure it has correct header, i.e., uImage's header.

yanyan-wrs commented 3 years ago

For the purpose of testing, you can switch to use go command of u-boot, but as 'go' doesn't accept entry arguments, you may have to hardcode the DTS address in OPTEE. the DTS address was passed in register X2 in the case of 'bootm'. Try this and see if it works.

JensVankeirsbilck commented 3 years ago

Can you dump the first dozens of bytes of the uTee image to make sure it has correct header, i.e., uImage's header.

No real idea what you meant with this, I hope you meant the output of mkimage -l, which is what I put beneath: mkimage -l uTee of my latest build-try shows the following:

Image Name:   Linux kernel
Created:      Mon Sep 27 11:18:30 2021
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    583004 Bytes = 569.34 KiB = 0.56 MiB
Load Address: 00008000
Entry Point:  00008000

mkimage -l image.ub, which is the image created by petalinux shows the following:

FIT description: U-Boot fitImage for plnx_arm kernel
Created:         Fri Sep  3 16:30:50 2021
 Image 0 (kernel@0)
  Description:  Linux Kernel
  Created:      Fri Sep  3 16:30:50 2021
  Type:         Kernel Image
  Compression:  uncompressed
  Data Size:    3813016 Bytes = 3723.65 KiB = 3.64 MiB
  Architecture: ARM
  OS:           Linux
  Load Address: 0x00008000
  Entry Point:  0x00008000
  Hash algo:    sha1
  Hash value:   43971091efb150dfd203dcd07b151a2012d83060
 Image 1 (fdt@0)
  Description:  Flattened Device Tree blob
  Created:      Fri Sep  3 16:30:50 2021
  Type:         Flat Device Tree
  Compression:  uncompressed
  Data Size:    26867 Bytes = 26.24 KiB = 0.03 MiB
  Architecture: ARM
  Hash algo:    sha1
  Hash value:   0bbcfaf944f0fbf4dadd7fd8bd389f613e16b618
 Default Configuration: 'conf@2'
 Configuration 0 (conf@2)
  Description:  Boot Linux kernel with FDT blob
  Kernel:       kernel@0
  FDT:          fdt@0
  Hash algo:    sha1
  Hash value:   unavailable

I see that image.ub contains the device tree blob inside, but the output from uTee and the output in kernel@0 of image.ub seem to be similar?

For the purpose of testing, you can switch to use go command of u-boot

I've played around with the go command already, but to no avail. However, since I tried many things and not always so structured, I'll try everything once more, but in a more structured way. I'll keep you posted of the outcome.

yanyan-wrs commented 3 years ago

The second dump shows it's FIT image. From the MAN page of mkimage it appears this tool can also produce image with FIT format. I have no such experience but is it possible that u-boot on your particular hardware only supports FIT payload instead of the legacy one? One way to verify is try to mkimage a working Linux payload using the legacy format and boot it. If it turned out the u-boot doesn't support legacy format, you can just repack the uTee using FIT.

JensVankeirsbilck commented 3 years ago

If it turned out the u-boot doesn't support legacy format

That was indeed the issue. So now I just disabled the option to support FIT images in the u-boot config of the petaLinux project, so now it does no longer give that error when using the bootm command. Now it reads the uTee file and tries to launch it. This launching is not successful yet, or at least I do not see any output, but at least this is bootm-problem fixed now.

Now, I'll have to figure out why uTee is not running...

github-actions[bot] commented 3 years ago

This issue has been marked as a stale issue because it has been open (more than) 30 days with no activity. Remove the stale label or add a comment, otherwise this issue will automatically be closed in 5 days. Note, that you can always re-open a closed issue at any time.