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

8 Nov 2021

      On Fri, 5 Nov 2021 at 18:17, Simon Glass sjg@chromium.org wrote:
...
) to signal Hi François,
On Fri, 5 Nov 2021 at 10:31, François Ozog francois.ozog@linaro.org
wrote:
...
Hi Simon,
Le ven. 5 nov. 2021 à 17:12, Simon Glass sjg@chromium.org a écrit :
...
Hi François,
On Fri, 5 Nov 2021 at 02:27, François Ozog francois.ozog@linaro.org
wrote:
...
...
...
On Fri, 5 Nov 2021 at 03:02, Simon Glass sjg@chromium.org wrote:
...
Hi François,
On Tue, 2 Nov 2021 at 10:03, François Ozog francois.ozog@linaro.org
wrote:
...
...
...
...
...
Hi Simon,
On Tue, 2 Nov 2021 at 15:59, Simon Glass sjg@chromium.org wrote:
>
> Hi François,
>
> On Mon, 1 Nov 2021 at 02:53, François Ozog <
francois.ozog@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.
Isn't 32 bits enough for a magic value?
Also x3 might be nicer, to match ARM 32-bit, so:
x0 = dtb
x1 = ABI indicator bits 63:32 0xb00757a3, bits 31:1 = 0, bit 0 = 1
(version 1) ? We don't need to decide how many bits for the version
right now. Perhaps 8 is plenty
x2 = 0
x3 = bloblist pointer, 0 if missing
x4 = 0
x30 = return address
sounds usable. Need more comments on this.
...
For ARM:
r0 = 0
r1 = machine number (0xb00757xx to signal standard passage where xx is
the ABI version?)*
r2 = dtb pointer
r3 = bloblist pointer (if r1 is 0xb00757xx), else 0
r4 = 0
r14 = return address

might be safe, looking at

https://elixir.bootlin.com/linux/latest/source/arch/arm/kernel/setup.c#L1094
Indeed. Need more comments on this.
...
...
...
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.
OK, I figured, so how about, for EFI on 64-bit:
x0 = handle
x1 = systable
x2 = ABI indicator bits 63:32 0xb00757a3, bits 31:1 = 0, bit 0 = 1
(version 1)
x3 = bloblist pointer
x4 = 0
x30 = return address
EFI 32-bit:
r0 = handle
r1 = systable
r2 = 0xb00757a3
r3 = bloblist pointer
r4 = 0
r14 = return address
Let's be clear that this is for an existing UEFI implementation to boot
U-Boot.
If the implementation cannot be changed to add the information, a UEFI
driver or protocol may be used.
Could SPL may be tweaked to craft the bloblist based on whatever
information I that case?
(side comment: LinuxBoot has developed techniques to replace most of an
EDK2 implementation by Linux.
This entry ABI does not apply in this use case as it is defined by EDK2.)
Now on the how.
EFI API has already defined extension mechanism, so that may be difficult
to add.
let's put the bloblist pointer in a <configtable>:
typedef struct {
1936  ///
1937  /// The 128-bit GUID value that uniquely identifies the system
configuration table.
1938  ///
1939
https://dox.ipxe.org/structEFI__CONFIGURATION__TABLE.html#a50a67cc76cea0a08e7fcfc868ea8a02f
  EFI_GUID https://dox.ipxe.org/structGUID.html VendorGuid
https://dox.ipxe.org/structEFI__CONFIGURATION__TABLE.html#a50a67cc76cea0a08e7fcfc868ea8a02f;
/* set to BLOB_LIST_GUID */
1940  ///
1941  /// A pointer to the table associated with VendorGuid.
1942  ///
1943
https://dox.ipxe.org/structEFI__CONFIGURATION__TABLE.html#a1acfe9c046bb4d3a1e7d0e3c7c06f11b
  VOID https://dox.ipxe.org/Base_8h.html#a7f319bfc2492a2136964194204e7a8cf
*VendorTable
https://dox.ipxe.org/structEFI__CONFIGURATION__TABLE.html#a1acfe9c046bb4d3a1e7d0e3c7c06f11b;
/* bloblist pointer */
1944 } EFI_CONFIGURATION_TABLE
https://dox.ipxe.org/structEFI__CONFIGURATION__TABLE.html;
U-Boot or a driver or a protocol can set the VendorTable to bloblist
pointer and add this to the list of configuration tables via
https://edk2-docs.gitbook.io/edk-ii-uefi-driver-writer-s-guide/5_uefi_servic...
The blobs should be already accounted for in the memory map as they were
pre-allocated before U-Boot entry. But that may be a topic to be checked.
Regards,
...
Simon
...
...
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@linaro.org | Skype: ffozog
--
François-Frédéric Ozog | Director Business Development
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog