Problem generating iMX SDK in Yocto release 4.9.11-1.0.0, imx-morty

[dry]

I'm using the imx-morty Yocto as released, and I built image build-fb-machine-test, no problem.

I also then built SDK installer , and tested it, installed it. It installed with no errors and no problems, no warnings.

After this I did a few very minor modifications to the default setup - like add extra apps and a dev library- and rebuilt image and sdk. Image seems fine.

But now I got some problem with the generated SDK installer.  And I tried to force re-generating it few times with no luck.

It seems like its' not generated correctly and missing files.  When I start installing it, I get message:

Extracting SDK...............................................................................................done
Setting it up...ls: cannot access '/opt/fsl-imx-fb/4.9.11-1.0.0/environment-setup-*': No such file or directory

At this step the installer / extractor hangs, and does not proceed further. I have to Cntr-C / kill it. It seems that the installed files are not complete, relative to first proper install it seems ~500Mb is missing. I guess after that error trace above things don't carry on.

Looking at first proper install vs hanged:

good install:

rw-r--r--. 1 root root 3458 Dec 15 18:00 environment-setup-cortexa7hf-neon-poky-linux-gnueabi
-rw-r--r--. 1 root root 54841 Dec 15 18:00 site-config-cortexa7hf-neon-poky-linux-gnueabi
drwxr-xr-x. 4 root root 4096 Dec 15 17:40 sysroots
-rw-r--r--. 1 root root 134 Dec 15 18:00 version-cortexa7hf-neon-poky-linux-gnueabi

bad install:

-rwxrwxr-x. 1 root root 9080 Feb 15 00:17 relocate_sdk.py
drwxr-xr-x. 4 root root 4096 Dec 15 17:40 sysroots

So those environment files definitely not there.

If I search for them in the build setup, I see they are seems all there:

/fsl-release-bsp/build-fb-machine-test/tmp/work/x86_64-nativesdk-pokysdk-linux/meta-environment-imx7dsabresd/1.0-r8/sdk/image/opt/fsl-imx-fb/4.9.11-1.0.0/environment-setup-cortexa7hf-neon-poky-linux-gnueabi
/fsl-release-bsp/build-fb-machine-test/tmp/work/x86_64-nativesdk-pokysdk-linux/meta-environment-imx7dsabresd/1.0-r8/packages-split/meta-environment-imx7dsabresd/opt/fsl-imx-fb/4.9.11-1.0.0/environment-setup-cortexa7hf-neon-poky-linux-gnueabi

/fsl-release-bsp/build-fb-machine-test/tmp/work/x86_64-nativesdk-pokysdk-linux/meta-environment-imx7dsabresd/1.0-r8/package/opt/fsl-imx-fb/4.9.11-1.0.0/environment-setup-cortexa7hf-neon-poky-linux-gnueabi
/fsl-release-bsp/build-fb-machine-test/tmp/work/x86_64-nativesdk-pokysdk-linux/meta-environment-imx7dsabresd/1.0-r8/image/opt/fsl-imx-fb/4.9.11-1.0.0/environment-setup-cortexa7hf-neon-poky-linux-gnueabi
/fsl-release-bsp/build-fb-machine-test/tmp/work/x86_64-nativesdk-pokysdk-linux/meta-environment-extsdk-imx7dsabresd/1.0-r8/sdk/image/opt/fsl-imx-fb/4.9.11-1.0.0/environment-setup-cortexa7hf-neon-poky-linux-gnueabi
/fsl-release-bsp/build-fb-machine-test/tmp/work/x86_64-nativesdk-pokysdk-linux/meta-environment-extsdk-imx7dsabresd/1.0-r8/packages-split/meta-environment-extsdk-imx7dsabresd/opt/fsl-imx-fb/4.9.11-1.0.0/environment-setup-cortexa7hf-neon-poky-linux-gnueabi
/fsl-release-bsp/build-fb-machine-test/tmp/work/x86_64-nativesdk-pokysdk-linux/meta-environment-extsdk-imx7dsabresd/1.0-r8/package/opt/fsl-imx-fb/4.9.11-1.0.0/environment-setup-cortexa7hf-neon-poky-linux-gnueabi
/fsl-release-bsp/build-fb-machine-test/tmp/work/x86_64-nativesdk-pokysdk-linux/meta-environment-extsdk-imx7dsabresd/1.0-r8/image/opt/fsl-imx-fb/4.9.11-1.0.0/environment-setup-cortexa7hf-neon-poky-linux-gnueabi

I have no clue why they don't make it into the SDK installer, and why things go bad ...

Anyone could help?

Thanks

[dry · Accepted solution]

I finally found that it was my bug in a variable i used to extend SDK contents, in local.conf  (duh !  )

I didn't create any customized layers, happy with it as is for now.

[gusarambula]

Hello D. RY,

Have you tried cleaning and baking the SDK with your changes? Please do a cleanall for the SDK recipe. I would recommend first trying that to see if the installer is generated correctly this time (as the other files are available but perhaps from the baking before you made the changes)

Let us know the outcome of this.

Regards,

[dry]

Hey ,

This must be a dumb question but how do you actually do it?

I generate SDK, i do

bitbake fsl-image-machine-test -c populate_sdk

Also tried to add -f to force it to generate if even if nothing needed.  No change.

Is there a special bitbake command to do cleanall just for the SDK?   (It would be a killa time wise to do cleanall on all the image ... )

[gusarambula]

I would recommend doing a complete cleanall.

It is my understanding that building the SDK should build all required files so you do not need to specify which image to build if you just want to build the SDK, but I may be wrong.

The BSP usually uses the meta-toolchain recipe to create the SDK so I’m more accustom to that way buy in the end both alternatives would perform the populate_sdk instruction.

Regards,

[dry]

Hi,

I did bitbake clean, which does not remove the sources at least. ( I tend to think this would be crazy to do, re-download & re-build all , even those that aren't affected).

gusarambula wrote:

It is my understanding that building the SDK should build all required files so you do not need to specify which image to build if you just want to build the SDK, but I may be wrong.

It seems this is wrong, as omitting the image  name  (as per NXP Yocto doc), fails to build SDK.  May be NXP's layer configs missing or such .. I dunno.

So without the -c populate_sdk, i can get no SDK.

What is strange is the pupulate_sdk_ext  (the extensible is it?) does have those environment setup scripts I'm missing. But that's not the SDK i want .. and it's too large.

After having reviewed what I changed - which was just to add extra application libraries to the target image - i cannot understand how this could have broken SDK generation ..

And if I have to cleanall after every such change , well this is just too frustrating.  Its very very painfully long process to rebuild it all .

Any other ideas.. ?   (before I do cleanall .. and go for a vacation waiting for it to build  :smileysad: )

[gusarambula]

Hello D. RY,

A cleanall is often a good starting point although I understand it’s very time consuming.

Yocto is meant as a distribution method rather than a development tool, which is why it does not track changes as some other development-centric solutions. That’s why the safest way to ensure a change is being considered is making a cleanall.

Have you tried using the meta-toolchain recipe for building the SDK? Or your changes require using the populate_sdk instruction directly?

Regards,

[dry]

Hi gusarambula,

... 

Have you tried using the meta-toolchain recipe for building the SDK? Or your changes require using the populate_sdk instruction directly?

 ...

meta-toolchain-sdk is not available seems, with the NXP's released/delivered Yocto system. If you look at their Yocto howto doc, they refer only to using -c populate_sdk.

I have tried meta-toolchain, and that seems to generate something very minimal , not even 1/10th size of full SDK that should get generated for the image.

May be NXP's Yocto release did not setup those recipes up to be buildable by self.

The -c populate_sdk_ext (for external or extensible , was it..) seems to generate a working sdk, but this is way much larger than normal or default sdk. And I wouldn't want it.

[gusarambula]

Hello D. RY,

The meta-toolchain recipe is the supported sdk on NXP’s BSP and it’s used primarily to extract the toolchain for cross compilation.

I was looking at how this recipe generates the toolchain and it inherits the populate_sdk bitbake class which calls for the populate_sdk_base bitbake class.

Perhaps you can create a customized recipe that calls for the class that most closely matches your requirements and customize accordingly (either the base or extended). There is a manual from the Yocto Project dedicated to this subject as it’s not a trivial task (link below).

https://www.yoctoproject.org/docs/2.2/sdk-manual/sdk-manual.html

You can find the differences between the base and extended SDK classes there, maybe that can help to see if it’s easier to strip the extended version from unnecessary elements or start with the minimal SDK and adding elements as required.

Regards,