From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on atuin.qyliss.net X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=3.4.6 Received: from atuin.qyliss.net (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id 37F928110B; Thu, 29 Sep 2022 10:22:37 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 496) id F013681106; Thu, 29 Sep 2022 10:22:35 +0000 (UTC) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) by atuin.qyliss.net (Postfix) with ESMTPS id 3B3FA81103 for ; Thu, 29 Sep 2022 10:22:33 +0000 (UTC) Received: by mail-ed1-x529.google.com with SMTP id z97so1320966ede.8 for ; Thu, 29 Sep 2022 03:22:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unikie.com; s=google; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc:subject:date; bh=fHVvrVksIvUMRiZiKtIO6Gj0mnL5riZCV9YBCWGioUU=; b=cUGXcm04bm9cBFHOYqfhhN2+CBqgbRQ6Ilrv8tERVuWE+GicIdLKZhBZUSz2ravjaD vNT/qc1d4A9sY0CZ+0ShFZkdyuGExh1w7fG4G89FVfNWs7voYJlKXWWQMnhR90ylauY+ rwk02kSxCVih8sN2B/fXIcjpBHu4714z3QdoANNInBObO5oHNqPVK4vqwTQBMsaQG+7q 9ft9ku8Cj+Tcv6aout9EmFMjUSfdE0rbFsviFGTmI+/FKYbBjFwjQ7VkgbutVsBqqTA4 uOsEI/Tt4QUUB3YfOzCqs3ApgdwEJ4ktWWz9zgFI4Bv0jBpiF3BuOpzLWoEEoUPxBDVx EEWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date; bh=fHVvrVksIvUMRiZiKtIO6Gj0mnL5riZCV9YBCWGioUU=; b=K0duQTxpGlHg35rIE/nXkcA09eE/cbAImNGCsMmC6wkZtkgctcSmUVuGIW3SvLjJGX h+qcvgyJBnBBGUwPYQcEiZJ0XZo/zR8qAqKyXOXzWCXbSGHLjEalZ9gb3WHwEaS86aFM TX79rvAPng5KhH+iqVsKEG9ycrngwham2OytR3T//3w7nkE4vswJLdTHbu0Wk1ou3XHR kX0516rRzMJcazuIwhnGaojFnmOaGKwvwIhUPTA2w1XKR/3+chW3LvnCFPTpOJJfoLuz +N00UZgr9f2Qtg1u3Fkvcx5jvzxVBHbGXrFGIFNj0RBY8Zx89aJpLBbIlgH4JHur6tGl nvTA== X-Gm-Message-State: ACrzQf3m0ZmgXl6l+vhwARKPi3eF47QDK/5dwNgCe2XgkVBc8nmfZYTz puvRwnXajiVg/am9McxFj5rq6+aFguKvM2nS X-Google-Smtp-Source: AMsMyM6+OSTLgwb01BKMGoYg3H20N4dq+Zh4/qrLQBK1X6RDcFZwAhCdr586bUt/6h9hgePuMFRg1Q== X-Received: by 2002:aa7:d397:0:b0:457:e4d5:c390 with SMTP id x23-20020aa7d397000000b00457e4d5c390mr2556280edq.7.1664446949975; Thu, 29 Sep 2022 03:22:29 -0700 (PDT) Received: from x220.qyliss.net (p200300ed673b8e010000000000000004.dip0.t-ipconnect.de. [2003:ed:673b:8e01::4]) by smtp.gmail.com with ESMTPSA id oq19-20020a170906cc9300b0073dd7e586f9sm3633732ejb.193.2022.09.29.03.22.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Sep 2022 03:22:29 -0700 (PDT) Received: by x220.qyliss.net (Postfix, from userid 1000) id 962EC52E; Thu, 29 Sep 2022 10:22:28 +0000 (UTC) From: Alyssa Ross To: Ivan Nikolaenko Subject: Re: [PATCH] scripts/make-gpt.sh: make GPT offset configurable In-Reply-To: <20220928140239.2380361-1-ivan.nikolaenko@unikie.com> References: <20220928140239.2380361-1-ivan.nikolaenko@unikie.com> Date: Thu, 29 Sep 2022 10:22:25 +0000 Message-ID: <87h70qqy3i.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Message-ID-Hash: ZTQUAHEMJF22X2HVBCQ42ENBSJ2UYS5E X-Message-ID-Hash: ZTQUAHEMJF22X2HVBCQ42ENBSJ2UYS5E X-MailFrom: alyssa.ross@unikie.com X-Mailman-Rule-Hits: header-match-devel.spectrum-os.org-0 X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-config-1 CC: devel@spectrum-os.org, Ville Ilvonen X-Mailman-Version: 3.3.5 Precedence: list List-Id: Patches and low-level development discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ivan Nikolaenko writes: > These changes can be used in an external configuration layer as > follows: > overlays =3D [ > (self: super: > { > gptOffset =3D 9437184; > }) > ]; > > Signed-off-by: Ivan Nikolaenko > --- > > This patch is not a solution but just a proposal about how things can be = done. > There is at least one another way of doing this (having our own make-gpt.= sh script), > but I thought that editing of the current one is better way. > > Also I don't know should we also consider other images and rootfs be fixe= d this way. > > img/live/Makefile | 3 ++- > img/live/default.nix | 1 + > scripts/make-gpt.sh | 22 ++++++++++++++++++++-- > 3 files changed, 23 insertions(+), 3 deletions(-) Hi Ivan, thanks for the proposal. I still think this is a cross-distribution problem looking for a cross-distribution solution, not something specific to Spectrum. Other distributions providing vendor-neutral ARM images (e.g. Fedora, NixOS) have exactly the same problem. Solving it as part of Spectrum doesn't help them solve the same problem, and I think it's critically important for the long term maintainability of Spectrum that we be wary of implementing custom solutions for cross-distro problems, even when they start out pretty small like this one. So I think the best way forward here would be to have a small program that lives outside of Spectrum. It would take a firmware image, a generic ARM OS GPT image, and a configurable offset (or, if more board-specific knowledge ends up being required, some sort of board configuration file). It would then create a new GPT image, install the firmware appropriately, and then copy the partitions from the generic image, offset appropriately. [[ To be honest, I'm surprised this program doesn't exist already considering its limited scope, but I haven't seen anything like it. I suspect part of the reason is that most distros have still not caught up with the idea of installing an image, rather than doing a bespoke imperative installation, but that's definitely the direction things are moving in =E2=80=94 e.g. systemd is doing lots of work to support image-bas= ed installs. [1] ]] This approach would avoid introducing additional complexity into Spectrum, _and_ would work for other operating systems too. It could be _the_ way to produce firmware+OS images for people who need to do that, reducing the amount of effort required to be spent on this problem across the ecosystem by users, integrators, and distributors. And the program should be pretty small and easy to write. It wouldn't be duplicating Spectrum's make-gpt.sh particularly, because the two would be focused on different tasks. make-gpt.sh takes some filesystem images and produces a GPT image from them, whereas this program would take an existing GPT and add in the platform-specific firmware. And it wouldn't need to be duplicated for every board somebody wanted to build images for, because the same program should be flexible enough to work for all boards that work this way. Some background here that's important to remember is that this is not something most end users would be expected to need to do. The ideal way of installing Spectrum on ARM, for an end user, would be to install a firmware distribution on separate storage (or if their board comes with firmware pre-installed that supports standards-based boot, they don't even have to do that!), and then install Spectrum on main storage. The firmware and OS could be updated and maintained independently*, and so Spectrum doesn't have to also be an ARM firmware distribution =E2=80=94 we = can leave that to other capable projects. Combined firmware+OS images are therefore mainly useful to two groups: end users using boards that don't have separate storage for firmware (or for which there is no firmware available that supports booting from main storage), or organisations who want to roll a system out across lots of devices, for whom it's more convenient to only have a single image on a single type of storage to worry about. If there's some reason this wouldn't work, and we absolutely *need* changes in Spectrum to accomodate firmware in the images we build, I'm willing to reconsider, but with my current knowledge, it looks to me like it could be solved distribution-independently, outside of Spectrum, and that doing so would make things better for everybody trying to create vendor-neutral ARM OSes. Previous discussion on this topic: - https://spectrum-os.org/lists/archives/spectrum-devel/20220828164957.p37= 43hvijjrkm66b@x220.qyliss.net/ - https://spectrum-os.org/lists/archives/spectrum-devel/0ead7a33-4c9b-6eab= -26df-5bbe02fc4649@unikie.com/ [[ As a side note, EBBR recommends using a protective partition rather than just offseting the GPT, to make the firmware area of the image more visible. [1] ]] * I'd really like fwupd support in Spectrum. [1]: https://arm-software.github.io/ebbr/index.html#gpt-partitioning --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEH9wgcxqlHM/ARR3h+dvtSFmyccAFAmM1ceMACgkQ+dvtSFmy ccBnsQ//bBtMAmJxwOJ1fkRC/yGQ4WXVLGdbR9xAXkVDfijFkHUHzL45KsUaiPkB +eraW6hwSf0Wt49tX0lAasnEDhi3gNdUkEVDU8986qhyw/sYbuBSC3gkTR7l3pYd vp+xv1dlo2KPnIkLh2wbjM8uMGjhRy0BLjkeoZFHslCvXS8bkXGW6uYM5fAmhT1z ZGFmgB13K6AXGAQ2CC8qHUIJ6JXeP+yDT8u4th1AwiVv7DIGulSJYZM4XT1eoXyT 09/6A0a0LUFKmMRf+LvsV2AFx4OowSvKbphNPfuY90vjtJA5v4x3ex9dujI6p6XQ ixY26obcnuhzo2RmGR6zupkgjgt2i+V9g5J/p2Stbmw8QY6EOPtxBx1PxYCxkwyZ 5MTuJSH3armETpqTj5IW47dK7J+5X90BpAHEExEzjII1/5OKp9xuqVHGdMWxxkni mUT53ym/LNkkOeKlHu/j9atRFdSoFWBlpGTpu7qyUwmoEO49pniCfz1VmsmOw+H8 tNFYi6UFJFgSGxEQq/uhnmxvE/z/HEA7YensMlE9c9C8Dmb9ubtaJxLo2ObDk7kb WJkJ7Z29cgcwiMFn62d1rDj8uVeiaOSyx03/D9FrUGdK3YtPGODfaNronc4+ocSv uUR7sQqUj3rcxUmedbRLDkWYv3yhoxFB38I+DRupZ5FQTSy3bEU= =2nka -----END PGP SIGNATURE----- --=-=-=--