From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id tJz/JOdbzmA4GAAAgWs5BA (envelope-from ) for ; Sat, 19 Jun 2021 23:04:39 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id yCEoIOdbzmDpdAAA1q6Kng (envelope-from ) for ; Sat, 19 Jun 2021 21:04:39 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 0C07625E26 for ; Sat, 19 Jun 2021 23:04:39 +0200 (CEST) Received: from localhost ([::1]:34518 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lui8s-0007JC-1F for larch@yhetil.org; Sat, 19 Jun 2021 17:04:38 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51960) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lui8K-0007Iz-13 for guix-devel@gnu.org; Sat, 19 Jun 2021 17:04:04 -0400 Received: from cascadia.aikidev.net ([173.255.214.101]:53674) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lui8F-0001Es-Co for guix-devel@gnu.org; Sat, 19 Jun 2021 17:04:03 -0400 Received: from localhost (unknown [IPv6:2600:3c01:e000:21:21:21:0:100b]) (Authenticated sender: vagrant@cascadia.debian.net) by cascadia.aikidev.net (Postfix) with ESMTPSA id 5FC7A1AA32; Sat, 19 Jun 2021 14:03:54 -0700 (PDT) From: Vagrant Cascadian To: Stefan , Danny Milosavljevic Subject: Re: Supporting *multiple* bootloaders for arm64 on a single install? In-Reply-To: <6577B35F-1261-4EFF-81E4-E531A3FD6930@vodafonemail.de> References: <87y2bmznak.fsf@ponder> <20210619140050.0715df69@scratchpost.org> <6577B35F-1261-4EFF-81E4-E531A3FD6930@vodafonemail.de> Date: Sat, 19 Jun 2021 14:03:50 -0700 Message-ID: <87v969lg7d.fsf@yucca> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: none client-ip=173.255.214.101; envelope-from=vagrant@debian.org; helo=cascadia.aikidev.net X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel@gnu.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1624136679; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=KhEHMoPySAj0MwfenMKYbYA03QF1KpFlp7AChOAcbUA=; b=b31kWO0lkh5Lz3sqcpZDq0yDGKUNBTRRO4bA0VmhvzMXBfx3kvb3UNa4wXz89OwFCwhCS9 LTDdagU0F7ocYdW0TJGmxZeQ5acNw3M+Zu8Puj9vmsSMqTGebFKjxqk00elraRlx73yPA/ HT2CFwYHIRTjXlapCcdkhKJzmD55ktwplIQbEPrL5k8XlGmgq9aPSZN1tfZs75dDQbugF5 nLZoJzK+91PMI1+vbXm7fRcSZk/GqjO0A0wCGo8CsuELntn1xgZYU/NMf6fuFQAXutSbOv j7wkoiZmZVfIt92jDkAJ9MBSiynfb6401rS3O4M2hjn4WYbMNKR/l/Tz/1u0ww== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1624136679; a=rsa-sha256; cv=none; b=QXyrVQlpL7UVOHPnbCuB2sKWItywl3RiXHa3fg2J6Z5IDKjkZwcT7L7RlRNta2LxFn2Dv0 aRqG7mG+QPV0LwaYI6GCx5veXvXoIWwTTMpHEAJU4gU4HuvK+tUeYRf+iW1ULcuBXagIkE NPcYA6aVc4cbnUdoMiX+Z+lIKQr7MHrjU/atxd9Kas/KWUBLON5PKAgI0L54LhKhr5Qf0z BChe+xDY+LbWDEy94iw9uLGoyQ9nlgrLjgdTPi6qojkip2slStvIx5PBGaHO86gqYs2FTK S4WfSbWFThX9QnLO55tq5z8utGOgce84RKqRnhwYTfOGHE2jljcLMCpr+UyR4Q== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Spam-Score: -3.02 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: 0C07625E26 X-Spam-Score: -3.02 X-Migadu-Scanner: scn1.migadu.com X-TUID: ru7s4vwh3ew4 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2021-06-19, Stefan wrote: >>> To support all of the above, I would need three separate bootloader >>> instances... one for Pinebook, one for Pinebook Pro, and lastly a >>> grub-efi bootloader. ... >> The chain bootloader itself is one Guix bootloader. >>=20 >> I advise you to search for mails by Stefan on the guix-devel mailing lis= t--those >> are very illuminating. ... >> If you do want to chainload grub-efi eventually, that's supported in Gui= x master, >> see "efi-bootloader-chain". It's meant for the end user to be able to u= se. > > Referring to the patch #48314, the efi-bootloader-chain got > simplified. It basically prepares a profile with all files to be > copied as is, no special =E2=80=9Ccollection=E2=80=9D folder any more. An= d the > installer of the grub-efi-netboot-(removable-)bootloader is now merely > a simple =E2=80=9C(copy-recursively bootloader-profile)=E2=80=9C procedur= e. >>> A related idea would be to generate an EFI bootable image with >>> sufficient emtpy space before the first partition (16MB) and then one >>> could manually install the appropriate u-boot, maybe with some helper >>> scripts to avoid having to do it completely manually... ... > I believe that the ARM future is UEFI, like on PCs. A lot of > distributions already chainload U-Boot and GRUB an arm systems. There > is a specification for ARM servers which demands UEFI=C2=B9. And there is > even the choice between U-Boot and TianoCore/EDK II. Yes, standardizing on UEFI in general would be a good thing, especially because u-boot can increasingly fill that role for boards that don't have a tianocore/edkII implementation. My heart is more with u-boot, but i also value standardization. :) > I think meanwhile that it would be beneficial, if, beside a bootloader > field, Guix would accept an optional firmware field. Then the U-Boot > or TianoCore/EDK II (or coreboot) could become some board specific > firmware, and the actual bootloader would be grub-efi installed on an > EFI System Partition. For systems like the Raspberry, which require > their firmware on a FAT partition, there is the already working > efi-bootloader-chain solution. Yeah, I like that idea! Das U-boot functionally is both kind of boot firmware as well as a bootloader rolled into one; I could see treating it more as a firmware which may not actually even need a separate bootloader (other than maybe generating a boot script or extlinux.conf), or a firmware implments EFI (and thus can load grub-efi). > The firmware could only be installed on explicit request. It's not > expected to see frequent changes =E2=80=93 every re-installation is a ris= k to > brick the system. (For my taste the bootloader is re-installed too > often already.) Mixed feelings on that; it puts you in the situation of not knowing when the current guix bootloader/firmware is broken if you don't reinstall it (although maybe it could be made smarter and only reinstall bootloader/firmware when it actually changes). It's already possible to pass an empty bootloader that just generates the configuration files for grub or extlinux which doesn't re-install(to my knowledge). Extending that to the proposed firmware idea would make some sense... live well, vagrant --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCYM5btwAKCRDcUY/If5cW qpJHAP9bChSEeO/OojUdIkSSfXEZiWGM/wOl2ztdYXFrA4kRyQEA/U5rixhYX2n4 IwZf1eAa22MyS2kx+45fc3fnS9zjOwM= =BRFl -----END PGP SIGNATURE----- --=-=-=--