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=-2.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,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 0FD7C62031; Thu, 15 Sep 2022 14:09:50 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 496) id 36E5A61F7F; Thu, 15 Sep 2022 14:09:48 +0000 (UTC) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) by atuin.qyliss.net (Postfix) with ESMTPS id B916461F8F for ; Thu, 15 Sep 2022 14:09:44 +0000 (UTC) Received: by mail-lf1-x130.google.com with SMTP id j16so3527131lfg.1 for ; Thu, 15 Sep 2022 07:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unikie.com; s=google; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date; bh=iCEyxbq7F2I2pFM76qJOz4KTY3u3BAc+GW7VAcI/oLo=; b=Sam31kQc4dfKpeecbq/4sk5MlvYVQnlYpWbGD1a0toX4Q6z9vPeBedNSS/VNL09PQb f6wOkTiE1OAD4YfqQS8U9jVX1wAfBf6xSwxZPqIqfhPOiEk5zvADX0OIn3lBk+CGeICJ da38LdU6UCvYW4SgUahU7Ibp0donUl/hMEKPIYjdHC794V7hOh7M6jPUrGI1E9e2+sLr WHqHUJYF8rynL+3ZIyCn7ZMEbHfI5jm6OItyzzTao6702w3at+/cT6MRQsXfihbFdPZU yNcbJve9Znzfi61lsGDVOpVS6NV1yao8cYpdKT9nIfYBJCxg0iT19n7aAvNg2hiu7Hc9 uKwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date; bh=iCEyxbq7F2I2pFM76qJOz4KTY3u3BAc+GW7VAcI/oLo=; b=fAwQqL19S8noUmvcBs+I1iuLLaXy7puXBtpcxIKA81yWEqWC+9cSLGmTKSi5zHB/Y/ RdxCKsulvbmM1tMv4lJ3mDgEFg7kApbCeuskNijfXCv1+z+7MNSoq42fD1CO5VujsALU /4Z0bIRjQpNcHEbH3n44OpqfVUu5huLOy7VGVLc4QVDVimX4hpBOUau/+CJbDTD3UoGl gxDla4PWX26pAp3WAA2usyH+ZUqthpZYvwhzpQo527jWIZQ84NhWEhtx+8YBby3yzdYB uu5FYPupz/m/5ylJumL1j0Hv721J/bkSvzfeLwC2vohTOa6jeilEU7BT9WPOGmWdBSKj Bvig== X-Gm-Message-State: ACrzQf0RD08O5Lzv+T0c2BzDswbvsmoe2hJhf3Uns7TGqTVnt2R77zAi EnbNjWtP7TxxQxn02yok3IyjI6R93KWD7qCi X-Google-Smtp-Source: AMsMyM5adu6Ot3U6+6UNfRZkHzSNORYm1EHYJQVvNJWjGODBqt63qvobgPqVjfvU+RQsiysF27ZFhw== X-Received: by 2002:a19:434f:0:b0:49c:fe43:e1e8 with SMTP id m15-20020a19434f000000b0049cfe43e1e8mr36693lfj.210.1663250983693; Thu, 15 Sep 2022 07:09:43 -0700 (PDT) Received: from [192.168.1.26] (mobile-access-6df011-52.dhcp.inet.fi. [109.240.17.52]) by smtp.gmail.com with ESMTPSA id f14-20020ac25cce000000b004979dc8038esm2986792lfq.201.2022.09.15.07.09.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Sep 2022 07:09:43 -0700 (PDT) Message-ID: <3b5ed1a7-571f-b653-3fb1-f388638b94a5@unikie.com> Date: Thu, 15 Sep 2022 17:09:42 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.0 Subject: Re: [PATCH] Add image configuration option Content-Language: en-US To: Alyssa Ross , =?UTF-8?Q?Jos=c3=a9_Pekkarinen?= 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> From: Ville Ilvonen In-Reply-To: <87v8povisw.fsf@alyssa.is> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Message-ID-Hash: NMINHIMDIKTNVTTTQEQNYLXNGT22HZ2I X-Message-ID-Hash: NMINHIMDIKTNVTTTQEQNYLXNGT22HZ2I X-MailFrom: ville.ilvonen@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 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: On 9/15/22 17:00, Alyssa Ross wrote: > Ville Ilvonen writes: > >> On 9/15/22 16:22, Alyssa Ross wrote: >>> José Pekkarinen writes: >>> >>>> 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: >>>>> >>>>> • 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. This >>>>> can already be handled through the existing configuration mechanism. >>>>> >>>>> • 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. >>>>> >>>>> • Whether to install extra stuff on the host system. This covers >>>>> 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 about >>>>> 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. >>> >>> 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? >>> >>>> 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 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 — they are two separate >>> components. (This isn't an approach unique to Spectrum — Fedora 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 = 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. >>> >>> 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 = 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. > > 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? Example with some device(s) defines the usefulness - to get Spectrum running on that device. Documentation with link to EBBR could be additional reading. The last practical question is where the device specific implementations of ebbr (e.g. u-boot) are stored. I'm reading out of Spectrum tree but the "glue" nix (your example of uboot+spectrum) would be needed somewhere. Could that be in Spectrum tree to be useful for Spectrum users? -Ville