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.
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.o...@linaro.org | Skype: ffozog
