guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ARMHF flash image - Put on website under GuixSD


From: Ludovic Courtès
Subject: Re: ARMHF flash image - Put on website under GuixSD
Date: Mon, 10 Sep 2018 22:54:32 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Hello Vagrant,

Vagrant Cascadian <address@hidden> skribis:

> 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).

OK.

> 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.

Interesting.

> 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?

We’d need to find how to generate these two parts of the image (maybe
that’d require changes to ‘guix system’ & co.?).  Then we can have
continuous integration jobs for all the various parts, especially if the
board-specific part is small.

At any rate, this approach sounds more viable than uploading a dozen of
nearly-identical 1GB images to ftp.gnu.org.  :-)

The way forward would be to find out what needs to be done in ‘guix
system’ to generate these image parts, adjust the “release” target in
Makefile.am, add some documentation under “System Installation” in the
manual, and possibly adjust the download page of the web site.

It’s not a trivial change because of all these bits that need to be
adjusted, but it’s doable.  Who’d like to give it a go?

Thanks for explaining!

Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]