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

[François Ozog]

Hi Simon,

Le ven. 5 nov. 2021 à 17:12, Simon Glass <sjg at chromium.org> a écrit :

> Hi François,
>
> On Fri, 5 Nov 2021 at 02:27, François Ozog <francois.ozog at linaro.org>
> wrote:
> >
> >
> >
> > 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.
>
> It's not that. It's just that it is closed-source, so not relevant to
> the discussion here. They could open-source it and then we could
> consider it, but it has been closed-source for years now, so why would
> we think that would happen?
>
> >
> > 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.
>
> OK. Do you think we need a separate devicetree pointer, rather than
> forcing it to be inside the created bloblist?
>
> I'd like to understand what problem you are solving with this. I am
> trying to figure out a firmware-to-firmware mini-ABI (just a few
> register values) that can be used in open-source projects. The ABI is
> not intended to be used with Linux (I am unsure of the benefit it
> would give and whether it is feasible to change the current one).
>
> You are talking about the Linux entry mechanism. What relevance does
> that have for firmware?
>
> I understand that some projects already implement the Linux mechanism,
> but that is because they expect to jump straight to Linux, not have
> U-Boot in the path. So IMO standard passage offers no benefit to them.
>
> To address them in turn:
> - rpi4 - closed source, who cares?
> - Apple M1 - we could probably expand it to pass a bloblist, but it
> would be confusing unless we share registers, as you suggest
> - Qemu - I already tried to update that and got pushback...do you
> really think those guys are going to want to add a bloblist? So again,
> who cares?
> - SystemReady - not sure what this means in practice, but it would be
> good if SystemReady could use standard passage
>
> So let's say we have an optional standard-passage thing and we use
> registers such that it is similar to Linux and EFI and just expands on
> them.
>
> The first problem is that Linux and EFI seem to be completely
> incompatible. Can that be changed, perhaps on the EFI side? If not,
> we need two separate protocols.
>
> I'll ignore EFI for now. So we might have:
>
> r0 = 0
> r1 = machine number (0?)
> r2 = dtb pointer
> r3 = bloblist pointer, 0 if missing
> r14 = return address
>
> or
>
> x0 = dtb
> x1 = bloblist pointer, 0 if missing
> x30 = return address
>
That’s essentially what I proposed!
you do not force the DTB to be found in the bloblist, and shape the U-Boot
entry after the Linux entry ABI. Good !
I was saving a few registers for future ABI evolution so that boards can be
guaranteed to have their board specific registers properly protected. The 5
registers, leaving 3 undefined was just « why not ». We could also have a
cookie in x1: high 48 bits magic low 16 ABI version, x2=bloblist pointer.


> For EFI, we could add a blob to the bloblist containing the system
> table and handle, perhaps? Otherwise:
>
> x2 - efi handle
> x3 - system table
>
> Is that along the lines of what you are thinking?
>
No, efi entry is only x0=efi handle, x1=system table . I was trying to find
a way to have passage when U-Boot is loaded as a UEFI app (your other patch
set to make U-Boot a more integrated UEFi app). Let’s say that a U-Boot
aware DXE driver/protocol actually populate such a table, it could be a
communication channel between that driver and U-Boot.

>
> But still, please respond above so I can understand what problem you
> are worried about.
>
> Regards,
> Simon
>
>
> >
> >> >>
> >> >> 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
> >
>
-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog