cancel
Showing results for 
Search instead for 
Did you mean: 

Where are bootfs, userfs, and vendorfs installed by bitbake?

mjuels
Associate II

I am bitbaking the core-image-minimal image, for a plain yocto poky distribution (Kirkstone), using stm32mp1 as my machine, and I am trying to figure out how the various st partition images are included in the build process. 

That is, how and where are the st-image-bootfs.bb, st-image-userfs.bb  and st-image-vendorfs.bb included in the core-image-minimal build? Everything is build as intended, but I cannot figure out how.

I cannot find anywhere, where the recipes are added to any of the environment variables I usually use to include recipes, (IMAGE_INSTALL, PACKAGE_INSTALL, etc.).

The only place I can find a reference to, for instance the bootfs recipe, is in meta-st-stm32mp/conf/machine/include/st-machine-common-stm32mp.inc

STM32MP_BOOTFS_IMAGE ?= "st-image-bootfs"

 But I cannot trace that to how the recipe is included in the build.

Please help.

1 ACCEPTED SOLUTION

Accepted Solutions

@mjuels ,
It looks a little bit tricky. In fact, you have to consider st-images-vendorfs, st-image-userfs and so on as real image. BUT, when you compile with Yocto/Bitbake, you choose to compile one unique image, not multiple ones.

In our case, we must compile also these other images, but without being able to say it clearly to Bitbake, so how to do ? The trick is here, integration team adds a dependency on a task of each other partition in the script I highlighted, <partition>:do_<...>, so the dependency is made by a workaround solution. 

To go further, we could imagine that the do_populate_lic_deploy could have been a different task than this one. The idea is to create the dependency with the image, not particularly with the task. Of course the task is not chosen randomly and there is a reason why they took this one, but do not focus on the task taken but more on the dependency created between your main image and partitions images.

I hope it is clear, not easy to explain I admit.

Kind regards,
Erwan.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

View solution in original post

6 REPLIES 6
Erwan SZYMANSKI
ST Employee

Hello @mjuels ,
The dependencies on these different recipes are not explicit, as hidden inside a function located in st-partitions-image.bbclassaround line 100. You will see a comment saying Make sure to append the partition build to current image target. This is the script below that do the job.

Kind regards,
Erwan.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

Hello Erwan,

Thank you for the reply!

I went throguh the file, and I see how the IMAGE_PARTITIONS gets analyzed for the content defined in
meta-st-stm32mp/conf/machine/include/st-machine-common-stm32mp.inc

I do not however understand which part of the script that tells bitbake to run the recipe?

I can see that the script sets up a number of variables. eg. IMAGE_PARTITION_MOUNTPOINT, IMAGE_ROOTFS_SIZE, for each file system, and that the file-system information is pushed to the image_partitions variable, but from there I do not see how it is used?

In the section of the script you reference, there is an explicit check "if current_image_name not in image_partitions ..." which excludes everything already set up in image_partitions, so I cannot see how the content of image_partitions is used in relation to bitbake.

Can you elaborate a bit on how the recipes are implicitly included based on the work done by the script?


Thank you for your assistance!

Best regards

Hello @Erwan SZYMANSKI 

Thank you for your reply - It has increased my insight a bit, but can you possibly elaborate on some of the details in my other reply?

As I mentioned, I can see that the script sets up a number of variables. eg. IMAGE_PARTITION_MOUNTPOINT, IMAGE_ROOTFS_SIZE, for each file system, and that the file-system information is pushed to the image_partitions variable.

However, I do not yet understand how any of this is subsequently used to tell bitbake to run the recipes?

 

Best regards

Hi @mjuels ,
Sorry for delayed answer, I was out of office for few days.

The real important lines to take care about in the portion of script I highlighted are the ones below :

for partition in image_partitions:
                        bb.debug(1, "Appending %s image build to 'do_image' depends tasks." % partition)
                        # We need to make sure the manifest file is deployed as we need it for 'image_rootfs_image_clean_task'
                        d.appendVarFlag('do_image', 'depends', ' %s:do_populate_lic_deploy' % partition)

It is a little bit tricky to get, but here, for each partition, we add a new dependency to the do_image task, that is : <partition>:do_populate_lic_deploy.

I advice you to activate debug logs to better understand the process, it will give you clear information about what happens precisely.

Kind regards,
Erwan.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

Hi @Erwan SZYMANSKI 

Thank you very much for taking the time to elaborate!

I am trying to understand the debug information as you suggest.

In that regard, I cannot find any documentation on the web concerning neither the use/purpose of the "do_populate_lic_deploy" task, nor how a recipe can be included by adding the dependency of "do_populate_lic_deploy" to "do_image"

I hope you will elaborate further, or can guide me towards any documentation on the subject, that I may have missed.

Thank you very much for your help

Best regards.

 

 

@mjuels ,
It looks a little bit tricky. In fact, you have to consider st-images-vendorfs, st-image-userfs and so on as real image. BUT, when you compile with Yocto/Bitbake, you choose to compile one unique image, not multiple ones.

In our case, we must compile also these other images, but without being able to say it clearly to Bitbake, so how to do ? The trick is here, integration team adds a dependency on a task of each other partition in the script I highlighted, <partition>:do_<...>, so the dependency is made by a workaround solution. 

To go further, we could imagine that the do_populate_lic_deploy could have been a different task than this one. The idea is to create the dependency with the image, not particularly with the task. Of course the task is not chosen randomly and there is a reason why they took this one, but do not focus on the task taken but more on the dependency created between your main image and partitions images.

I hope it is clear, not easy to explain I admit.

Kind regards,
Erwan.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.