Hello Denis,
> On the official builders we could build only 4 images for ARM. To do > that we could reserve space for u-boot in the images and find a way to > later add u-boot to these images in a separate step. I see multiple sources of duplication: 1. The images declarations in gnu/system/images/*.scm are often very similar. In addition, we also have the embedded-installation-os declarations in gnu/system/install.scm. They do not exactly serve the same purpose because embedded-installation-os are operating-system declarations, whereas the images files are, well, images :). However they share some common purpose: declare the UART name (ttyO0 or so), the default storage name (/dev/mmcblk0 or so) and the bootloader name. Plus, an image is an abstraction around an operating-system. I think that we should find a way to have all of those in the same place, most likely in gnu/system/install/*.scm. Then, it would be nice to declare the images in a less verbose way, maybe using macros to abstract the common parts. 2. As you mentioned, the final image will be 99% identical for all those boards, so finding a way to have a rootfs part that would be generic and substitutable and a boot part that would contain most of the board specific stuff (bootloader, kernel, dtb), as you proposed, would make sense to me. I guess that people using those images are most interested in the booting part. What happens then, in the rootfs is another story. On the ARMv7 boards, Guix itself is not really usable: there is often not enough RAM / CPU power to run "guix pull" anyway. To me, those image definitions are offering a nice way to deploy say a web server or any kind of service on an SD-card targeting a specific embedded device. Guix is used to produce the image but then won't be usable on the device itself. Reconfiguring probably means re-baking and re-flashing an image on the SD-card. In that sense, focusing on providing easy-to-use image definitions that the user can modify to run any kind of service/firmware on an embedded device, should be the end-goal here. They should not be treated as systems where we can one day run an installer and have a desktop-like experience. If you can come-up with a plan to solve those two issues, I would be happy to discuss it. Thanks, Mathieu
