) to signal Hi François, On Fri, 5 Nov 2021 at 10:31, François Ozog <francois.o...@linaro.org> wrote: > > 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.
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.o...@linaro.org | Skype: ffozog >> > > > -- > François-Frédéric Ozog | Director Business Development > T: +33.67221.6485 > francois.o...@linaro.org | Skype: ffozog >
