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.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS, T_SCC_BODY_TEXT_LINE 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 F233E61DE8; Thu, 15 Sep 2022 14:00:59 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 496) id 96CB561E3A; Thu, 15 Sep 2022 14:00:58 +0000 (UTC) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by atuin.qyliss.net (Postfix) with ESMTPS id 622BA61DDC for ; Thu, 15 Sep 2022 14:00:56 +0000 (UTC) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 5EE433200AC0; Thu, 15 Sep 2022 10:00:54 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Thu, 15 Sep 2022 10:00:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alyssa.is; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; t=1663250453; x=1663336853; bh=3X/5lIeSP1 JslpyR+5mrcfSLkcGQ7fLLAsqHk8o+Lj8=; b=SSh7l3dDXEjEZxr414cKQPBBo5 u3CaiYBdutMEwJiOtfMrvx3VcVfMcrV5QrD3WxSOrWpnHWEJ6Cg0ScKdhabG7ylx J5/WVaLQMkqIlDiaP+Na7G1ZjtPQdW2ewqxTZGA+H1D6Cc1CvUBal/h5HCTBmGOy SUFvFmKgRfRBzmWOpKFnDUWirZQtZekaj8ZbZVCErgzc6TkVHmaSoZ5vt9F2DatA 2kg5ueao+hX5VpvaQO9mhnsHotUbl8YDiMsLGELuyVozcCP/mBqohZu/eCCl12QU rle5zbFBKSdDQ0Mh9+c+QtrwRo2L6e6xjCZvl2MiOiZt6juaDDL1L7Mknk+w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1663250453; x=1663336853; bh=3X/5lIeSP1JslpyR+5mrcfSLkcGQ 7fLLAsqHk8o+Lj8=; b=uXGoOWgb2yS3VHieyLRUGsloawlNxxKJPInmRvkU+8Gj saGyCSPtUSgluA5Rq2WJzChBBkjo4P6qT1nAGRdcSi6Kfra2WAgmCRNrE7aNKWbX Kuld5gj8YCbIrdp9j/CQo2vRKA8ANliFiqB/tb4XkO7TPdbqKwd5mflhmxB/cmJ3 QUQB3cvEEqxPVqQBwbUB8F68oapeTFS9Ex6O1YwXC8i39bgeDZCdTHVF1s7sN7sZ JzuVxku/GoOdepWHxdndaT7QWkpWjjLM92KFHGqBKiHTdAEaDQjXsBh7e08okGCi onXiwF2diOYqeHdG6w6aMdhd1hRO2GpWRkWBAVzzfQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfedukedgjedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefujghffffkgggtsehgtderredttdejnecuhfhrohhmpeetlhihshhs rgcutfhoshhsuceohhhisegrlhihshhsrgdrihhsqeenucggtffrrghtthgvrhhnpeethe evudfgjefghefhieejudelkeeljeegvdekueeuhffhgedvveefteevgeetieenucevlhhu shhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehhihesrghlhihssh grrdhish X-ME-Proxy: Feedback-ID: i12284293:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 15 Sep 2022 10:00:52 -0400 (EDT) Received: by x220.qyliss.net (Postfix, from userid 1000) id 5BDB7506; Thu, 15 Sep 2022 14:00:51 +0000 (UTC) From: Alyssa Ross To: Ville Ilvonen , =?utf-8?Q?Jos=C3=A9?= Pekkarinen Subject: Re: [PATCH] Add image configuration option In-Reply-To: <302c49ae-fef5-2e36-f573-88b00f5af9cc@unikie.com> References: <20220915073515.47855-1-jose.pekkarinen@unikie.com> <87mtb1xd38.fsf@alyssa.is> <87h718yiuk.fsf@alyssa.is> <87zgf0vklc.fsf@alyssa.is> <302c49ae-fef5-2e36-f573-88b00f5af9cc@unikie.com> Date: Thu, 15 Sep 2022 14:00:47 +0000 Message-ID: <87v8povisw.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Message-ID-Hash: PSAINPO6PCX7RJOAGZFIC7MOI57GHIZM X-Message-ID-Hash: PSAINPO6PCX7RJOAGZFIC7MOI57GHIZM X-MailFrom: hi@alyssa.is X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-config-1; header-match-devel.spectrum-os.org-0; header-match-devel.spectrum-os.org-1; header-match-devel.spectrum-os.org-2; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: devel@spectrum-os.org 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 Ville Ilvonen writes: > On 9/15/22 16:22, Alyssa Ross wrote: >> Jos=C3=A9 Pekkarinen writes: >>=20 >>> On Thu, Sep 15, 2022 at 2:31 PM Alyssa Ross wrote: >>> >>>> [...] >>>> Okay, thanks for the explanation. I think we can group some of these >>>> together: >>>> >>>> =E2=80=A2 Stuff that's already Nixpkgs configuration options or can = be >>>> expressed through an overlay. Whether to cross compile, what >>>> architecture to build for, whether to use a vendor kernel, etc. T= his >>>> can already be handled through the existing configuration mechanis= m. >>>> >>>> =E2=80=A2 VM customisation, including extra VMs, disabling Wayland, = etc. In my >>>> mind there are still some open questions around how this should be >>>> implemented exactly, but this is definitely something that needs to >>>> be more configurable. >>>> >>>> =E2=80=A2 Whether to install extra stuff on the host system. This c= overs >>>> things like debugging symbols and tools. >>>> >>>> Does that sound right to you? Are there more that you can think of? >>>> I'd like to understand the requirements here better, to help think abo= ut >>>> what sort of configuration mechanisms might be required. >>> >>> This is a good summary, currently I can think of a coupel of more, >>> which is a mechanism to provide upstream project configuration artifacts >>> when nix allow to bypass their automated configs, for example, a kernel >>> config when using manual config kernel nix package, a bit more unclear >>> is how to provide upstream configs when nix is not flexible enough. >>=20 >> You mean you'd like to manually provide a Kconfig file, rathen than >> using Nixpkgs' (not very good) structured config mechanism, right? >> That should be possible with an overlay, but maybe some documentation >> with an example would be a good idea? >>=20 >>> A mechanism to generate a full image from the nix generated artifacts >>> putting together kernel, initrd, rootfs and ext partition so that the >>> full image can be flashed in a sdcard of choice and use it. This would >>> require to be configurable so that you can modify the partition table >>> to suit vendor needs. >>=20 >> We've had some discussion about that already on the list and on IRC. My >> current view is that early boot firmware (U-Boot etc.) doesn't really >> have anything to do with Spectrum. They both run at different times, >> and they communicate over a standard interface (EBBR [1]), so the >> specifics of the firmware aren't really in scope for Spectrum itself and >> belong elsewhere. It doesn't make sense for Spectrum to be installing >> U-Boot any more than it makes sense for U-Boot to be installing >> Spectrum, or for Linux to be installing U-Boot =E2=80=94 they are two se= parate >> components. (This isn't an approach unique to Spectrum =E2=80=94 Fedora= is >> doing something similar.) >>=20 >> It can make sense to make an image that is a combination of U-Boot and >> Spectrum, but that process should be part of an integration between the >> two that exists one layer up, rather than part of either project. For >> example, you could do something like this: >>=20 >> let >> spectrum =3D import { >> # config could either be loaded using the standard mechanism >> # or inlined here. >> }; >> # It would also be possible to import individual components of >> # Spectrum and assemble them manually if even greater >> # flexibility was required, but I doubt that would be common. >>=20 >> inherit (spectrum) pkgs; >> # I don't think a pkgs attribute currently exists on the >> # spectrum-live.img derivation, but it might make sense to add >> # for this sort of use case. >>=20 >> uboot =3D pkgs.ubootRockPro64; >> in >>=20 >> pkgs.runCommand "uboot+spectrum.img" {} '' >> # Use sfdisk (or maybe there's some better tool) >> # to create a partition table, and copy the U-boot image >> # and the Spectrum images into place. >> # >> # Spectrum is designed to accomodate this by not expecting >> # any of its partitions to be at any particular location >> # on disk. >> '' >>=20 >> Maybe this is another case where documentation and a worked example >> would help? > > Documented example case would help. It's good to scope but in the big=20 > picture it's hard to see early boot firmware would have *nothing* to do=20 > with Spectrum. That's not the case with x86_64 either. > > Let me clarify. > On x86 traditionally people can't change early bootloading. > -> Spectrum assumes UEFI OS loading because UEFI is just there and can't= =20 > be changed > On arm traditionally people can and will change early bootloading. > -> Spectrum has assumed UEFI but UEFI is just not there. It's must be=20 > put there - typically on device SD card or eMMC image. > On riscv assumption is more like on arm. > > So the mechanism is essential, even when not *provided* by Spectrum it=20 > should be acknowledged. > Documenting Spectrum reqs to boot itself with example determines how=20 > easily people can make their devices run Spectrum. Agreed, that's why I was pleased to discover the EBBR spec recently, which defines exactly this: "an interface between platform firmware and an operating system that is suitable for embedded platforms", designed for U-Boot with UEFI like we were already targeting. So we can say "Spectrum aims to implement EBBR on aarch64" (and on RISC-V when we get there if that's the right thing to do), and that way there's a lovely long document that explains what is Spectrum's responsibility to do, and what is the firmware's responsibility to do. And when something goes wrong, we'll be able to refer to the spec to determine whether it's a problem with Spectrum, or with the platform firmware. And of course we can have some documentation that introduces EBBR to an audience that's not necessarily familiar with it, and provides an example of how an EBBR system comprising both Spectrum and U-Boot might be put together, expanding on what I included as the example in my previous message. That should be more than enough to acknowledge the mechanism, right? --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEH9wgcxqlHM/ARR3h+dvtSFmyccAFAmMjMBEACgkQ+dvtSFmy ccCLYA//TjH7cor1kno9fXZG994eurFo241rUd2psVWcAedTbzEr4lzTEsjlPKPG spvZryY0gGz8RGvAUIsJJ7SIb5Of3SO57ZAtK43FrP4+NRZf2+1YfTsFEHc10rv2 oTu3oGyozyX+yX4cBJbloTFYnCAj+9fFmR8K7J8nyjYSYLQuH2YgEmF42o4WtlV2 pEntSbEj61ck0NvhEaYUOVtnXBJz2jWNduULOIOqj0tCYojGZw2gT0dcLrMigunE FvwvrHQmZwneCHHMSmd0T+3X9p4yEaiT2YNd++nweLtik1qIngmWM9PY1sRGzK28 WQBIQRqFyDqZrDsLv22pjUN6vBKaEpaLzoSxHaGRrokNY3uVetsyhHh1yPGHu+bA gmHoOjHKryDTUnjq1DMxeVP7G+ZwkH6RhL2gHPS3RKW66IzotE+XFQUOGQAh9a3w UVNqORTfN3tswfmIs0MypQt7w+YMZfmuS/RtFFbzjzNyjdM/xp77EguupH2/O02k 61I2UhAp698i6zgzsS9RUKIQLPGdhRyJ0A4mIDEc7KwEhAlt+zCq333BacJQmDAi DRooaBgUeXb9DIKeBq/qtpR+oLa/I3W6Le7OdaCK1hqgLaVimJU2WZPU91Y8HnHn pOjVBuvqiiX5dGd7MKX8gkpH+K82DjJRYUQJu3PxKPDWgjMnd8I= =eY48 -----END PGP SIGNATURE----- --=-=-=--