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

[Simon Glass]

) 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

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

>
>>
>> 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

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
>