On Tue, Nov 07, 2023 at 06:23:05PM -0500, Tom Rini wrote: > On Tue, Nov 07, 2023 at 11:12:16PM +0000, Conor Dooley wrote: > > +CC Palmer > > > > On Tue, Nov 07, 2023 at 05:38:37PM -0500, Tom Rini wrote: > > > On Tue, Nov 07, 2023 at 10:27:50PM +0000, Conor Dooley wrote: > > > > On Tue, Nov 07, 2023 at 05:10:23PM -0500, Tom Rini wrote: > > > > > > > > > > > > > further clarify or not > > > > > the RISC-V ISA thing that's elsewhere in this thread (and part of the > > > > > kernel, not a U-Boot thing). > > > > > > > > TBH, this a bit fragmented across threads, and as someone that hasn't > > > > been following it it's a bit difficult to tell exactly what is being > > > > asked for. Would someone be able to ask it as a direct question? > > > > > > Sorry for being unclear, and thanks for asking. What I think the U-Boot > > > community would like to know is, what is the device-tree based way to > > > know if a RISC-V platform has the Zbb extensions > > > > For this one, it's pretty straightforward IMO - if riscv,isa-extensions > > contains "zbb", then you are safe to use those instructions. My > > understanding is that relying on getting illegal instruction traps is > > not a sufficient test for usability of standard extensions, as a vendor > > extension could be using the same opcodes as a standard extension. > > > > > so the RNG opcodes, > > > similar (in concept at least?) to the ARMv8.5 RNG feature. > > > > The ordinary extensions that are instructions - like Zbkb that provides > > bit manipulation instructions for cryptography you will be able to rely > > on riscv,isa-extensions also. Zkr is actually a CSR acting as an entropy > > source and is a bit more complicated. RISC-V Cryptography Extensions > > Volume I, Chapter Four [0] is the relevant thing for use of the CSR > > provided by Zkr, and it says "The seed CSR is also access controlled by > > execution mode, and attempted read or write access will raise an illegal > > instruction exception outside M mode unless access is explicitly granted." > > My take is that either the SBI implementation needs to provide S-Mode > > U-Boot with an accurate devicetree (including what extensions are valid > > for use in S-mode) or if the devicetree is provided as part of the U-Boot > > binary then it needs to match what is available at that privilege level > > on the platform. In this case, you would also be able to rely on > > riscv,isa-extensions for that detection. There is an existing dt-binding > > patch > > <https://lore.kernel.org/linux-riscv/[email protected]/> > > that adds Zkr, and my proposal would be to document that the presence of Zkr > > explicitly in riscv,isa-extensions means that the bit in mseccfg.[s,u]seed > > has been set so it can be used at the current privilege level. > > > > If that's not acceptable, and people think that having Zkr in the > > devicetree means that the hardware has the extension, regardless of > > usability at the present privilege level, then IMO we need an SBI ecall > > defined to request entablement of the CSR & report as to whether or not > > that was possible. > > > > I'm not sure how any of the above lines up with the ARMv8.5 RNG feature > > unfortunately. > > Thanks. Setting aside Simon's follow-up, this is what I was looking for. > We might have to wait for Heinrich to return from the conference to have > time to look at how to utilize the above and see what we can do from > there.
I did read that, but I don't think most of it is relevant to the binding itself. His five things were: | - U-Boot models hardware (and other things) as devices in driver model [1] This I think should be satisfied. The Zkr CSR is a property of the CPU, and shouldn't have its own DT node IMO. Is it problematic for U-Boot to populate multiple devices for its driver model based on one DT node? I know in Linux that I can create devices using something like platform_device_register(), does U-Boot have a similar facility? https://elixir.bootlin.com/linux/latest/source/drivers/base/platform.c#L767 | - U-Boot requires devices to be in the devicetree, with very limited | exceptions [2] | - Where multiple devices exist in a uclass, it is desirable to be able | to number them [3] I'm not sure really how this one ties in. Do you need a number for each CPU that supports Zkr, since a system may be heterogeneous? I think that how you treat things like that is beyond communicating support via DT though, IMO the job of the DT is just to tell U-Boot on which CPUs it can access the seed CSR. | - Similarly it is useful to be able select a particular device, e.g. | with a phandle [4] I suppose a phandle to the CPU would work in this case. | - U-Boot uses devicetree for configuration as it has no userspace Cheers, Conor.
signature.asc
Description: PGP signature
