I need to customize the MACHINE apalis-imx8.conf creating my new one with some settings like changing the DT overlays and whatever.
With Yocto Project it is possible to override almost everything in a custom layer and therefore I expected to be able to do the same even in this case.
Unfortunately I am facing to problems when trying to override the variable TEZI_EXTERNAL_KERNEL_DEVICETREE_BOOT into my new machine configuration file.
This is an unexpected behavior, and therefore I am asking what is the Yocto MACHINE customization best practice suggested by Toradex?
Thank you
I would create my own machine, preferably starting the machine name with our machine name, include the original .conf and extend the MACHINE_OVERRIDES with the original machine name.
Then add whatever is needed to get the desired result.
E.g. have a look at what we did to have a machine suitable for a now obsolete silicon revision of the SoC [1].
However for TEZI_EXTERNAL_KERNEL_DEVICETREE_BOOT you do not need to do that. The overlay recipe is the only consumer of that variable. Since the content of the variable is machine specific we do set it in the machine configuration.
I would add a bbappend to the overlay recipe setting that variable to whatever you need, e.g. to not have any overlay applied by default I would create a file as follows:
Of all the overlays built we only deploy those which do NOT contain imx[6-8] or tk1 in their filename, plus we do deploy all overlays which start with the string given by the MACHINE_PREFIX variable. MACHINE_PREFIX is set to the machine name by default. [1].
So you would need to additionally set MACHINE_PREFIX_marco = "apalis-imx8" in your overlay bbappend to additionally deploy the overlays specific to your module type.
Hello @max.tx ,
I have the same problem when I am creating the meta-toolchain using a custom MACHINE.
In such case aarch64-linux-cpp is not built nor included in the sysroots.
Maybe do you need any other ‘magic’ setup?
What ‘same’ problem? I cannot relate any issue discussed in this topic with the build of meta-toolchain.
I’m not aware of anything special needed to build meta-toolchain.
Albeit I tend to recommend bitbake <image_name> -c populate_sdk over bitbake meta-toolchain to have additionally the developer packages of whatever I already packaged into the <image_name> recipe.
Hi @max.tx
‘same’ problem means ‘not working’.
Create a custom machine and use it in your local.conf (as stated above in this thread) and build bitbake meta-toolchain
or even bitbake <image_name> -c populate_sdk is the same.
The final result will be a toolchain/SDK that won’t contain the expected toolchain binaries like aarch64-linux-cpp.
Maybe I need any other ‘magic’ setup?
If it really is the same problem then the same solution should fix it, not?
Anyway, I created conf/machine/marco.conf
# keep the original machine as an override with high prio
MACHINEOVERRIDES =. "apalis-imx8:"
require conf/machine/apalis-imx8.conf
MACHINE_PREFIX_marco = "apalis-imx8"
Changed local.conf to have MACHINE = "marco"and did a bitbake meta-toolchain.
Then I installed the resulting sdk, sourced its environment and I have a toolchain. Albeit the toolchain is additionally decorated with the DISTRO name.
$ deploy/sdk/tdx-xwayland-glibc-x86_64-meta-toolchain-aarch64-marco-toolchain-5.5.0.sh
$ . /.../environment-setup-aarch64-tdx-linux
$ which aarch64-tdx-linux-cpp
.../sysroots/x86_64-tdxsdk-linux/usr/bin/aarch64-tdx-linux/aarch64-tdx-linux-cpp
$ aarch64-tdx-linux-cpp --version
aarch64-tdx-linux-cpp (GCC) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ cat << EOF > hello.c
#include <stdio.h>
int main(void) {printf("Hi\n");return 0;}
EOF
$ $CC hello.c -o hello
$ file hello
hello: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=aabaddf404cc497d9b9f06a77363796ff67b5888, for GNU/Linux 3.14.0, with debug_info, not stripped