Closed JensVankeirsbilck closed 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:
fatload mmc 0:1 0x38000000;
bootm 0x38000000 - 0x02a00000;
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?
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.
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.
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.
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.
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...
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.
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:
CFG_DT_ADDR=0x02A00000 CFG_NS_ENTRY_ADDR=0x03000000
mkimage -A arm -O linux -C none -a 0x3E000000 -e 0x3E000000 -d tee.bin uTee
to get the uTee filefatload 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.