unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Vagrant Cascadian <vagrant@debian.org>
Cc: guix-devel@gnu.org
Subject: Re: ARMHF flash image - Put on website under GuixSD
Date: Mon, 10 Sep 2018 22:54:32 +0200	[thread overview]
Message-ID: <878t49ax9z.fsf@gnu.org> (raw)
In-Reply-To: <87y3c92w6e.fsf@aikidev.net> (Vagrant Cascadian's message of "Mon, 10 Sep 2018 08:45:29 -0700")

Hello Vagrant,

Vagrant Cascadian <vagrant@debian.org> 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	other threads:[~2018-09-10 21:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-07 20:21 ARMHF flash image - Put on website under GuixSD Danny Milosavljevic
2018-09-10 12:28 ` Ludovic Courtès
2018-09-10 13:47   ` pelzflorian (Florian Pelz)
2018-09-10 15:12   ` Danny Milosavljevic
2018-09-10 15:45   ` Vagrant Cascadian
2018-09-10 20:54     ` Ludovic Courtès [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878t49ax9z.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=vagrant@debian.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).