search

OP-TEE / build

Makefiles to use OP-TEE on various platforms
107 stars 213 forks source link

rockpi4 build issues #769

Open msgilligan opened 1 month ago

msgilligan commented 1 month ago

Building with the latest master (on Debian 12 ARM64), Using the standard build instructions, I get the following:

$ make RUST_ENABLE=n flash
make -C plat/rockchip/rk3399/drivers/m0 BUILD=/home/sean/ValidiTEE/optee-rock4/trusted-firmware-a/build/rk3399/release/m0

When I try using the boot-img target, I get:

$ make RUST_ENABLE=n boot-img
make -C /home/sean/ValidiTEE/optee-rock4/build/../optee_os O=out/arm CFG_USER_TA_TARGETS=ta_arm64 CFG_ARM64_core=y PLATFORM=rockchip-rk3399 CROSS_COMPILE="/usr/bin/ccache /home/sean/ValidiTEE/optee-rock4/build/../toolchains/aarch64/bin/aarch64-linux-" CROSS_COMPILE_core="/usr/bin/ccache /home/sean/ValidiTEE/optee-rock4/build/../toolchains/aarch64/bin/aarch64-linux-" CROSS_COMPILE_ta_arm64="/usr/bin/ccache /home/sean/ValidiTEE/optee-rock4/build/../toolchains/aarch64/bin/aarch64-linux-" CROSS_COMPILE_ta_arm32="/usr/bin/ccache /home/sean/ValidiTEE/optee-rock4/build/../toolchains/aarch32/bin/arm-linux-gnueabihf-" CFG_TEE_CORE_LOG_LEVEL=3 DEBUG=0 CFG_IN_TREE_EARLY_TAS="trusted_keys/f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c" CFG_ENABLE_EMBEDDED_TESTS=y
make[1]: Entering directory '/home/sean/ValidiTEE/optee-rock4/optee_os'
mk/config.mk:1025: Warning: Disabling CFG_NOTIF_TEST_WD [requires CFG_CALLOUT CFG_CORE_ASYNC_NOTIF]
  CHK     out/arm/conf.mk
  CHK     out/arm/include/generated/conf.h
  GEN     out/arm/ta/trusted_keys/dyn_list
  CHK     out/arm/conf.cmake
  CHK     out/arm/export-ta_arm64/mk/conf.mk
  GEN     out/arm/ta/avb/dyn_list
  GEN     out/arm/ta/pkcs11/dyn_list
  GEN     out/arm/ta/remoteproc/dyn_list
  CHK     pkcs11-ta-verify-helpers
make[1]: Leaving directory '/home/sean/ValidiTEE/optee-rock4/optee_os'
CROSS_COMPILE="/usr/bin/ccache /home/sean/ValidiTEE/optee-rock4/build/../toolchains/aarch64/bin/aarch64-linux-" M0_CROSS_COMPILE="/usr/bin/ccache /home/sean/ValidiTEE/optee-rock4/build/../toolchains/aarch32/bin/arm-linux-gnueabihf-" make -C /home/sean/ValidiTEE/optee-rock4/build/../trusted-firmware-a ARCH=aarch64 PLAT=rk3399 SPD=opteed DEBUG=0 LOG_LEVEL=30 bl31
make[1]: Entering directory '/home/sean/ValidiTEE/optee-rock4/trusted-firmware-a'
Including services/spd/opteed/opteed.mk
make -C plat/rockchip/rk3399/drivers/m0 BUILD=/home/sean/ValidiTEE/optee-rock4/trusted-firmware-a/build/rk3399/release/m0
make[2]: Entering directory '/home/sean/ValidiTEE/optee-rock4/trusted-firmware-a/plat/rockchip/rk3399/drivers/m0'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/home/sean/ValidiTEE/optee-rock4/trusted-firmware-a/plat/rockchip/rk3399/drivers/m0'
  LD      /home/sean/ValidiTEE/optee-rock4/trusted-firmware-a/build/rk3399/release/bl31/bl31.elf
/home/sean/ValidiTEE/optee-rock4/build/../toolchains/aarch64/bin/aarch64-linux-ld.bfd: warning: /home/sean/ValidiTEE/optee-rock4/trusted-firmware-a/build/rk3399/release/bl31/bl31.elf has a LOAD segment with RWX permissions
/home/sean/ValidiTEE/optee-rock4/build/../toolchains/aarch64/bin/aarch64-linux-ld.bfd: warning: /home/sean/ValidiTEE/optee-rock4/trusted-firmware-a/build/rk3399/release/bl31/bl31.elf has a LOAD segment with RWX permissions
/home/sean/ValidiTEE/optee-rock4/build/../toolchains/aarch64/bin/aarch64-linux-ld.bfd: warning: /home/sean/ValidiTEE/optee-rock4/trusted-firmware-a/build/rk3399/release/bl31/bl31.elf has a LOAD segment with RWX permissions
make[1]: *** [Makefile:1306: /home/sean/ValidiTEE/optee-rock4/trusted-firmware-a/build/rk3399/release/bl31/bl31.elf] Error 1
make[1]: Leaving directory '/home/sean/ValidiTEE/optee-rock4/trusted-firmware-a'
make: *** [Makefile:79: tfa] Error 2

I will try on an Intel box shortly and see if that makes a difference.

Note that I made a PR with some documentation improvements for rockpi4: https://github.com/OP-TEE/optee_docs/pull/242

msgilligan commented 1 month ago

I tried with the 4.2.0 tag and got the same error(s).

jenswi-linaro commented 1 month ago

I can confirm the same build error on Ubuntu 22.04.4 ARM64.

jenswi-linaro commented 1 month ago

Upgrading TF-A to v2.10 fixes the build error. I haven't tried booting it though.

msgilligan commented 1 month ago

I'm going to give it a try today. I'm trying to figure out how to configure repo to do this. Should we make a PR to the manifest repo?

msgilligan commented 1 month ago

I made a PR: https://github.com/OP-TEE/manifest/pull/287

msgilligan commented 1 month ago

Upgrading TF-A to v2.10 fixes the build error.

Were you able to run with the flashtarget, or did you use the boot-img target?

Am I missing something here. Should we update the documentation?

(Update: The behavior I am seeing is that the flash target requires the boot-img target but without specifying it as make dependency.)

msgilligan commented 1 month ago

I copied the rockpi4.img built to an SD Card and it boots and successfully runs xtest.

(Since I'm using a VM I'm not so sure I want to try to to use USB pass thru to write to eMMC)

msgilligan commented 1 month ago

https://github.com/OP-TEE/manifest/pull/287 is ready-for-review.

jenswi-linaro commented 1 month ago

Upgrading TF-A to v2.10 fixes the build error.

Were you able to run with the flashtarget, or did you use the boot-img target?

Am I missing something here. Should we update the documentation?

(Update: The behavior I am seeing is that the flash target requires the boot-img target but without specifying it as make dependency.)

I always do a make all first, step 5 [1] says make -j nproc which is equivalent. We don't want flash to depend on the all target since it's a bit much to do each time you're flashing.

However, if you see a good place to make it clearer when building for rockpi4 feel free to propose something.

[1] https://optee.readthedocs.io/en/latest/building/gits/build.html#step-5-build-the-solution

msgilligan commented 1 month ago

I always do a make all first, step 5 [1] says make -j nproc which is equivalent. We don't want flash to depend on the all target since it's a bit much to do each time you're flashing.

OK, that makes sense.

But developers (like me) might assume that to just do the flash they can just use the flash target. And in the case of incremental builds they may not want to run the all target.

However, if you see a good place to make it clearer when building for rockpi4 feel free to propose something.

I have not studied the Makefile, but I can think of two approaches:

  1. Have the flash target depend on boot-img (this may not be much different from all, I suppose)
  2. Add a note to the build instructions explaining how things work and how to do incremental builds.

As I learn more about the build, I might come up with a better idea, but it seems we should at least do #2 for now.

msgilligan commented 1 month ago

BTW, I have two Rock 4 family boards for testing:

And have now successfully booted and run xtest on both of them.

msgilligan commented 1 month ago

@jenswi-linaro I'm also wondering if we should have used the lts-v2.10.5 tag since that's the latest (LTS) release?

jenswi-linaro commented 1 month ago

@jenswi-linaro I'm also wondering if we should have used the lts-v2.10.5 tag since that's the latest (LTS) release?

I'd rather upgrade to the latest TF-A release. That's what we usually do when upgrading. I suggested v2.10 because I knew it was used in other configurations and wanted to minimize the risk of problems just before the release.

jenswi-linaro commented 1 month ago

But developers (like me) might assume that to just do the flash they can just use the flash target. And in the case of incremental builds they may not want to run the all target.

Other developers (like me) might assume that flash only does the flashing and nothing else. Right now we get a bit of both. Perhaps we should let flash depend on all and add a flash-only target depending on nothing.

msgilligan commented 4 weeks ago

Perhaps we should let flash depend on all and add a flash-only target depending on nothing.

That sounds like a good idea! Making that change and documenting it would do the trick. Would we need to change any of the makefiles for the other boards?

jenswi-linaro commented 3 weeks ago

Would we need to change any of the makefiles for the other boards?

Yes. Before starting this I'd like to hear what others think. @jforissier @jbech-linaro @etienne-lms ?

jforissier commented 3 weeks ago

Would we need to change any of the makefiles for the other boards?

Yes. Before starting this I'd like to hear what others think. @jforissier @jbech-linaro @etienne-lms ?

Sounds good to me.