Per-image config.txt is not possible

[mcampbellizo]

Currently config.txt is setup as a recipe that will deploy config.txt. There are several influential environment variables that can affect its content. The issue comes when you might want to have different config settings on a per-image basis. For instance, in my case I'd like to make an image for general use, but then have another image that has specifc device tree overlays enabled. Because rpi-config_git.bb is a stand alone recipe it is unable to be affected by the image settings.

Proposed Solution (looking for comments) One possible solution I see is to remove all the customization that happens to config.txt from rpi-config.bb. This recipe would simply fetch and deploy config.txt as is. After that, we could move all customizaion into the do_image for the rpi-sdcard. This way, you could set any of the variables that would affect config.txt in the image recipe and they would work without affecting other recipes.

The downside to this is that any other image types that might want to use config.txt would not get this, however I cant think of a situation where you would want to do this. Either way, I think it's worth pointing out.

If people are generally on board with this solution I'd be happy to take a shot at this and post a PR.

[agherzan]

This is not a bad idea. I'm just worried about people assuming the current behaviour. I can see this working on both levels though by having a class which does modifications based on a set of variables on the config.txt. The same class is used both at the recipe level (creating the base config.txt - current behaviour) as well as usable at the image level (which adds another level of configuration). The only bit that needs to be figured out is the wic but for rpi-sdcard it should be fine.

[mcampbellizo]

I totally agree with your point that changing current behavior would be confusing. My work around right now was to copy the entire sdcard_image-rpi.bbclass into my custom layer and add some hooks in the image generation to allow me to intercept and make modifications to config.txt. This matches what your describing and seems like it might be the better route.

Based on the above implementation, here is how I see the workflow going. Let me know what you think. I'd like to get some buy off before I go and implement something.

• Factor the config.txt customization currently done in do_deploy of rpi-config into a bbclass
• rpi-config uses the above bbclass to customize based on the vars it can see (e.g. from distro, machine, layers, etc.)
• sdcard_image-rpi.bblcass adds a new function hook variable for customizing config.txt per-image. By default, it will reuse the config.txt bbclass so you can also use any of those settings on a per-image basis
• Users could also add arbitrary functions to that hook to do whatever that need to the config.txt per-image (up to and including just replacing it fully).

I think the combination of above would provide a nice combination of preserving current functionality that is useful while adding extra flexibility.

There is one flaw I can see that might be confusing for users. If a user sets a variable at a machine level, and the explicitly unset it in an image recipe, this will not remove the affects it had at the machine level. I'm not sure of a good way to handle this, and it might just need to be documented. Even with this flaw, I believe the extra flexibility is worth it. Let me know what you think, and thanks for the input so far!

P.S. I've been working with Yocto for about 3 years now and I've never really been able to wrap my head around what the wic images are and why they exist. There isn't a ton of documentation on it. Would you be able to point me to any?

[kraj]

IMO we should deprecate sdcard_image-rpi.bblcass, it has served us so far but wic is right replacement to generate SD-Card images and is aligned with upstream OE/Yocto direction when it comes to image generation.

Wic is documented here https://www.yoctoproject.org/docs/2.6/dev-manual/dev-manual.html#creating-partitioned-images-using-wic and https://www.yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#ref-kickstart

Let me know if you have further doubts

The customization to config.txt could actually be deferred to a image post processing task. and we can hook this via a global config metadata At image level you have global access and I think it would be good place to make edits to config.txt

secondly there are certain options which make changes in two places e.g. enable a kernel module and then set some variable in config.txt, in this case, the operation can happen in two different tasks as desired.

[mcampbellizo]

HI Krag, thanks for the input. I like the idea of just deferring config.txt customization fully to image post processing task (or possibly image pre processing, I'd have to look into that). With this, global data will have the same effect, and it can also be overridden on a per-image basis.

As for wic, I did some reading in that documentation and have my head wrapped around it more now. Thanks for that. Whether or not meta-raspberrypi plans on going to wic, I think that would be outside the scope of this PR. If I do all the heavy lifting with image post/pre tasks, from what I can tell that should seamlessly integrate with wic if we go in that direction.

Here's a refined version of the proposal:

• rpi-config recipe is only responsible for fetching and deploying config.txt. No customization is done at that time. Also, have it deploy directly to the deploy dir, not into the bcm2835-bootfiles folder. This will allow for customization before going into the image without modifying the deployed file itself.
• config.txt customization is still based on the same variables, but the code for this is contained in a bbclass that also will append itself as a image hook (either pre/post).
• The above bbclass is inherited at the machine level (or other global level) to make sure any image type will get these customizations
• A particular recipe can further modify config.txt by either setting/unsetting the vars that the above bblcass uses or by prepending/appending the modification function itself.
• All of the above should work with wic if we go in that direction

[hhromic]

IMO we should deprecate sdcard_image-rpi.bblcass, it has served us so far but wic is right replacement to generate SD-Card images and is aligned with upstream OE/Yocto direction when it comes to image generation.

Completely agree with this, definitively the layer should align to standard patterns where possible :)

[agherzan]

I don't have a strong feeling about removing the bbclass. I actually use it as the main generator still. I don't think it hurts for people wanting to use it.

[agherzan]

I will close this for now due to no activity. Feel free to comment to resurrect it if still needed.