Overriding default image generation with yocto

cancel
Showing results for 
Search instead for 
Did you mean: 

Overriding default image generation with yocto

3,162 Views
chrisratliff
Contributor I

I have been attempting to change the partitioning scheme implemented by default in meta-fsl-arm.  To do this simply There are only two lines I need to modify to create the image I desire in image_types_fsl.bbclass, but I know this is not the Yocto way of doing things.

The two lines are:

Adding :

parted -s ${SDCARD} unit KiB mkpart primary $(expr  ${IMAGE_ROOTFS_ALIGNMENT} \+ ${BOOT_SPACE_ALIGNED} \+ $ROOTFS_SIZE) $(expr ${IMAGE_ROOTFS_ALIGNMENT} \+ ${BOOT_SPACE_ALIGNED} \+ $ROOTFS_SIZE \+ $ROOTFS_SIZE)

to generate_imx_sdcard

and

Modifying:

SDCARD_SIZE=$(expr ${IMAGE_ROOTFS_ALIGNMENT} + ${BOOT_SPACE_ALIGNED} + $ROOTFS_SIZE + ${IMAGE_ROOTFS_ALIGNMENT})

to
 SDCARD_SIZE=$(expr ${IMAGE_ROOTFS_ALIGNMENT} + ${BOOT_SPACE_ALIGNED} + $ROOTFS_SIZE + ${IMAGE_ROOTFS_ALIGNMENT} + $ROOTFS_SIZE + ${IMAGE_ROOTFS_ALIGNMENT})

in IMAGE_CMD_sdcard

I have been attempting to somehow override these functions with functions in my layer with these modifications to do things the Yocto way, but am having trouble achieving this.

I had tried to append to the class with new versions of those two functions which caused built errors. As well as attempting to remove the classes via IMAGE_CLASSES_remove and replaced with my own version and overriding the functions in the class by having the functions in my own image_types_fsl.bbclass file.  These did not work.  Any advice as to how to proceed would be appreciated, thanks.

0 Kudos
4 Replies

670 Views
brendanta
Contributor II

Hello Chris,

I stumbled across this post of yours where I aim to achieve a very similar goal to your question.  Did you end up finding a solution to your problem?  If so, could you please share your solution?

Thanks

0 Kudos

670 Views
gusarambula
NXP TechSupport
NXP TechSupport

Hello Chris Ratliff,

Since these are all Yocto variables. I would recommend creating a recipe append in your new layer as you already did and making sure the priority of your layer is higher so the final assignment is taken into account.

There is information on how to create a new layer in the following document. Make sure that the append file is located on the same relative path on your new layer.

https://community.nxp.com/docs/DOC-331917

Perhaps you can share the errors listed when trying to apply your patch.

Regards,

0 Kudos

670 Views
chrisratliff
Contributor I

The error I receive when I attempted to create a .bbappend file was.

ERROR: No recipes available for:
  /home/cratliff/[...]/image_types_fsl.bbappend

Which think is because I am unable to append to a class, I must append the recipe which includes the class. I unsuccessfully attempted this by creating both image_types_fsl.bbappend and image_types_fsl.bbclass files under meta-my-layer/classes.

 

With everything else I have done, it is not that I receive an error, but that anything I try to append or override in the class is ignored.  I am able to verify my layer is included by the inclusion of helloworld in the rootfs though.

 

I set the priority of my-layer to 9 as I saw the priority of meta-fsl-bsp-release was 8.

 

I created the bbappend for the recipe 'fsl-image-gui' in the parallel path in my layer.

  meta-my-layer/imx/meta-sdk/recipes-fsl/images/fsl-image-gui.bbappend

 

No error is produced, but the function runs from the original image-types-fsl instead of the modified version in the newly created fsl-image-gui.bbappend.

 

running 'bitbake -e fsl-image-gui'  generates this tree: (reduced to show only relevant entries)

# conf/bitbake.conf includes:
#   /home/cratliff/fsl-community-bsp/sources/meta-fsl-arm/conf/machine/imx6qsabresd.conf includes:
#     /home/cratliff/fsl-community-bsp/sources/meta-fsl-arm/conf/machine/include/imx6sabresd-common.inc includes:
#       /home/cratliff/fsl-community-bsp/sources/meta-fsl-arm/conf/machine/include/imx-base.inc includes:
#         /home/cratliff/fsl-community-bsp/sources/meta-fsl-arm/conf/machine/include/fsl-default-settings.inc

 

with fsl-default-settings.inc being where image-types-fsl is added to the IMAGE_CLASSES variables.

I was able to successfully to IMAGE_CLASSES_remove and then add my own modified version of the class file by placing those commands in a .conf file instead of my  my-recipe.bb or image-types-fsl.bbappends, but this still does not seem like the ideal way to change the image generated as it requires copying and modifying a file from an fsl layer.

0 Kudos

670 Views
gusarambula
NXP TechSupport
NXP TechSupport

Hello Chris Ratliff,

I’m glad to hear you had a workaround but I agree it’s not the most elegant implementation possible.

I think the problem may be that you are appending a class file and I’m not sure this is valid, at least I haven’t seen it in practice. I would recommend trying to just place the duplicated (and updated) class on your layer. Since it has a higher priority it should take this class and not the original one.

You may alternatively do a bbappend for the image recipe using the class rather than the class itself. Seems that this scenario wouldn’t have troubles in your current configuration.

I hope this helps!

Regards,

0 Kudos