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 ms11 with LMTPS id CJJmCesUp14pVAAA0tVLHw (envelope-from ) for ; Mon, 27 Apr 2020 17:22:51 +0000 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 WJ5FHvMUp14VdgAAbx9fmQ (envelope-from ) for ; Mon, 27 Apr 2020 17:22:59 +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 1037D941AA6 for ; Mon, 27 Apr 2020 17:22:58 +0000 (UTC) Received: from localhost ([::1]:56154 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jT7T7-00076f-Pm for larch@yhetil.org; Mon, 27 Apr 2020 13:22:57 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56064) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jT7Sn-000758-SM for help-guix@gnu.org; Mon, 27 Apr 2020 13:22:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jT7Sm-0007ug-DB for help-guix@gnu.org; Mon, 27 Apr 2020 13:22:37 -0400 Received: from cascadia.aikidev.net ([2600:3c01:e000:267:0:a171:de7:c]:56052) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jT7Sl-0007uZ-Rx for help-guix@gnu.org; Mon, 27 Apr 2020 13:22:36 -0400 Received: from localhost (unknown [IPv6:2600:3c01:e000:21:21:21:0:100e]) (Authenticated sender: vagrant@cascadia.debian.net) by cascadia.aikidev.net (Postfix) with ESMTPSA id C3C1B1A9BD; Mon, 27 Apr 2020 10:22:32 -0700 (PDT) From: Vagrant Cascadian To: Simon South Subject: Re: Building installation image for ROCK64 In-Reply-To: <87ees99icv.fsf@simonsouth.net> References: <87sgh9iz1v.fsf@simonsouth.net> <877dyl7mn0.fsf@yucca> <87o8reb9ob.fsf@simonsouth.net> <87zhayyy1d.fsf@ponder> <87ees99icv.fsf@simonsouth.net> Date: Mon, 27 Apr 2020 10:22:27 -0700 Message-ID: <87o8rcvo6k.fsf@ponder> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: none client-ip=2600:3c01:e000:267:0:a171:de7:c; envelope-from=vagrant@debian.org; helo=cascadia.aikidev.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/04/27 13:22:33 X-ACL-Warn: Detected OS = ??? X-Received-From: 2600:3c01:e000:267:0:a171:de7:c X-BeenThere: help-guix@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: help-guix@gnu.org Errors-To: help-guix-bounces+larch=yhetil.org@gnu.org Sender: "Help-Guix" X-Scanner: scn0 X-Spam-Score: -2.61 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of help-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=help-guix-bounces@gnu.org X-Scan-Result: default: False [-2.61 / 13.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; GENERIC_REPUTATION(0.00)[-0.55570221525301]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.51.188.0/24:c]; IP_REPUTATION_HAM(0.00)[asn: 22989(0.19), country: US(-0.00), ip: 209.51.188.17(-0.56)]; DWL_DNSWL_FAIL(0.00)[209.51.188.17:server fail]; MX_GOOD(-0.50)[cached: eggs.gnu.org]; RCPT_COUNT_TWO(0.00)[2]; MAILLIST(-0.20)[mailman]; SIGNED_PGP(-2.00)[]; FORGED_RECIPIENTS_MAILLIST(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:22989, ipnet:209.51.188.0/24, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TAGGED_FROM(0.00)[larch=yhetil.org]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[6]; FROM_NEQ_ENVFROM(0.00)[vagrant@debian.org,help-guix-bounces@gnu.org]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[debian.org]; HAS_LIST_UNSUB(-0.01)[]; DNSWL_BLOCKED(0.00)[209.51.188.17:from]; MID_RHS_NOT_FQDN(0.50)[]; FORGED_SENDER_MAILLIST(0.00)[] X-TUID: kVVejz3vTZag --=-=-= Content-Type: text/plain On 2020-04-27, Simon South wrote: > Vagrant Cascadian writes: >> With your current layout, parts of the bootloader may be written to the >> same offsets as files in your first partition... > > Yes, my mistake. Thanks for pointing that out. > >> You really want to have the loader1 (start sector 64, 2.5MB size) and >> loader2 (start sector 16384, 4MB size) partitions... > > I'm not sure how literally you meant this to be interpreted, but after a > bit of experimentation it seems the most sensible arrangement for now is > just to have a single partition starting at sector 32,768 for the root > filesystem. This is because That also should work fine. > - If real partitions are created for the bootloader stages and the > trusted firmware, U-Boot will fail to start the OS (with "Unrecognized > filesystem type") when it scans for bootable partitions. (It probably > ought to just skip over partitions without a recognizable filesystem, > but it doesn't seem to behave that way.) It's possible to mark the partition as bootable (I think "ESP Boot" or something like that). > - It seems Guix System does not yet support having /boot on a separate > partition and will fail at startup if the store isn't available on the > same filesystem as extlinux.conf. Consequently reserving 112 MB for a > separate boot partition accomplishes nothing. Right; I wouldn't suggest using such a tiny boot partition anyways (I think they suggest a 112MB /boot ?). > At least this way the root filesystem is safe from being overwritten by > the bootloader, and as Guix's support for multiple partitions improves > over time it'll be possible to more closely follow Rockchip's > conventions. Yeah, anything after sector 32768 is, in my opinion, fair game to do whatever you want with. :) >> It would be nice to eventually be able to create installer images for >> aarch64/armhf... > > Yes, absolutely. In the meantime just making available a > minimal-but-complete image for writing to a microSD card would be a big > help to people looking to get started quickly with Guix on the ROCK64. I'm tempted to make armhf and aarch64 one-off images using linux-image-arm64-generic and linux-image-arm-generic kernels, and include instructions for updating the bootloader, to support an arbitrary number of different systems... this should be doable. live well, vagrant --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCXqcU1AAKCRDcUY/If5cW qsarAQDkB3POngf6F9rBmu5fY2UH9pM2JxT5bTQ5Nn3XVPbH2QD/bwZRAS4VjUiq gXZBN3EH60zmaiuBTTwHAZ4kyezNJwU= =e52m -----END PGP SIGNATURE----- --=-=-=--