tf-a-tools: fix building the native target by quaresmajose · Pull Request #41 · STMicroelectronics/meta-st-stm32mp

quaresmajose · 2022-08-23T21:49:05Z

No description provided.

BernardPuel · 2022-08-24T07:41:04Z

Thanks for your contribution Jose.
I will enter an internal ticket for ST internal review.

quaresmajose · 2022-08-24T08:32:48Z

Thanks for your contribution Jose. I will enter an internal ticket for ST internal review.

Thanks, It is a pleasure to be able to contribute to your project

quaresmajose · 2022-08-24T08:34:05Z

Please old on a bit as I need to confirm an issue that I see in our CI

| fiptool: error while loading shared libraries: libcrypto.so.3: cannot open shared object file: No such file or directory

So my affirmation - RDEPENDS and FILES is not needed can be wrong.

quaresmajose · 2022-08-24T14:13:02Z

Please old on a bit as I need to confirm an issue that I see in our CI
| fiptool: error while loading shared libraries: libcrypto.so.3: cannot open shared object file: No such file or directory
So my affirmation - RDEPENDS and FILES is not needed can be wrong.

the patch tf-a-tools: fix the RPATH for the native target fixes the issue so it is ready to review.

BernardPuel · 2022-08-24T14:33:39Z

Hi Jose, I discussed with dev team and ST policy is to stick with tf-a 2.6 (as a whole) and not upgrading some parts of tf-a and not others (like here for tf-a tools).

Could you please elaborate a bit why do you want to upgrade tf-a tools to 2.7 version (what is your motivation) ?

quaresmajose · 2022-08-24T15:22:32Z

I am fine in not upgrading the tf-a tools to 2.7 for now and only fix the native target so I will drop the update patch

ricardosalveti · 2022-08-24T17:45:57Z

We're using upstream 2.7 (instead of the 2.6 from ST BSP), but I guess it is easier for us to do the bump at our own layer instead.

OpenSTLinux · 2022-08-25T07:44:05Z

ok Clear Ricardo.

cpriouzeau · 2022-08-26T08:10:10Z

The fix are merged on top of kirkstone branche

jviguera · 2022-09-01T14:39:00Z

@quaresmajose @BernardPuel

The current 2.6 version in Kirkstone fails to build when creating a toolchain/SDK.

$ bitbake nativesdk-tf-a-tools

First, there are a bunch of warnings converted to errors because of '-Werror':

| gcc -c -DVERSION='"v2.6(release):v2.6-dirty"' -D_GNU_SOURCE -D_XOPEN_SOURCE=700 -Wall -Werror -pedantic -std=c99 -O2 -I../../include/tools_share -I/ssd/dey/kirkstone/ccmp15-dvk/tmp/work/x86_64-nativesdk-deysdk-linux/nativesdk-tf-a-tools/2.6-r0/recipe-sysroot/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-deysdk-linux/usr/include -isystem/ssd/dey/kirkstone/ccmp15-dvk/tmp/work/x86_64-nativesdk-deysdk-linux/nativesdk-tf-a-tools/2.6-r0/recipe-sysroot-native/usr/include -O2 -pipe fiptool.c -o fiptool.o
| In file included from /ssd/dey/kirkstone/ccmp15-dvk/tmp/work/x86_64-nativesdk-deysdk-linux/nativesdk-tf-a-tools/2.6-r0/recipe-sysroot/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-deysdk-linux/usr/include/linux/posix_types.h:5:0,
| from /ssd/dey/kirkstone/ccmp15-dvk/tmp/work/x86_64-nativesdk-deysdk-linux/nativesdk-tf-a-tools/2.6-r0/recipe-sysroot/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-deysdk-linux/usr/include/linux/types.h:9,
| from /ssd/dey/kirkstone/ccmp15-dvk/tmp/work/x86_64-nativesdk-deysdk-linux/nativesdk-tf-a-tools/2.6-r0/recipe-sysroot/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-deysdk-linux/usr/include/linux/stat.h:5,
| from /ssd/dey/kirkstone/ccmp15-dvk/tmp/work/x86_64-nativesdk-deysdk-linux/nativesdk-tf-a-tools/2.6-r0/recipe-sysroot/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-deysdk-linux/usr/include/bits/statx.h:31,
| from /ssd/dey/kirkstone/ccmp15-dvk/tmp/work/x86_64-nativesdk-deysdk-linux/nativesdk-tf-a-tools/2.6-r0/recipe-sysroot/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-deysdk-linux/usr/include/sys/stat.h:465,
| from fiptool.c:8:
| /ssd/dey/kirkstone/ccmp15-dvk/tmp/work/x86_64-nativesdk-deysdk-linux/nativesdk-tf-a-tools/2.6-r0/recipe-sysroot/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-deysdk-linux/usr/include/linux/stddef.h:23:49: error: ISO C does not permit named variadic macros [-Werror=variadic-macros]
| #define __struct_group(TAG, NAME, ATTRS, MEMBERS...)
| ^~~
| In file included from fiptool.c:12:0:
| /ssd/dey/kirkstone/ccmp15-dvk/tmp/work/x86_64-nativesdk-deysdk-linux/nativesdk-tf-a-tools/2.6-r0/recipe-sysroot/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-deysdk-linux/usr/include/limits.h:124:3: error: #include_next is a GCC extension [-Werror]
| # include_next <limits.h>
| ^~~~~~~~~~~~
| In file included from fiptool.c:16:0:
| /ssd/dey/kirkstone/ccmp15-dvk/tmp/work/x86_64-nativesdk-deysdk-linux/nativesdk-tf-a-tools/2.6-r0/recipe-sysroot/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-deysdk-linux/usr/include/stdlib.h:141:8: error: ISO C does not support the ‘_Float32’ type [-Werror=pedantic]
| extern _Float32 strtof32 (const char *__restrict __nptr,

Then it also fails at link time:

gcc src/build_msg.o src/cert.o src/cmd_opt.o src/ext.o src/key.o src/main.o src/sha.o src/tbbr/tbb_cert.o src/tbbr/tbb_ext.o src/tbbr/tbb_key.o -L /ssd/dey/kirkstone/ccmp15-dvk/tmp/work/x86_64-nativesdk-deysdk-linux/nativesdk-tf-a-tools/2.6-r0/recipe-sysroot/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-deysdk-linux/usr/lib -lssl -lcrypto -o cert_create
hosttools/ld: warning: /ssd/dey/kirkstone/ccmp15-dvk/tmp/work/x86_64-nativesdk-deysdk-linux/nativesdk-tf-a-tools/2.6-r0/recipe-sysroot/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-deysdk-linux/usr/lib/libssl.so: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001
hosttools/ld: warning: /ssd/dey/kirkstone/ccmp15-dvk/tmp/work/x86_64-nativesdk-deysdk-linux/nativesdk-tf-a-tools/2.6-r0/recipe-sysroot/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-deysdk-linux/usr/lib/libssl.so: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002
hosttools/ld: warning: /ssd/dey/kirkstone/ccmp15-dvk/tmp/work/x86_64-nativesdk-deysdk-linux/nativesdk-tf-a-tools/2.6-r0/recipe-sysroot/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-deysdk-linux/usr/lib/libcrypto.so: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001
hosttools/ld: warning: /ssd/dey/kirkstone/ccmp15-dvk/tmp/work/x86_64-nativesdk-deysdk-linux/nativesdk-tf-a-tools/2.6-r0/recipe-sysroot/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-deysdk-linux/usr/lib/libcrypto.so: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002
hosttools/ld: cannot find /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-deysdk-linux/lib/libc.so.6
hosttools/ld: cannot find /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-deysdk-linux/usr/lib/libc_nonshared.a
hosttools/ld: cannot find /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-deysdk-linux/lib/ld-linux-x86-64.so.2

I guess all this is because Kirkstone does only support OpenSSL 3.0.x, while the tf-a-tools version 2.6 seems to expect OpenSSL 1.x.

Is there a fix for bitbake nativesdk-tf-a-tools?
or,
do you reconsider upgrading to a newer version in Kirkstone branch (seems that 2.7 supports Openssl 3)?

Thanks.

quaresmajose · 2022-09-02T08:16:55Z

@jviguera have you tried build the nativesdk-tf-a-tools before this PR? I will take a look to see if this PR introduce some issues on nativesdk target

I guess all this is because Kirkstone does only support OpenSSL 3.0.x, while the tf-a-tools version 2.6 seems to expect OpenSSL 1.x.

if your suspicion is correct it was already broken before.

cpriouzeau · 2022-09-02T09:00:54Z

@quaresmajose and @jviguera , I just pushed a pach to correct the compilation with openssl3.

I have test with yocto build for native and native-sdk.

quaresmajose · 2022-09-02T09:45:21Z

@cpriouzeau but with the pushed patch the native target is broked again 766634e#diff-8b1d74ca8a6425a18839337d0994329c2a7b4f093434a07238f198df3641a3baL23-L30 as this is needed for the native target as you can see in 96bffa5

96bffa5 doesn't fix any build issue but instead it fixes a runtime issues. this happens because the native fip-tool is trying to use the default libraries of the host machine instead of the lib on the bitbake native rootfs.

So as an example if we build this fip-tool on a host with libcrypto.so.1.1 when at runtime the tool will fail because it will try to find the libcrypto.so.3 (provided by bitbake during build) on the rootfs of host machine the instead of the native rootfs provided by bitbake

libcrypto.so provided on the build machine:

builder@942b524bf70d:/$ ls /lib/x86_64-linux-gnu/libcrypto.so* -l
lrwxrwxrwx 1 root root      16 Mar  9 12:12 /lib/x86_64-linux-gnu/libcrypto.so -> libcrypto.so.1.1
-rw-r--r-- 1 root root 2954080 Mar  9 12:12 /lib/x86_64-linux-gnu/libcrypto.so.1.1

quaresmajose · 2022-09-02T09:48:05Z

@cpriouzeau are you sure this recipe works on the target?

COMPATIBLE_HOST:class-target = "null"

766634e#diff-8b1d74ca8a6425a18839337d0994329c2a7b4f093434a07238f198df3641a3baL14

quaresmajose · 2022-09-02T10:42:32Z

this patch does the job for me and don't break the native fiptool, don't haven know if the nativesdk fiptool runs fine but already builds

iff --git a/recipes-bsp/trusted-firmware-a/tf-a-tools_2.6.bb b/recipes-bsp/trusted-firmware-a/tf-a-tools_2.6.bb
index b1137f0..3bbad6c 100644
--- a/recipes-bsp/trusted-firmware-a/tf-a-tools_2.6.bb
+++ b/recipes-bsp/trusted-firmware-a/tf-a-tools_2.6.bb
@@ -15,12 +15,13 @@ COMPATIBLE_HOST:class-target = "null"
 
 S = "${WORKDIR}/git"
 
-EXTRA_OEMAKE += "V=1 HOSTCC='${BUILD_CC}' OPENSSL_DIR='${STAGING_EXECPREFIXDIR}'"
-EXTRA_OEMAKE += "certtool fiptool"
+HOSTCC:class-native = "${BUILD_CC}"
+HOSTCC:class-nativesdk = "${CC}"
+EXTRA_OEMAKE = "V=1 HOSTCC='${HOSTCC}' OPENSSL_DIR='${STAGING_EXECPREFIXDIR}' certtool fiptool"
 
 do_configure[noexec] = "1"
 
-do_compile:prepend () {
+do_compile:prepend:class-native () {
     # This is still needed to have the native fiptool executing properly by
     # setting the RPATH
     sed -e '/^LDLIBS/ s,$, \$\{BUILD_LDFLAGS},' \

- The addiction of the HOSTCC breaks the nativesdk target build - The RPATH only needs to be fixed for the native target regression introduced in: STMicroelectronics#41 Signed-off-by: Jose Quaresma <[email protected]>

quaresmajose marked this pull request as draft August 24, 2022 08:46

quaresmajose force-pushed the kirkstone branch from 09c28db to 90673b3 Compare August 24, 2022 14:11

quaresmajose marked this pull request as ready for review August 24, 2022 14:11

quaresmajose force-pushed the kirkstone branch from 90673b3 to 6c5464b Compare August 24, 2022 15:26

quaresmajose changed the title ~~tf-a-tools: fix build and update to 2.7~~ tf-a-tools: fix building the native target Aug 24, 2022

quaresmajose closed this Aug 26, 2022

quaresmajose force-pushed the kirkstone branch from 6c5464b to 96bffa5 Compare August 26, 2022 09:58

quaresmajose mentioned this pull request Aug 26, 2022

tf-a-tools: 2.6 -> 2.7 #42

Closed

Conversation

quaresmajose commented Aug 23, 2022

Uh oh!

BernardPuel commented Aug 24, 2022

Uh oh!

quaresmajose commented Aug 24, 2022

Uh oh!

quaresmajose commented Aug 24, 2022

Uh oh!

quaresmajose commented Aug 24, 2022

Uh oh!

BernardPuel commented Aug 24, 2022

Uh oh!

quaresmajose commented Aug 24, 2022

Uh oh!

ricardosalveti commented Aug 24, 2022

Uh oh!

OpenSTLinux commented Aug 25, 2022

Uh oh!

cpriouzeau commented Aug 26, 2022

Uh oh!

jviguera commented Sep 1, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

quaresmajose commented Sep 2, 2022

Uh oh!

cpriouzeau commented Sep 2, 2022

Uh oh!

quaresmajose commented Sep 2, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

quaresmajose commented Sep 2, 2022

Uh oh!

quaresmajose commented Sep 2, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

jviguera commented Sep 1, 2022 •

edited

Loading

quaresmajose commented Sep 2, 2022 •

edited

Loading