Hello
I wonder why Optee OS would use a linux target toolchains but not a bare metal target(none os)?
gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-gcc -dM -E - < /dev/null|grep linux #define __linux 1 #define __gnu_linux__ 1 #define linux 1 #define __linux__ 1
That makes hard to share a header files between Linux kernel and Optee. We like to pass some structure in SHM, but optee don't have all those Linux types likes <linux/types.h>.
If optee didn't choose the toolchains for the Linux, we could easily decide which part would use for Client Agent(Linux kernel) side or TEE OS side.
Why we don't use bare metal toolchains ?
Thank you
Randy Li
Hi Randy,
On Mon, Dec 4, 2023 at 2:39 PM Randy Li ayaka@soulik.info wrote:
Hello
I wonder why Optee OS would use a linux target toolchains but not a bare metal target(none os)?
I guess it started with that we didn't want to download both one Linux and one bare metal toolchain. We need both AArch32 and AArch64 versions so it doubles up.
gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-gcc -dM -E - < /dev/null|grep linux #define __linux 1 #define __gnu_linux__ 1 #define linux 1 #define __linux__ 1
That makes hard to share a header files between Linux kernel and Optee. We like to pass some structure in SHM, but optee don't have all those Linux types likes <linux/types.h>.
Surely you can define a .h file in a way that you can include it in both environments. We try to stick to ISO C.
If optee didn't choose the toolchains for the Linux, we could easily decide which part would use for Client Agent(Linux kernel) side or TEE OS side.
Why we don't use bare metal toolchains ?
Feel free to do so.
Cheers, Jens
On 12/4/23 17:34, Jens Wiklander wrote:
Hi Randy,
On Mon, Dec 4, 2023 at 2:39 PM Randy Li ayaka@soulik.info wrote:
Hello
I wonder why Optee OS would use a linux target toolchains but not a bare metal target(none os)?
I guess it started with that we didn't want to download both one Linux and one bare metal toolchain. We need both AArch32 and AArch64 versions so it doubles up.
To expand on this: when building a complete OP-TEE setup like we do with https://github.com/OP-TEE/manifest, there are many different runtime environments: the Linux kernel, client applications, OP-TEE OS, Trusted Applications, EL3 firmware... Some of them require a Linux toolchain (the OP-TEE client library, tee-supplicant as well as the client applications). So the idea was, if we could build all the software with a Linux toolchain, it would simplify things. Since then we found out there are caveats but it mostly works.
On 2023/12/5 00:34, Jens Wiklander wrote:
Hi Randy,
On Mon, Dec 4, 2023 at 2:39 PM Randy Li ayaka@soulik.info wrote:
Hello
I wonder why Optee OS would use a linux target toolchains but not a bare metal target(none os)?
I guess it started with that we didn't want to download both one Linux and one bare metal toolchain. We need both AArch32 and AArch64 versions so it doubles up.
gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-gcc -dM -E - < /dev/null|grep linux #define __linux 1 #define __gnu_linux__ 1 #define linux 1 #define __linux__ 1
That makes hard to share a header files between Linux kernel and Optee. We like to pass some structure in SHM, but optee don't have all those Linux types likes <linux/types.h>.
Surely you can define a .h file in a way that you can include it in both environments. We try to stick to ISO C.
Sometimes, we just need the macro functions like defined in <helper/bits.h> or <helper/align.h>
But in the Linux kernel environment, we don't have such header file.
Are there any safe environment macro that we could use to distinguish between Linux kernel and Optee TEE part(both OS and TA) ?
If optee didn't choose the toolchains for the Linux, we could easily decide which part would use for Client Agent(Linux kernel) side or TEE OS side.
Why we don't use bare metal toolchains ?
Feel free to do so.
Cheers, Jens
op-tee@lists.trustedfirmware.org
-
Jens Wiklander -
Jerome Forissier -
Randy Li