Request to revert the stsplitpartitions work

[bhstalel]

This is really hard Pull Request and I was really amazed by the how things are turning around for meta-st-stm32mp.

I remember that I gave a talk in the last Yocto summit about the complexity of meta-st-stm32mp and how we can optimize it more by removing ~70% of the code developed in the machine level. And yet, here I can see a new code developed where the old r2 release was more clear, simple and practical for all developers.

With this new feature stsplitpartitions it is now very hard for developers to deal with the partitions, and here is the reason why:

Let me start by explaining to readers the old way to do things:

• boot partition was build as ext4 with an image recipe (st-image-bootfs) that included by default kernel devicetree, imagebootfs and extlinux of u-boot by default. And if someone wants to add something to it, it is simple, a simple .bbappend and a simple IMAGE_INSTALL/PACKAGE_INSTALL append.
• userfs and vendorfs partitions are the same way
• Partitions handling process just takes the current built image and check if it is rootfs then it will make it depends on all the rest of images that are present in PARTITIONS_IMAGES variable
• With all the above, when you build, let's say core-image-minimal, you get all other recipes built and deployed and voila !

Now, all of the partition image recipes are removed, and instead all files (kernel image, devicetree, extlinux, m33/m0 binaries, userfs, vendorfs stuff, ..) all are installed in rootfs and then with a new image fstype, a for loop goes through PARTITIONS_IMAGES and take the mount point of each partition, and copy the content of that folder (that is actually installed in the first place in rootfs) and move it to a new folder called splitted_${label} where label can be (userfs, bootfs or vendorfs) or any other value if you add something to PARTITIONS_IMAGES.

My question is: why ?

And here are my other questions:

• What if I need to add something to splitted_bootfs, what should I do ?, the only way is to force my recipe to install the files in ${D}/boot and then I need to add that recipe to my rootfs and voila ! And that would be so confusing for project development and maintanance, imagine the following in my project-image.bb:

# Add this to rootfs and it will be splitted automatically to bootfs by stsplitpartitions class
IMAGE_INSTALL:append = " some-boot-file"

• All important boot files are added to MACHINE_EXTRA_RRECOMMENDS and that makes the developer always keeping recommendations enabled, if we optimize our build with NO_RECOMMENDATIONS = "1", that will result in empty bootfs and userfs. I actually tried it for st-image-core and other images.

In lot of other examples, we modify PARTITIONS_IMAGES to include A/B partitionning for bootfs, rootfs and userfs so we can have a correct auto-generated flashlayout, and with this new feature (even with old release) we only use this to generate the flashlayout once and then disable everything so other services and script keep working correctly with non-A/B partitions, such as mount-partitions.

I am trying so hard to teach people how to use STM32MP boards, I have lot of videos in the TechLeef YouTube channel, and I talked about your BSP layer in Yocto events, and I would love to get an answer about this and that you really understand my point of view and suggest something.

If you want a contributor, I am available for that, just keep me in touch with your ideas and plans so I can help with what the community wants and feels about BSP layers.

[bhstalel]

I forgot to say that this is not backward compatible, and every company in the world that uses ST's old partitions recipes way, will need to adapt lot of stuff to be aligned with r3 release.

[yassibeh]

We have the same issue on our side.

Our downstream integration still relies on the previous image/partition workflow, with separate partition-oriented image handling. When moving to the new stsplitpartitions model, we hit the same kind of migration cost and backward-compatibility problems described here.

In practice, the new flow changes more than just implementation details: it also changes how partition content is produced and how existing downstream logic has to integrate with bootfs/rootfs and partition image handling. For an existing project, that is not a small refactor.

Because of that, we currently keep a downstream legacy approach instead of fully switching to stsplitpartitions.

So from our side, this concern is real as well: the new mechanism may be valid technically, but it is much harder to adopt for projects that were built around the previous partition/image model.