there are cases where you can damage or even completely fry your hardware, no application snap should be allowed to load overlays …
application snaps are not limitable by board, they sit in the store for a specific architecture and while you can namespace them like i.e. “foobar-pi” they will still be installable on any other armhf system … so installing teh foobar-pi (shipping an overlay for the RPi only) snap on some allwinner or imx board will probably set some voltage on some regulator to a value that makes the chip go up in flames … this really needs to be done in the gadget …
that said, the Pi being a special case here with lots of extra hacks like the snap system keys to mangle config.txt via snap set/get, there could surely be a mechanism to set a dtoverlay value from some pi specific interface.
We could have the super-privileged interface but it would strictly be for experimentation only.
If we want first class support for this it would need to be mediated by snapd itself or at least specific gadgets.
I could imagine using the content interface or an interface like it, together with the declaration language that let us control it quite precisely, to provide the DTBs to snapd/the gadget for loading on behalf of the snap but not directly by the snap. In that approach the store/gadget brands and to some extent users but not the snaps would have a voice about what to load.
Is there a way or could a way be conceivable to check for conflict between DTBs before loading them?
@ogra - ok that is a good point re hardware incompatibility etc.
The other option for this is to get the overlay merged into the pi kernel itself, so then only a change is needed to config.txt to specify this to be loaded. This could be mediated and managed by snapd - and if needed down the track perhaps could be extended to allow snaps to ship overlays themselves for snapd to managed as well.
Either way it is probably useful to have this overlay in the standard core 18 pi kernel (since the driver is already there) so I’ll see if I can push that through an upcoming SRU cycle.
Regarding management of overlays via snapd, since we already have various pi config.txt settings accessible via snap set system pi-config.foo - perhaps we could just add pi-config.dtoverlay (and may as well then expose dtparam as well - https://elinux.org/RPiconfig#Device_Tree)?
On a related note for those creating gadget snaps for their devices, note that gadgets can have services (even with plugs) and for the case of say, a device that needs tpm_tis_spi with device tree overlay, one can:
create the device tree overlay like normal in the gadget
do a one-shot daemon in the gadget that writes out tpm_tis_spi to /etc/modules-load.d/<your filename>.conf (just make sure that <your filename> doesn’t start with 'snap.’
plugs system-files in your gadget that allows writing to /etc/modules-load.d/<your filename>.conf
setup your gadget to auto-connect system-files for itself
create the device tree overlay like normal in the gadget
Is the normal way to do this what was suggested by @ijohnson above, simply make sure to stage the binary .dtbo file to $SNAPCRAFT_PART_INSTALL/boot-assets/overlays/your-favorite-overlay.dtbo?
Also, and maybe I missing something, but doesn’t the inclusion of the correct DTB overlay for this TPM module automatically trigger the module loading? I’m not sure why you’re additionally adding a conf file to /etc/module-load.d/ to do this?
@ijohnson also mentioned modifying /boot/config.txt, however again with the correct overlay, I’m not sure why this would be required?
typically loading the dtbo powers up the peripherial device, which in turn means the kernel should see it and auto-load the correct module, there should be no manual intervention needed.
if possible (i know it is not always possible) a dtbo should be freshly compiled against the actual kernel. bits and pieces (regulators, interfaces, whatever) could be renamed between major kernel versions so if you have a dtbo for 4.15 it might have issues with 5.4.
this really depends what kind of addon board you have there and if it is something you actually need on first boot (i imagine tpm might be in that category).
snap configs are only applied during first boot after snapd started AFAIK so using a snap config option excludes all the addon HW that need to be initialized before.
config.txt is loaded (and executed by the proprietary bootloader) before we even get to u-boot or any other bit we control, i fear there is no way around modifying the file at gadget build time unless we make sure to have all gadget system configs applied by snap prepare-image at image build time (that would mean running the config hooks, not sure how feasible this is on an unbooted image)
AFAIK yes, but note my disclaimer that I’ve not personally re-built a pi gadget snap with an additional overlay like this.
I think this guidance from @jdstrand was specifically for an overlay that for whatever reason didn’t trigger the kernel module to auto-load.
I don’t think this is needed, I think this was just mentioned in passing as one possible way that might be used to accomplish the original topic of this conversation
