Note that you can actually build u-boot using the kbuild plugin. This allows cross compilation with snapcraft --target-arch armhf. You just need to set build-attributes: [no-install] to avoid calling make install.
Since i wrote these blog posts some improvements in snapcraft have been made, the “on” and “to” statements for build-packages can actually make cross building 100% transparent now (independent of what plugin you use), so if the snapcraft.yaml is properly crafted you can just call snapcraft without any --target-arch options (the target arch for gadgets is typically fixed and defined in the yaml already).
If you look at the dragonboard gadget snap you can see that this already uses the kbuild plugin, the problem here is that you need a new enough u-boot tree to support this. Many old board implementations still have not been ported (and probably never will) or simply come with a forked old u-boot tree the BSP lives on top that you will have to deal with.
My personal problem with the kbuild plugin is that it makes everything a bit more opaque, when i want to explain the process to some newcomer a few lines of shell in a script snippet in snapcraft.yaml is easier to understand IMHO. But yeah, you can definitely use kbuild here as well.
Hi, I followed your blog posts about gadget snaps. I was hoping if you could please explain more in details the uboot.env.in. I’m trying to create a gadget snap for imx6 pico itx board and I’m not sure if I’m setting the env file correctly.
I was able to populate my env file and bring up my board by changing hard coded addresses, kernel boot parameters and adding snappy variables (copied from example from the blog posts). But it would be good to understand in details how snapd and u-boot work together.