From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 4M1TDetWzmDeDQAAgWs5BA (envelope-from ) for ; Sat, 19 Jun 2021 22:43:23 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id YDboCOtWzmAjdAAAbx9fmQ (envelope-from ) for ; Sat, 19 Jun 2021 20:43:23 +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 8F6EA241EF for ; Sat, 19 Jun 2021 22:43:22 +0200 (CEST) Received: from localhost ([::1]:59408 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1luhoH-0003zW-H9 for larch@yhetil.org; Sat, 19 Jun 2021 16:43:21 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50096) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1luhnt-0003z8-JI for guix-devel@gnu.org; Sat, 19 Jun 2021 16:42:57 -0400 Received: from cascadia.aikidev.net ([173.255.214.101]:53632) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1luhnq-0004VQ-Kp for guix-devel@gnu.org; Sat, 19 Jun 2021 16:42:57 -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 10BD11AA32; Sat, 19 Jun 2021 13:42:50 -0700 (PDT) From: Vagrant Cascadian To: Danny Milosavljevic Subject: Re: Supporting *multiple* bootloaders for arm64 on a single install? In-Reply-To: <20210619140050.0715df69@scratchpost.org> References: <87y2bmznak.fsf@ponder> <20210619140050.0715df69@scratchpost.org> Date: Sat, 19 Jun 2021 13:42:46 -0700 Message-ID: <87y2b5lh6h.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, 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=1624135402; 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=S44D895Sb0CkWOD0IjXBSQsdjm6JRjZF+FNatfFDRFo=; b=HTAe9wLXRJB45rHHO4P4xUKoM+6sgvV5jNIi1ledqGW31jv3OORiN9tfsO66fVGARgdr0b FdDmxpZZK0TLVy2xKgwDy6fedNB9k5weXsjuvTaIzqogjglvYGoO4ook7tmuGYPxJwpDrI 6n61vaevPJvWRhstZCcB/J/eeqzKZsNbL7IUtJLQQ2WiPiRBZ4j6lD0JGv/nIyeRf7A15J tyLXLMRnsd/iQGr3+7zo7s+BcxfEle0/RhOVQUaQNSfB5SL2ecQwEWpKV7lW2QmoJvt5lm Anb03BSLaGr5TUcnejBJQo6fLxZhD8sYTc5GNWABln1hvMipLgGxV+1WBAV6Kg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1624135402; a=rsa-sha256; cv=none; b=dpbH15wnf93Wj93CmQ/NY5P8KVX1C7Y2OhjTImtP4DKAE8tUI+FDgrMHJlhJujmIUtMo48 mNWhM2gsKhl30LqufyeUmeVh/pEq1REe6dmtLocR0KkcXNrbSdey9/DSvo3QZ8GLBjYeA4 p9r6KeaFMrOTP6ym1oZ9uKxC1bDCu8xzWD9OTk+GtT/957qkLNBtT98QsYyHrjfWDGEy8D 9gXDsfRABu1WoKCYwnDIVRYMsXwOXqQOq6zuBiS6a16DHUEVJ1/1CVttLi0dreoZ4X9NlT PvhSNlIMe7WnLNfFhPgo0K+DWRirv4g/vq2Hteik8P/rbLLEJnDOI/DG2z33YQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=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: -0.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: 8F6EA241EF X-Spam-Score: -0.52 X-Migadu-Scanner: scn1.migadu.com X-TUID: kniDf9FAQBbj --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 2021-06-19, Danny Milosavljevic wrote: > 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! Thanks! and thanks for stirring up this quiet topic again :) >> 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. Different parts of the image can be written to different offsets on the boot media in a way that doesn't conflict. The boot ROM on allwinner and rockchip have a series of offsets they check for compatible boot code, and the offsets are different enough that you can have a pairing of allwinner and rockchip boards installed on the same boot media. The pair that makes "obvious" sense is the pinebook and pinebook-pro, though nearly any pairing of allwinner and rockchip boards would likely work. >> 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-load= ed" > bootloader and the others are chain-loaded one-after-another from ONE fil= esystem > (for example Raspberry Pi and/or EFI bootloaders). > > (It's currently used in order to use an EFI bootloader hosted on NFS--whi= ch > 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. Sounds possibly useful for this, yes.... >> 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-s= pl.bin")) >> (u-boot (string-append bootloader "/libexec/u-boot-sunxi-wit= h-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 51= 2))) > >> (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-bo= ot) Thanks! So I would need to add this in the bootloader section of config.scm and add the optional idb-destination-offset argument to all the intermediary functions... >> 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=20 >>=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 co= de, > you find the (two) callers of it. > >> Is it possible to definte multiple bootloaders [in the same operating-sy= stem] 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 s= tage2 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= and 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= ruse). Yeah, the two u-boot (pinebook, pinebook-pro-rk3399) used are entirely independent, neither of those are part of a single chain. But either u-boot variant *could* load grub-efi (and does look for potentialy EFI images if there's no extlinux.conf or boot.scr) as part of a bootloader chain... >> 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 l= ine? In config.scm. Sounds like making a specific arm64-pinebook-generic-bootloader like you suggested above might be an option, although it would be nice to be able to generalize it enough so that you could pick semi-arbitrary u-boot combinations (as long as they're compatible). > If you mean the disk-image-installer, that's just a procedure (which is r= un > build-side). You can make it do whatever you want--including hardcoding = weird > offsets. I'm pretty sure it gets the entire image (one could potentially= mangle) > as a parameter anyway. I've never successfully or knowingly used the disk-image-installer, as it doesn't support native builds. :/ Mostly, I've been doing "guix system init" and "guix system reconfigure", using the u-boot-pinebook-bootloader in config.scm since the default offsets work, and then manually installing the appropriate u-boot-pinebook-rk3399 bits, due to needing to use non-default offsets. >> 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= master, > see "efi-bootloader-chain". It's meant for the end user to be able to us= e. I'll look into it, thanks! >> 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 g= enerated > guix system disk image on bare metal. Just boot it in qemu and install u= -boot > there for example. No need to boot into qemu to install u-boot, it's just typically write a couple binaries to a specific offset in the resulting image... > Or even edit the image manually by using dd. (unfortunately, > on almost every ARM system I set up Guix on so far, one or both of those = were > necessary) Curious. I've had good luck with: (bootloader (bootloader-configuration (bootloader u-boot-pinebook-pro-rk3399-bootloader) (target "/dev/mmcblk0")))=20=20 Occasionally having to do weird things like passing /dev/sda instead if installing to a USB adapter for microSD or something. > That said, it's nice to have officially supported ARM systems where you c= an just > generate a disk image and it will boot without having to do weird extra s= tuff > outside Guix. That is the goal! > (In general, I want to reiterate that the buildroot project already has g= enimage > scripts for almost all ARM boards--and Guix uses genimage anyway! It mak= es 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 devel= oped > instead) Admittedly, I haven't looked into buildroot's genimage scripts beyond just a cursory glance... though have been meaning to even since you mentioned it what now seems ages ago. Maybe an importer would make a lot of sense, though it would likely loose some flexibility along the way (like my mad scientist schemes to install two u-boots on the same system). I've written some simple shell scripts for allwinner and rockchip systems for Debian that basically just dd various bits to offsets. And of course, I have looked at the code to do essentially the same thing in guix but in guile... I do wonder if the u-boot-FOO to install-u-boot-FOO chain could be refactored to remove a few intermediate steps, which is what I was hinting at in my earlier mail. When using upstream u-boot, it is a relatively small set of instructions; e.g. allwinner uses one set of instructions, rockchip uses another set of instructions, ti-family processors another, imx processors, and maybe a 32-bit variant for some of them... so ~6 standard installation sets covers hundreds or even thousands of boards, with a few outliers that differ. Most other platforms I'm aware of require non-free bits so are out of scope for guix. And thanks for reading thus far my rambling post about niche corner cases that are actually useful! :) live well, vagrant --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCYM5WxwAKCRDcUY/If5cW qpGTAQDi/8kpyvhaW1QuAuESXviimQzPDta8C5rL98lr2Pdg+QD+N2nkdjzXhzi5 6spTPK6VjsQc4FHKqFAk3gDMGTLHswE= =9HlE -----END PGP SIGNATURE----- --=-=-=--