From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id n6JIFy3gzWBNygAAgWs5BA (envelope-from ) for ; Sat, 19 Jun 2021 14:16:45 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id CW9PEi3gzWBjIAAAbx9fmQ (envelope-from ) for ; Sat, 19 Jun 2021 12:16:45 +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 CDB331FD1E for ; Sat, 19 Jun 2021 14:16:44 +0200 (CEST) Received: from localhost ([::1]:51708 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1luZtz-0006Tm-Pi for larch@yhetil.org; Sat, 19 Jun 2021 08:16:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59448) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1luZtm-0006Sc-0m for guix-devel@gnu.org; Sat, 19 Jun 2021 08:16:30 -0400 Received: from dd26836.kasserver.com ([85.13.145.193]:37580) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1luZti-0007sq-HE for guix-devel@gnu.org; Sat, 19 Jun 2021 08:16:29 -0400 Received: from localhost (84-115-233-88.cable.dynamic.surfer.at [84.115.233.88]) by dd26836.kasserver.com (Postfix) with ESMTPSA id 8C9613363AB6; Sat, 19 Jun 2021 14:16:16 +0200 (CEST) Date: Sat, 19 Jun 2021 14:16:10 +0200 From: Danny Milosavljevic To: Vagrant Cascadian Subject: Re: Supporting *multiple* bootloaders for arm64 on a single install? Message-ID: <20210619140050.0715df69@scratchpost.org> In-Reply-To: <87y2bmznak.fsf@ponder> References: <87y2bmznak.fsf@ponder> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/++qGq=Z6hlKbfMaO3uoV4Z/"; protocol="application/pgp-signature"; micalg=pgp-sha512 Received-SPF: none client-ip=85.13.145.193; envelope-from=dannym@scratchpost.org; helo=dd26836.kasserver.com X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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, Stefan 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=1624105004; 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=UNSewUG5DdmZTsZBRw1XL08MHhD2M/Bbbpoc4q/U4i0=; b=Dm/kV6ge7MJ3KjpI+ADLwE9ch6zsr/IOw5XverSC6n4AEOn0aV2FNBTHrci3oYa7L9S4Bs pqIY3LtW1HVnlZLl9vhPUnC4Eph0VSFj9y9JIIydW5iP1Kqisbb5Rl6cGkK7UUrqMp3hjC tRBJFvU+nVL3V/+/k4siWGieS57LvkCENWIwDlR8y2R+tSD/S0G87U94+ob8PwSbv6LBiK 8RgrqzgDY5WDexkoLR4YlVbWzm3JAMZ3VPHdhumUmexetXtj+pmFzOnqswOrkXUAi0YMQU qX56WQusEqrcvaqGzVrR07Lkb3+NuGAw9AnuXyMCfKhJZ/axmkapUEbB2umjJw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1624105004; a=rsa-sha256; cv=none; b=EnNX+1d8kvl0WClVM8knQQKHZ/46pL3j3sa5u/UVTVIjJZyQDiiWPi8gXAJJ7kddrSPpeg ykZMauiogOeCZiMMy3a/PexgXTPMUVtM93Z92L0ry4XIodki23Wd1oLofKTKSRHoQuQrg2 sBJhDVTOfhaRc3bOppz7FPNoob4YVcSLKRxg+Eqr+HBpRz/EdO+hZ1zV6R3LmFDPNvuezR m1FlTUSORee3N0yfiLP2JW/LtsGGmhJ+xVW/xiWy5eCyOU+v1kkMZzCCx3PfNyjhsz/UJ3 aVekAdAUl8euALtK5QJyrm+lRHonjwApgoq2e3lDBWq7ntKdH0baDoHHtog+Og== 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.52 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: CDB331FD1E X-Spam-Score: -3.52 X-Migadu-Scanner: scn1.migadu.com X-TUID: Ug8d5TnD2MH0 --Sig_/++qGq=Z6hlKbfMaO3uoV4Z/ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Vagrant, On Sun, 06 Jun 2021 14:38:27 -0700 Vagrant Cascadian wrote: > So, I've managed to get a single image that supports booting both the > Pinebook and Pinebook Pro reasonably well! I can pop the microSD card > out of one and put it into the other, and it boots! Awesome! > The only problem with my single image for multiple pinebooks variants is > it requires manually installing u-boot to different offsets for Pinebook > Pro (e.g. idbloader.img at sector 2112 rather than sector 64),=20 >as parts of the Pinebook bootloader are installed at overlapping offsets. Uhhh? Doesn't sound possible to me then to use the same image for both? I'm probably missing something. > But as I understand it, guix only supports a single bootloader entry.=20 That is correct. > 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. Stefan wrote a Guix chain bootloader that is in master--but it's meant to be only used for bootloaders where there is a primary "bare-metal-loaded" bootloader and the others are chain-loaded one-after-another from ONE files= ystem (for example Raspberry Pi and/or EFI bootloaders). (It's currently used in order to use an EFI bootloader hosted on NFS--which is an awesome way to manage embedded boards) The chain bootloader itself is one Guix bootloader. I advise you to search for mails by Stefan on the guix-devel mailing list--= those are very illuminating. > Installing u-boot-pinebook uses: > (define install-allwinner64-u-boot > #~(lambda (bootloader root-index image) > (let ((spl (string-append bootloader "/libexec/u-boot-sunxi-with-sp= l.bin")) > (u-boot (string-append bootloader "/libexec/u-boot-sunxi-with= -spl.fit.itb"))) > (write-file-on-device spl (stat:size (stat spl)) > image (* 8 1024)) > (write-file-on-device u-boot (stat:size (stat u-boot)) > image (* 40 1024))))) >=20 > Installing u-boot-pinebook-pro-rk3399 uses: >=20 > (define install-rockpro64-rk3399-u-boot > #~(lambda (bootloader root-index image) #~(lambda* (bootloader root-index image #:key idb-destination-offset) > (let ((idb (string-append bootloader "/libexec/idbloader.img")) > (u-boot (string-append bootloader "/libexec/u-boot.itb"))) > (write-file-on-device idb (stat:size (stat idb)) > image (* 64 512)) image (or idb-destination-offset (* 64 512)= )) > (write-file-on-device u-boot (stat:size (stat u-boot)) > image (* 16384 512))))) >=20 > (define install-pinebook-pro-rk3399-u-boot install-rockpro64-rk3399-u-boo= t) >=20 > But now I need to figure out how to pass a non-default offset for the > "idb" part for rockchip platforms. >=20 > In a system config.scm, you'd define it like so: >=20 > (bootloader (bootloader-configuration > (bootloader u-boot-pinebook-pro-rk3399-bootloader) > (target "/dev/mmcblk0"))) >=20 > u-boot-pinebook-pro-rk3399-bootloader is defined in > gnu/bootloader/u-boot.scm, which inherits from u-boot-bootloader, which > inherits from extlinux-bootloader in gnu/bootloader/extlinux.scm... >=20 > And somewhere along the way I've lost track of how we get to > install-pinebook-pro-rk3399-u-boot... It's in the "bootloader" record, field "disk-image-installer". If you search for "bootloader-disk-image-installer" in the Guix source code, you find the (two) callers of it. > Is it possible to definte multiple bootloaders [in the same operating-sys= tem] currently,=20 No--and I don't think that would have any advantages. If the thing is not a chain then Guix doesn't need to logically split the bootloaders in the first place. Ok: stage1 -> stage2 -> stage3 represented as (chain-bootloaders stage1 sta= ge2 stage3). Not ok: stage1-arch1 stage1-arch2 represented as two different bootloaders that both are specified in the same operating-system inside the same list. Instead, I think it's fine to just model that as one "weird" bootloader (arm64-pinebook-generic-bootloader)--especially if both use u-boot anyway a= nd also especially if they reuse some of their parts anyway (it's gonna have weird interdependencies in any case--so any apparent modularity would just be a r= use). > or if not, > what would need to change to be able to support that? Where would one > pass non-default offsets for a given platform? Could you elaborate on what you mean? Pass where? On the Guix command lin= e? If you mean the disk-image-installer, that's just a procedure (which is run build-side). You can make it do whatever you want--including hardcoding we= ird offsets. I'm pretty sure it gets the entire image (one could potentially m= angle) as a parameter anyway. > Strictly speaking, the extlinux.conf generation would be optional for an > EFI generated image(as u-boot can load grub-efi), although at the moment > I'd prefer using extlinux.conf if available as it makes for more > consistent matching of device-tree/.dtb file with the running kernel... If you do want to chainload grub-efi eventually, that's supported in Guix m= aster, see "efi-bootloader-chain". It's meant for the end user to be able to use. > 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... Yeah, that's possible right now. After all, you don't have to load the gen= erated guix system disk image on bare metal. Just boot it in qemu and install u-b= oot there for example. Or even edit the image manually by using dd. (unfortun= ately, on almost every ARM system I set up Guix on so far, one or both of those we= re necessary) That said, it's nice to have officially supported ARM systems where you can= just generate a disk image and it will boot without having to do weird extra stu= ff outside Guix. (In general, I want to reiterate that the buildroot project already has gen= image scripts for almost all ARM boards--and Guix uses genimage anyway! It makes= a lot of sense to write an importer for those instead of reinventing the wheel. = You really do not want to develop & maintain u-boot installation recipes for all 34432 ARM variants out there yourself--just use the recipes already develop= ed instead) --Sig_/++qGq=Z6hlKbfMaO3uoV4Z/ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAmDN4AoACgkQ5xo1VCww uqXDwgf/RQrbDsBKYT0/D9UlC89IOxlxFAlUCjQbaAdz3zhfGn6dUgrwGDEZuBWj stXyAE8RHP07Zypm+DIoRWCwF0R/erTfnrikHzPJXOdGDO5lSIIj5PPIxPKyidWk sq7OIEENhhJBww1nvEpy4bIjXuUJX9m00+OqJYR3BEiu4+uBh/3QCsehwOGOwyUS +GVms/TQ00+Ly6p9ZPDYPSzdm3vxiaacAEgAUCeiEkBO1WM4b4vHjID6dENufDY/ f7TNjdfSbQ/cEX9HnbG8Z9j6Ep7GUteBdlN4OVgHtoeq96RxMjJWcxDoYXQJxaME 13mmUGrHUFaEAaqE8jLy/aISLRw4cQ== =0Bj1 -----END PGP SIGNATURE----- --Sig_/++qGq=Z6hlKbfMaO3uoV4Z/--