On Thu, Jan 19, 2023 at 04:31:57PM +0000, Abdellatif El Khlifi wrote:
On Wed, Jan 18, 2023 at 08:59:32AM -0500, Tom Rini wrote:
On Wed, Jan 18, 2023 at 01:46:54PM +0000, Sudeep Holla wrote:
On Wed, Jan 18, 2023 at 12:49 PM Tom Rini trini@konsulko.com wrote:
I guess the problem comes down to, can we have one discovery method that everyone shares, or do we have to let everyone invent a new discovery method every time?
No one needs to invent any discovery method every time if the firmware specification provides one and as Rob mentioned many times in the thread, all new firmware specification must provide one and we are trying to make sure that is the case with all new specs from Arm.
FF-A, Op-tee, U-Boot, coreboot, barebox (and everyone else I'm unintentionally forgetting) could just discover these things via device tree.
I leave that to the individual projects to decide and agree but fundamentally if the specification provides a way to discover, not sure why we are even discussing an alternative method here.
Or, we could all write our own code to perform the discovery.
For what reason ? I can understand if there is no discovery mechanism but that's not the case in $subject.
And when RISC-V comes along with similar functionality, we could probe their device tree and see they've implemented the same concept, but a little differently, but still have the discovery portion be in the device tree. To which it sounds like your answer is "not in the device tree".
I see U-boot seem to have made a decision to create DT node for each and everything that needs to be added to DM which seems bit unfortunate but I don't understand the history/motive/background for it but I respect the decision if it is already made.
These firmware interfaces are standard on all Arm platforms and can be discovered based on PSCI/SMCCC. Not using the same and use DT node needs unnecessary addition of DT nodes for all the f/w i/f on all the platforms that need the support when one can be just discovered.
Sorry for the sudden appearance on this thread, I was avoiding getting into this but thought I will at least express my opinion and also the way the firmware specifications from Arm is expected to be evolved from now on. With that I will leave it to you and other U-boot maintainers and the community in general to decide the right course in this case.
To be clear, if the position is that "this is what everyone else will use, really" then yes, we'll follow this in U-Boot.
Hi Simon, Tom,
The FF-A transport is a SW bus and is not associated to any HW peripheral or undiscoverable base address.
There is only 1 way of discovering the FF-A bus and it's through the FF-A SW interfaces. The FF-A spec [1] describes this in details.
Discovering means gathering information about the FF-A framework such as: the FF-A version, supported features, secure partitions number and attributes.
Please refer to the following paragraphs for more details: [2], [3], [4], [5]
The core driver provided by this patchset implements the Setup and discovery interfaces in addition to direct messaging.
The driver provides ffa_bus_discover() API that allows to discover the FF-A bus as described by the spec and in the FF-A driver readme [6].
We expect and highly recommend FF-A users to always discover the FF-A bus using ffa_bus_discover() API.
A use case is provided which is the EFI MM communication [7].
ffa_bus_discover() does the following:
- creates, binds and probes the arm_ffa device
- at probe level, discovery FF-A interfaces are called to try to discover the FF-A framework
- when all discovery interfaces succeed, probing is successful and FF-A bus is ready to use
- if one of the discovery interfaces fails, the arm_ffa device is removed from the DM and FF-A bus can not be used
Cheers Abdellatif
[1]: FF-A spec version 1.0, https://developer.arm.com/documentation/den0077/latest/
[2] 2.8 Partition identification and discovery
All FF-A components can discover the identities and properties of other partitions through the FFA_PARTITION_INFO_GET interface. Once discovered, the IDs must be used in the messaging interfaces to identify the target of a message.[3] 4.2.2.2 Buffer discovery and setup
This version of the Framework enables discovery and setup of RX/TX buffer pairs between FF-A components as follows. ... 2. An endpoint could allocate the buffer pair and use the FFA_RXTX_MAP interface to map it with the Hypervisor or SPM as applicable.[4] 4.2.2.3 Buffer attributes
An endpoint must discover the minimum size and alignment boundary for the RX/TX buffers by passing the function ID of the FFA_RXTX_MAP ABI as input in the FFA_FEATURES interface (see 8.2 FFA_FEATURES).[5] 6.1.1 Common compliance requirements
- It must be possible for the FF-A components at an FF-A instance to discover the presence and version number of their Framework implementations through the FFA_VERSION interface (see 8.1 FFA_VERSION). - All FF-A components must implement support for Setup and discovery interfaces described in Chapter 8 Setup and discovery interfaces. These interfaces are as follows. FFA_VERSION. FFA_FEATURES. FFA_RX_RELEASE. FFA_RXTX_MAP. FFA_RXTX_UNMAP. FFA_PARTITION_INFO_GET. FFA_ID_GET. - It must be possible for an FF-A component, at the lower EL at an FF-A instance to use the FFA_FEATURES interface (see 8.2 FFA_FEATURES) to discover if an FF-A interface is implemented by the FF-A component at the higher EL.[6] FF-A support readme: https://lore.kernel.org/all/20221122131751.22747-4-abdellatif.elkhlifi@arm.c... [7] FF-A MM comms: https://lore.kernel.org/all/20221122131751.22747-10-abdellatif.elkhlifi@arm....
Since I'm apparently being unclear, let me try again. Yes, fine, for U-Boot, we'll go ahead and accept patches that implement this spec, and not require device tree modifications.
But as also I believe been agreed on, this doesn't prevent some other architecture / group from coming along and claiming it has a new unique approach to this problem and so has to re-invent the discoverable software bus wheel. Nor does it prevent some group from inventing a different software defined bus and discovery method and not re-using any of this work, because it too is special and unique and somehow different enough.