[PATCH 00/31] passage: Define a standard for firmware data flow

[François Ozog]

On Fri, 5 Nov 2021 at 03:02, Simon Glass <sjg at chromium.org> wrote:

> Hi François,
>
> On Tue, 2 Nov 2021 at 10:03, François Ozog <francois.ozog at linaro.org>
> wrote:
> >
> > Hi Simon,
> >
> > On Tue, 2 Nov 2021 at 15:59, Simon Glass <sjg at chromium.org> wrote:
> >>
> >> Hi François,
> >>
> >> On Mon, 1 Nov 2021 at 02:53, François Ozog <francois.ozog at linaro.org>
> wrote:
> >> >
> >> > Hi Simon,
> >> >
> >> > this seems a great endeavor. I'd like to better understand the scope
> of it.
> >> >
> >> > Is it to be used as part of what could become a U-Boot entry ABI
> scheme? By that I mean giving some fixed aspects
> >> > to U-Boot entry while letting boards to have flexibility (say for
> instance that the first 5 architecture ABI
> >> > parameter registers are reserved for U-Boot), and the Passage is
> about specifying either those reserved registers
> >> > or one of them?
> >>
> >> The goal is to provide a standard entry scheme for all firmware
> >> binaries. Whether it achieves that (or can with some mods) is up for
> >> discussion.
> >>
> > If you say
> > a) define a U-Boot entry ABI and providing a firmware-to-firmware
> information passing facility which would be part of all firmware ABIs (as
> the projects decide to define their own ABI) it looks good.
> > but If you say
>
> It is an ABI to be adopted by U-Boot but also other firmware. For
> example, if TF-A calls U-Boot it should use standard passage. If
> U-Boot calls TF-A or Optee it should use standard passage.
>
> > b) define a standard entry scheme (register map, processor state, MMU
> state, SMMU state, GIC state...) that does not look realistic.
>
> No I don't mean that. This data structure could be used in any state,
> so long as the two registers are set correctly.
>
> > I think you mean a) but just want to be sure.
>
> Yes I think so.
>
> >>
> >> Re the registers, do you think we need 5?
> >>
>
> I don't :-)
>
> >> >
> >> > Thinking entry ABI, here is what I observed on Arm:
> >> >
> >> > Linux has two entry ABIs:
> >> > - plain: x0 = dtb;
> >> >           command line = dtb:/chosen/bootargs; initrd =
> dtb:/chosen/linux,initrd-*
> >> > - EFI: x0=handle, x1=systemtable, x30=return address;
> >> >            dtb = EFI_UUID config table; initrd =
> efi:<loadfile2(INITRD vendor media UUID); command line = efi:
> image_protocol::load_options
> >> >
> >> > U-Boot (proper) has plenty of schemes:
> >> > - dtb is passed as either x0, x1, fixed memory area (Qemu which is
> bad in itself), or other registers
> >> > - additional information passing: board specific register scheme, SMC
> calls
> >> > - U-Boot for RPI boards implement a Linux shaped entry ABI to be
> launched by Videocore firmware
> >> >
> >> > Based on all the above, I would tend to think that RPI scheme is a
> good idea but also
> >> > shall not prevent additional schemes for the boards.
> >>
> >> I was not actually considering Linux since I believe/assume its entry
> >> scheme is fixed and not up for discussion.
> >>
> >> I also did not think about the EFI case. As I understand it we cannot
> >> touch it as it is used by UEFI today. Maybe it is even in the
> >> standard?
> >
> > It is in the spec and we are making it evolve, or its understanding
> evolve (jurisprudence) for instance on initrd standard handling.
>
> Well perhaps we could merge it with standard passage. But EFI is not
> going to want to use a bloblist, it will want to use a HOB.
>
> >>
> >>
> >> Really I am hoping we can start afresh...?
> >>
> >> >
> >> > What about a U-Boot Arm entry ABI like:
> >> > - plain: x0=dtb, x1=<Passage defined>, x2-x5 = <reserved>, other
> registers are per platform, SMC calls allowed too
> >>
> >> Hmm we don't actually need the dtb as it is available in the bloblist.
> >
> > If you don't have x0=dtb, then you will not be able to use U-Boot on
> RPI4.
> > Unless you want to redo everything the RPI firmware is doing.
>
> That's right, RPI cannot support standard passage. It is not
> open-source firmware so it isn't really relevant to this discussion.
> It will just do what it does and have limited functionality, with
> work-arounds to deal with the pain, as one might expect.
>
> So you are seeing two "all-or-nothing" options:
<specific>: U-Boot entry is board specific as it is today
<purepassage>: A new form where the only parameter is a head of bloblist,
one of those blobs contain a DT
 You propose to mandate a DT for all boards make sense in that environment.
For RPI4, you just ignore everything the prior boot loader does because it
is not <passage> compliant.

This reinforces my opposition to the mandatory DT proposal.

a third option is I think way more attractive:
<optpassage>: shaped after the architecture Linux entry (ie. first
parameter is dtb) [+ passage head (i.e. second parameter is pointer to
passage head)]

This way, you make U-Boot entry clean in RPI4, Apple M1, Qemu, SystemReady
contexts
and get a well deserved standardized information passing between prior
loaders and U-Boot.

The three options are possible though, you could select a U-Boot entry
CONFIG option for:
<specific>
<optpassage>
<purepassage>

But despite it would be technically feasible, I don't think it is goes in
the right direction.

>>
> >> But I added an offset to it as a convenience.
> >>
> >> > - EFI: x0=handle, x1=systemtable, x30=return address;  (when U-Boot
> is launched as an EFI app)
> >> >        dtb = EFI_UUID config table, + Passage = Passage UUID config
> table
> >>
> >> I don't understand the last line. Where is the passage info /
> >> bloblist? Do you mean it goes in the HOB list with a UUID? I suppose
> >> that is the most EFI-compatible way.
> >
> > The Passage config table  could just contain the "head" of the
> bloblist/Passage information.
>
> If UEFI wants to deal with standard passage, that is...
>
> >>
> >>
> >> What do you think about the idea of using an offset into the bloblist
> >> for the dtb?
> >
> > It is possible but as I said, failing to mimic Linux entry ABI would
> miss the opportunity to just boot without changes on RPI4.
>
> See above. Broadcom could look at open-sourcing their bootloader if they
> wish.
>
> >>
> >> Also, can we make the standard passage ABI a build-time
> >> option, so it is deterministic?
> >>
> > Looks good. I would look into stating that for SystemReady we would
> advise to use that option and make it standard for Trusted Substrate
> (Linaro recipes that we upstreaming to make SystemReady compliance easy and
> consistent across platforms).
>
> OK. I mean that if the option is enabled, then standard passage must
> be provided / emitted or things won't work. If the option is disabled,
> then standard passage is not used. In other words, we are looking for
> magic values in registers, etc, just enabling/disabling it at
> build-time.
>
> >>
> >> >
> >> > We could further leverage Passage to pass Operating Systems
> parameters that could be removed from device tree (migration of /chosen to
> Passage). Memory inventory would still be in DT but allocations for CMA or
> GPUs would be in Passage. This idea is to reach a point where  device tree
> is a "pristine" hardware description.
> >>
> >> I'm worried about this becoming a substitute for devicetree. Really my
> >> intent is to provide a way to pass simple info, whereas what you talk
> >> about there seems like something that should be DT, just that it might
> >> need suitable bindings.
> >>
> > I see your point and I agree It should not be a substitute.
> > here is an expanded version of what I had in mind when I wrote those
> lines.
> > cma, initrd and other Linux kernel parameters can be conveyed either
> through command line or DT.
> > When using the non UEFI Linux entry ABI, you need to use the DT to pass
> those parameters.
> > When using the UEFI Linux entry ABI, you *can* (not must) use the
> command line to pass all information, leaving the DT passed to the OS
> without any /chosen.
> > When introducing Passage, I was wondering if we could pass command line
> to Linux and, same as UEFI, leave the DT free from /chosen.
> > I am not sure it is a good goal though. I may be too pushing for a DT
> free from parameters.
>
> We could. Are there benefits to that?
>
> I doubt we would pass the standard passage to Linux as a bloblist. I
> imagine something like this. The bloblist sits in memory with some
> things in it, including a devicetree, perhaps an SMBIOS table and a
> TPM log. But when U-Boot calls Linux it puts the address/size of those
> individual things in the devicetree. They don't move and are still
> contiguous in memory, but the bloblist around them is forgotten. Linux
> doesn't know that the three separate things it is picking up are
> actually part of a bloblist structure, since it doesn't care about
> that. Even a console log could work the same way. That way we don't
> end up trying to teach Linux about bloblist when it already has a
> perfectly good means to accept these items.
>
> For ACPI I see things a similar way. The ACPI tables can point to
> things that *happen* to be in a bloblist, but without any knowledge of
> that needed in Linux, grub, etc.
>
> >>
> >> As you know I have more expansive views about what should be in DT.
> >
> > I think both of us are huge supporters of DT format and self describing
> capabilities.
> > I am inclined to put rules into what fits into what lands in the DT that
> is passed to the OS.
> > I am a fan of having DT used more in ad-hoc files.
>
> Me too.
>
> >>
> >> >
> >> > Cheers
> >> >
> >> > PS: as Ilias mentions, this patch set contains bug fixes, non
> immediately related additional functions (DM stats). It would be great to
> carve those out to fast path them and keep this one with the very core of
> your idea.
> >>
> >> The DM stats is used in 'passage: Report the devicetree source'. I
> >> know it is sideways but I think it is better to make the output line
> >> more useful than just reporting the devicetree source.
> >>
> > I believe the DM stats has merits in its own. You could upstream this
> independently and then Passage would be yet another "customer" of the
> feature.
>
> I could, but it would just be a debug feature so people might not
> think it worth the code space. With the devicetree source it is more
> compelling.
>
> >>
> >> The first patch is indeed unrelated. I will pick it up so we can drop
> >> it for the next rev.
> >>
> [..]
>
> Regards,
> Simon
>


-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog