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 C934762321; Thu, 15 Sep 2022 14:48:30 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 496) id 95116622FC; Thu, 15 Sep 2022 14:48:28 +0000 (UTC) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by atuin.qyliss.net (Postfix) with ESMTPS id B4EC7622FA for ; Thu, 15 Sep 2022 14:48:24 +0000 (UTC) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 690503200A36; Thu, 15 Sep 2022 10:48:22 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 15 Sep 2022 10:48:22 -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=1663253301; x=1663339701; bh=kXQbj1TP1h /AmbJ+P7A/tU9DIghYHKLRkkYEdqovmvY=; b=Iqjsz0gE7+A3yljt72IO4ELcQl wkn4f7jFt42X9aYZ+Mb4tTuXi+YAC1PBCZfnE3UEib1mzWyutlmXygyIF/Z7xyXc HDiIrhctkgZrqIWmEqqt/g2kTRWh35CmHbxxRrJ+M/uqhPUZQz7XVAOZxwwhLrHr OTsGWE1AbEbDJuI7f70EmUGEANAY87e5dqR9epSw2KRQEfD+IL2GYSLfbalKdduW zVXZTYkfCxquqv5aznRuVCzoog1kL8on6Ue0fqXDdQ8Gde+rIkNfHVr6B6EaakYl 8Va+nOcX/OsT+PqYTVf+B5FqqvRCDuKodZWaZWcKlo3QdZnpixgxaVUUUfhQ== 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=1663253301; x=1663339701; bh=kXQbj1TP1h/AmbJ+P7A/tU9DIghY HKLRkkYEdqovmvY=; b=xZ7F1R1ku+TnsgEi5Vl2tb6tQXiTCxNS244HsnmekiiA 5bXs1qjlyikLgyE2upYPGFgz1lUf2DyYcZrVgOmq9bkJ05yRzx9Vr6KX5sB4Esvj 4YKIzR5UAlSuYQ5CXNcKZ1ilMRK3uXtvkmaawOejZjCYyUwQH6nz4mwLPKoMXsLs vQbklYZQOyVF3EnR0+HRXg1GFOdZbh4rG2UyZHoiMNKYtc3DB72ZBK1gpdZj2+JB k2vqaEi4lZS09S+iSkBSuc23guLaZkxr1zNMfpXaVe03n7XkTqroDiTuvPD4anUZ gjxOQGIm+01dyDq5AvUXOYdjVCkWpFs5TphI6oJ9Gw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfedukedgkedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne goufhushhpvggtthffohhmrghinhculdegledmnecujfgurhephffvvefujghffffkgggt sehgtderredttdejnecuhfhrohhmpeetlhihshhsrgcutfhoshhsuceohhhisegrlhihsh hsrgdrihhsqeenucggtffrrghtthgvrhhnpeevuddvhedvveegffejgfeivdfhtdevhefh vedvhfejieellefgjefghfelhfdvffenucffohhmrghinhepghhithhhuhgsrdhiohenuc evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehhihesrghl hihsshgrrdhish X-ME-Proxy: Feedback-ID: i12284293:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 15 Sep 2022 10:48:21 -0400 (EDT) Received: by x220.qyliss.net (Postfix, from userid 1000) id 841A94B4; Thu, 15 Sep 2022 14:48:19 +0000 (UTC) From: Alyssa Ross To: Ville Ilvonen , =?utf-8?Q?Jos=C3=A9?= Pekkarinen Subject: Integrating Spectrum and platform firmware In-Reply-To: <3b5ed1a7-571f-b653-3fb1-f388638b94a5@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> <87v8povisw.fsf@alyssa.is> <3b5ed1a7-571f-b653-3fb1-f388638b94a5@unikie.com> Date: Thu, 15 Sep 2022 14:47:58 +0000 Message-ID: <87sfksvgm9.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Message-ID-Hash: 4PPE7XB2S22YNABIMPW2XOUA673ZTCLD X-Message-ID-Hash: 4PPE7XB2S22YNABIMPW2XOUA673ZTCLD 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 17:00, Alyssa Ross wrote: >> Ville Ilvonen writes: >>=20 >>> On 9/15/22 16:22, Alyssa Ross wrote: >>>> Jos=C3=A9 Pekkarinen writes: >>>> >>>>> 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. >>>> >>>> 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 a= nd >>>> 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 = separate >>>> components. (This isn't an approach unique to Spectrum =E2=80=94 Fedo= ra is >>>> doing something similar.) >>>> >>>> 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: >>>> >>>> let >>>> spectrum =3D import { >>>> # config could either be loaded using the standard mecha= nism >>>> # or inlined here. >>>> }; >>>> # It would also be possible to import individual component= s of >>>> # Spectrum and assemble them manually if even greater >>>> # flexibility was required, but I doubt that would be comm= on. >>>> >>>> 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. >>>> >>>> uboot =3D pkgs.ubootRockPro64; >>>> in >>>> >>>> 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. >>>> '' >>>> >>>> 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 >>> picture it's hard to see early boot firmware would have *nothing* to do >>> 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 >>> 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 >>> 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 >>> should be acknowledged. >>> Documenting Spectrum reqs to boot itself with example determines how >>> easily people can make their devices run Spectrum. >>=20 >> 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. >>=20 >> 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? > > Example with some device(s) defines the usefulness - to get Spectrum=20 > running on that device. Documentation with link to EBBR could be=20 > additional reading. The last practical question is where the device=20 > specific implementations of ebbr (e.g. u-boot) are stored. I'm reading=20 > out of Spectrum tree but the "glue" nix (your example of uboot+spectrum)= =20 > would be needed somewhere. Could that be in Spectrum tree to be useful=20 > for Spectrum users? Well, there are a couple of things here: The first is that the glue Nix is only needed if you want to have the firmware and the Spectrum partitions on the same image. This is something that's supported, but recommended against (see the Firmware Storage section of the EBBR spec [1] =E2=80=94 that also mirrors the recommendations I've heard from both the Tow-Boot and Fedora ARM maintainers.) That's not to say it's not a legitimate thing to do =E2=80=94 I understand = that it's nice to be able to just download a single image and have everything work, especially when Spectrum is one part of a bigger vision =E2=80=94 so = it's not like it's unsupported, but the happy path that the community seems to be heading towards (and therefore the one that I'd expect to recommend to end users that are coming directly to Spectrum) is that users should first install platform firmware if required (perhaps using a distribution like Tow-Boot) onto dedicated storage as part of setting up their device, and then install whatever EBBR-compliant distro they want onto main storage. In the best case, where the hardware is well supported by mainline Linux, they get a working device without needing to track down or build a special image. If they're not quite so lucky, they still don't need to worry about the specifics of combining firmware and OS into a single image, and neither do we. The second thing is that the Nix glue is board specific. It has to know how to build U-Boot, and how to install it in the image at the correct offset. But it isn't really specific to Spectrum at all. The only interaction it needs to have with Spectrum is copying its partitions into the right place, and the only implementation details of Spectrum it needs to depend on are that Spectrum comes as a GPT image, and that it doesn't mind if the offset of its partitions changes. So if you wanted a reusable way to combine an OS image and a platform fimware image into a single image with Nix, I think that would make more sense as a seperate project outside of Spectrum, since it would also work with almost any other OS. I know there's been talk among NixOS aarch64 users/developers about re-doing how NixOS builds SD card images, and this feels very relevant to that conversation. This could, for example, be part of a future, improved version of nixos-hardware, and as long as it didn't depend on any NixOS specifics, it could work whether the OS being installed is NixOS, Spectrum, Fedora, or anything else, as long as it implements EBBR. [1]: https://arm-software.github.io/ebbr/index.html#firmware-storage --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEH9wgcxqlHM/ARR3h+dvtSFmyccAFAmMjOyMACgkQ+dvtSFmy ccAAexAAllhWQhcY+x0qyUBBBClLddbzzVHokKF0/jljiPquBZPFmk1sf6QzSdic oSnRwTYQDPn7fUJBc8ZBEG0D9/FFLCdWsBRMM+n6wBFy0JXC6vnu2NGRHZ8i2HiJ dxgaaQUvPxpSlfX9qbl0af9X/e2XmHZYlXNqdIbg196Xs++mSJ+RgfUA0Nubbjou o/LkRjOsEegxurn3vXJyxaOjftneG7iGkre5H59992OU9O+osLfdmmgDx30/hz03 qiIQupPuywNKr8oKI0vsJrbaHzfTvGokg5rf3WM9r2U6dguaQZWUci+2yvnrAWA6 r8oW47VdrKXSxtsAgLnrinPTDoK7Gd4ozT6CmhNnylMmNOMEgohnvIQykw2JaQ1Q KBFXU/Wqs2g90PU39J3ux2yk5BqP/4jfHsequlyg1EpR4P8DAgzzUOEy3k9l8O4G 7WAlIIfNiLjP85veHecjyuqN+e5j7zqgw0wesreJdwUQPBaROhN+tsSad1HSYAoK z7Q73JA3qPDKksQyJJJTPHZMz3LMWf73Rr8vjxvrUE9HZI2x6zoloc5LZCDwvXhd cFn8vV2kzKV4Wwim5rY86m2RQv4ulMPMoFs3jJCnZ9M5Yq+ny7fiu7zhHGJ0vByV uM2pljez7E2fObUITG8gjm5BiGgVNR4aKqm8Of+mzo/dJa60iMU= =D1aQ -----END PGP SIGNATURE----- --=-=-=--