Re: ARMHF flash image - Put on website under GuixSD

[Vagrant Cascadian]

On 2018-09-10, Ludovic Courtès <address@hidden> wrote:
> Danny Milosavljevic <address@hidden> skribis:
>
>> finally, https://hydra.gnu.org/build/3044681 (flash-image armhf) built.
>>
>> Can we put it on the website at https://www.gnu.org/software/guix/download/
>> inside the GuixSD part?
>>
>> I think it would be nice to have something ready-to-go for ARM systems as 
>> well,
>> and this would be a good start.  Apart from the bootloader, everything should
>> work as-is in there.  And the user can either keep the original bootloader
>> on the board or flash a new one after booting GuixSD - either in qemu or
>> on a real machine.
>
> I agree that it would be nice, but to what extent is this image generic
> to all ARM boards?  My understanding is that images are necessarily
> bound to a specific board.

An armhf image should generally be able to support most modern 32-bit
arm boards, and an aarch64 image should be able to support most 64-bit
boards. At least to the extent that they are supported in linux-libre.

As Danny said, the bootloader is board-specific. This would either be
present in firmware on the board itself, or need to be added to the
image itself or other boot media manually.

For systems that use a modern u-boot, this should work if the image
includes the generated /boot/extlinux/extlinux.conf, and the initrd
doesn't require any tweaks to the included modules.

For EFI systems, it would probably require installing the appropriate
grub-efi bits.

For maximal compatibility, it would be best if both the relevent u-boot
and EFI bits were installed; they don't necessarily conflict, and modern
u-boot even has an EFI implementation (though may not work on many armhf
systems).


For comparison, the supported debian-installer images have a two-part
image:

  
https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/README.concatenateable_images

Which contains the board-specific bootloader firmware and the common
parts as two separate images.

This has the obvious downside of requiring more work from the end-user
to assemble the correct image with the advantage being that the common
parts (which is the vast majority of the image) are shipped only once.


I could see it making sense for guix to generate a common image, and
then using that common image as an input to generate an image with the
bootloader installed, but maybe the substitute servers wouldn't build
the generated images by default?


live well,
  vagrant

signature.asc
Description: PGP signature