Hi Simon, Le ven. 5 nov. 2021 à 17:12, Simon Glass <s...@chromium.org> a écrit :
> Hi François, > > On Fri, 5 Nov 2021 at 02:27, François Ozog <francois.o...@linaro.org> > wrote: > > > > > > > > On Fri, 5 Nov 2021 at 03:02, Simon Glass <s...@chromium.org> wrote: > >> > >> Hi François, > >> > >> On Tue, 2 Nov 2021 at 10:03, François Ozog <francois.o...@linaro.org> > wrote: > >> > > >> > Hi Simon, > >> > > >> > On Tue, 2 Nov 2021 at 15:59, Simon Glass <s...@chromium.org> wrote: > >> >> > >> >> Hi François, > >> >> > >> >> On Mon, 1 Nov 2021 at 02:53, François Ozog <francois.o...@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.o...@linaro.org | Skype: ffozog > > > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
