From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: ARMHF flash image - Put on website under GuixSD Date: Mon, 10 Sep 2018 22:54:32 +0200 Message-ID: <878t49ax9z.fsf@gnu.org> References: <20180907222110.50e6bac2@scratchpost.org> <877ejth6yj.fsf@gnu.org> <87y3c92w6e.fsf@aikidev.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([208.118.235.92]:39928) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fzTNs-0008ER-8p for guix-devel@gnu.org; Mon, 10 Sep 2018 17:06:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fzTCe-0001il-H4 for guix-devel@gnu.org; Mon, 10 Sep 2018 16:54:37 -0400 In-Reply-To: <87y3c92w6e.fsf@aikidev.net> (Vagrant Cascadian's message of "Mon, 10 Sep 2018 08:45:29 -0700") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Vagrant Cascadian Cc: guix-devel@gnu.org Hello Vagrant, Vagrant Cascadian 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=E2=80=99d need to find how to generate these two parts of the image (may= be that=E2=80=99d require changes to =E2=80=98guix system=E2=80=99 & co.?). T= hen 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 =E2=80=98guix system=E2=80=99 to generate these image parts, adjust the =E2=80=9Crelease= =E2=80=9D target in Makefile.am, add some documentation under =E2=80=9CSystem Installation=E2= =80=9D in the manual, and possibly adjust the download page of the web site. It=E2=80=99s not a trivial change because of all these bits that need to be adjusted, but it=E2=80=99s doable. Who=E2=80=99d like to give it a go? Thanks for explaining! Ludo=E2=80=99.