Re: [PATCH] Add image configuration option

[Ville Ilvonen <ville.ilvonen@unikie.com>]

On 9/15/22 17:00, Alyssa Ross wrote:
> Ville Ilvonen <ville.ilvonen@unikie.com> writes:
> 
>> On 9/15/22 16:22, Alyssa Ross wrote:
>>> José Pekkarinen <jose.pekkarinen@unikie.com> writes:
>>>
>>>> On Thu, Sep 15, 2022 at 2:31 PM Alyssa Ross <hi@alyssa.is> 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 <spectrum/img/live> {
>>>               # 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