Merge branch '2023-07-24-introduce-FF-A-suppport'

To quote the author:
Adding support for Arm FF-A v1.0 (Arm Firmware Framework for Armv8-A) [A].

FF-A specifies interfaces that enable a pair of software execution
environments aka partitions to communicate with each other. A partition
could be a VM in the Normal or Secure world, an application in S-EL0, or
a Trusted OS in S-EL1.

FF-A is a discoverable bus and similar to architecture features.
FF-A bus is discovered using ARM_SMCCC_FEATURES mechanism performed
by the PSCI driver.

   => dm tree

    Class     Index  Probed  Driver                Name
   -----------------------------------------------------------
   ...
    firmware      0  [ + ]   psci                      |-- psci
    ffa                   0  [   ]   arm_ffa               |   `-- arm_ffa
   ...

Clients are able to probe then use the FF-A bus by calling the DM class
searching APIs (e.g: uclass_first_device).

This implementation of the specification provides support for Aarch64.

The FF-A driver uses the SMC ABIs defined by the FF-A specification to:

    - Discover the presence of secure partitions (SPs) of interest
    - Access an SP's service through communication protocols
      (e.g: EFI MM communication protocol)

The FF-A support provides the following features:

    - Being generic by design and can be used by any Arm 64-bit platform
    - FF-A support can be compiled and used without EFI
    - Support for SMCCCv1.2 x0-x17 registers
    - Support for SMC32 calling convention
    - Support for 32-bit and 64-bit FF-A direct messaging
    - Support for FF-A MM communication (compatible with EFI boot time)
    - Enabling FF-A and MM communication in Corstone1000 platform as a use case
    - A Uclass driver providing generic FF-A methods.
    - An Arm FF-A device driver providing Arm-specific methods and
      reusing the Uclass methods.
    - A sandbox emulator for Arm FF-A, emulates the FF-A side of the
      Secure World and provides FF-A ABIs inspection methods.
    - An FF-A sandbox device driver for FF-A communication with the
      emulated Secure World.  The driver leverages the FF-A Uclass to
      establish FF-A communication.
    - Sandbox FF-A test cases.
    - A new command called armffa is provided as an example of how to
      access the FF-A bus

For more details about the FF-A support please refer to [B] and refer to [C] for
how to use the armffa command.

Please find at [D] an example of the expected boot logs when enabling
FF-A support for a platform. In this example the platform is
Corstone1000. But it can be any Arm 64-bit platform.

[A]: https://developer.arm.com/documentation/den0077/latest/
[B]: doc/arch/arm64.ffa.rst
[C]: doc/usage/cmd/armffa.rst
[D]: example of boot logs when enabling FF-A

5 files changed, 357 insertions, 0 deletions

diff --git a/doc/arch/arm64.ffa.rst b/doc/arch/arm64.ffa.rst
new file mode 100644
index 00000000000..325fb80346e
--- /dev/null
+++ b/doc/arch/arm64.ffa.rst
@@ -0,0 +1,261 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Arm FF-A Support
+================
+
+Summary
+-------
+
+FF-A stands for Firmware Framework for Arm A-profile processors.
+
+FF-A specifies interfaces that enable a pair of software execution environments aka partitions to
+communicate with each other. A partition could be a VM in the Normal or Secure world, an
+application in S-EL0, or a Trusted OS in S-EL1.
+
+The U-Boot FF-A support (the bus) implements the interfaces to communicate
+with partitions in the Secure world aka Secure partitions (SPs).
+
+The FF-A support specifically focuses on communicating with SPs that
+isolate portions of EFI runtime services that must run in a protected
+environment which is inaccessible by the Host OS or Hypervisor.
+Examples of such services are set/get variables.
+
+The FF-A support uses the SMC ABIs defined by the FF-A specification to:
+
+- Discover the presence of SPs of interest
+- Access an SP's service through communication protocols
+  e.g. EFI MM communication protocol
+
+At this stage of development only EFI boot-time services are supported.
+Runtime support will be added in future developments.
+
+The U-Boot FF-A support provides the following parts:
+
+- A Uclass driver providing generic FF-A methods.
+- An Arm FF-A device driver providing Arm-specific methods and reusing the Uclass methods.
+- A sandbox emulator for Arm FF-A, emulates the FF-A side of the Secure World and provides
+  FF-A ABIs inspection methods.
+- An FF-A sandbox device driver for FF-A communication with the emulated Secure World.
+  The driver leverages the FF-A Uclass to establish FF-A communication.
+- Sandbox FF-A test cases.
+
+FF-A and SMC specifications
+-------------------------------------------
+
+The current implementation of the U-Boot FF-A support relies on
+`FF-A v1.0 specification`_ and uses SMC32 calling convention which
+means using the first 32-bit data of the Xn registers.
+
+At this stage we only need the FF-A v1.0 features.
+
+The FF-A support has been tested with OP-TEE which supports SMC32 calling
+convention.
+
+Hypervisors are supported if they are configured to trap SMC calls.
+
+The FF-A support uses 64-bit registers as per `SMC Calling Convention v1.2 specification`_.
+
+Supported hardware
+--------------------------------
+
+Aarch64 plaforms
+
+Configuration
+----------------------
+
+CONFIG_ARM_FFA_TRANSPORT
+    Enables the FF-A support. Turn this on if you want to use FF-A
+    communication.
+    When using an Arm 64-bit platform, the Arm FF-A driver will be used.
+    When using sandbox, the sandbox FF-A emulator and FF-A sandbox driver will be used.
+
+FF-A ABIs under the hood
+---------------------------------------
+
+Invoking an FF-A ABI involves providing to the secure world/hypervisor the
+expected arguments from the ABI.
+
+On an Arm 64-bit platform, the ABI arguments are stored in x0 to x7 registers.
+Then, an SMC instruction is executed.
+
+At the secure side level or hypervisor the ABI is handled at a higher exception
+level and the arguments are read and processed.
+
+The response is put back through x0 to x7 registers and control is given back
+to the U-Boot Arm FF-A driver (non-secure world).
+
+The driver reads the response and processes it accordingly.
+
+This methodology applies to all the FF-A ABIs.
+
+FF-A bus discovery on Arm 64-bit platforms
+---------------------------------------------
+
+When CONFIG_ARM_FFA_TRANSPORT is enabled, the FF-A bus is considered as
+an architecture feature and discovered using ARM_SMCCC_FEATURES mechanism.
+This discovery mechanism is performed by the PSCI driver.
+
+The PSCI driver comes with a PSCI device tree node which is the root node for all
+architecture features including FF-A bus.
+
+::
+
+   => dm tree
+
+    Class     Index  Probed  Driver                Name
+   -----------------------------------------------------------
+    firmware      0  [ + ]   psci                      |-- psci
+    ffa                   0  [   ]   arm_ffa               |   `-- arm_ffa
+
+The PSCI driver is bound to the PSCI device and when probed it tries to discover
+the architecture features by calling a callback the features drivers provide.
+
+In case of FF-A, the callback is arm_ffa_is_supported() which tries to discover the
+FF-A framework by querying the FF-A framework version from secure world using
+FFA_VERSION ABI. When discovery is successful, the ARM_SMCCC_FEATURES
+mechanism creates a U-Boot device for the FF-A bus and binds the Arm FF-A driver
+with the device using device_bind_driver().
+
+At this stage the FF-A bus is registered with the DM and can be interacted with using
+the DM APIs.
+
+Clients are able to probe then use the FF-A bus by calling uclass_first_device().
+Please refer to the armffa command implementation as an example of how to probe
+and interact with the FF-A bus.
+
+When calling uclass_first_device(), the FF-A driver is probed and ends up calling
+ffa_do_probe() provided by the Uclass which does the following:
+
+    - saving the FF-A framework version in uc_priv
+    - querying from secure world the u-boot endpoint ID
+    - querying from secure world the supported features of FFA_RXTX_MAP
+    - mapping the RX/TX buffers
+    - querying from secure world all the partitions information
+
+When one of the above actions fails, probing fails and the driver stays not active
+and can be probed again if needed.
+
+Requirements for clients
+-------------------------------------
+
+When using the FF-A bus with EFI, clients must query the SPs they are looking for
+during EFI boot-time mode using the service UUID.
+
+The RX/TX buffers are only available at EFI boot-time. Querying partitions is
+done at boot time and data is cached for future use.
+
+RX/TX buffers should be unmapped before EFI runtime mode starts.
+The driver provides a bus operation for that called ffa_rxtx_unmap().
+
+The user should call ffa_rxtx_unmap() to unmap the RX/TX buffers when required
+(e.g: at efi_exit_boot_services()).
+
+The Linux kernel allocates its own RX/TX buffers. To be able to register these kernel buffers
+with secure world, the U-Boot's RX/TX buffers should be unmapped before EFI runtime starts.
+
+When invoking FF-A direct messaging, clients should specify which ABI protocol
+they want to use (32-bit vs 64-bit). Selecting the protocol means using
+the 32-bit or 64-bit version of FFA_MSG_SEND_DIRECT_{REQ, RESP}.
+The calling convention between U-Boot and the secure world stays the same: SMC32.
+
+Requirements for user drivers
+-------------------------------------
+
+Users who want to implement their custom FF-A device driver while reusing the FF-A Uclass can do so
+by implementing their own invoke_ffa_fn() in the user driver.
+
+The bus driver layer
+------------------------------
+
+FF-A support comes on top of the SMCCC layer and is implemented by the FF-A Uclass drivers/firmware/arm-ffa/arm-ffa-uclass.c
+
+The following features are provided:
+
+- Support for the 32-bit version of the following ABIs:
+
+    - FFA_VERSION
+    - FFA_ID_GET
+    - FFA_FEATURES
+    - FFA_PARTITION_INFO_GET
+    - FFA_RXTX_UNMAP
+    - FFA_RX_RELEASE
+    - FFA_RUN
+    - FFA_ERROR
+    - FFA_SUCCESS
+    - FFA_INTERRUPT
+    - FFA_MSG_SEND_DIRECT_REQ
+    - FFA_MSG_SEND_DIRECT_RESP
+
+- Support for the 64-bit version of the following ABIs:
+
+    - FFA_RXTX_MAP
+    - FFA_MSG_SEND_DIRECT_REQ
+    - FFA_MSG_SEND_DIRECT_RESP
+
+- Processing the received data from the secure world/hypervisor and caching it
+
+- Hiding from upper layers the FF-A protocol and registers details. Upper
+  layers focus on exchanged data, FF-A support takes care of how to transport
+  that to the secure world/hypervisor using FF-A
+
+- FF-A support provides driver operations to be used by upper layers:
+
+    - ffa_partition_info_get
+    - ffa_sync_send_receive
+    - ffa_rxtx_unmap
+
+- FF-A bus discovery makes sure FF-A framework is responsive and compatible
+  with the driver
+
+- FF-A bus can be compiled and used without EFI
+
+Relationship between the sandbox emulator and the FF-A device
+---------------------------------------------------------------
+
+::
+
+   => dm tree
+
+    Class     Index  Probed  Driver                Name
+   -----------------------------------------------------------
+   ffa_emul      0  [ + ]   sandbox_ffa_emul      `-- arm-ffa-emul
+    ffa                  0  [    ]   sandbox_arm_ffa               `-- sandbox-arm-ffa
+
+The armffa command
+-----------------------------------
+
+armffa is a command showcasing how to use the FF-A bus and how to invoke the driver operations.
+
+Please refer the command documentation at :doc:`../usage/cmd/armffa`
+
+Example of boot logs with FF-A enabled
+--------------------------------------
+
+For example, when using FF-A with Corstone-1000 the logs are as follows:
+
+::
+
+   U-Boot 2023.01 (May 10 2023 - 11:08:07 +0000) corstone1000 aarch64
+
+   DRAM:  2 GiB
+   Arm FF-A framework discovery
+   FF-A driver 1.0
+   FF-A framework 1.0
+   FF-A versions are compatible
+   ...
+   FF-A driver 1.0
+   FF-A framework 1.0
+   FF-A versions are compatible
+   EFI: MM partition ID 0x8003
+   ...
+   EFI stub: Booting Linux Kernel...
+   ...
+   Linux version 6.1.9-yocto-standard (oe-user@oe-host) (aarch64-poky-linux-musl-gcc (GCC) 12.2.0, GNU ld (GNU Binutils) 2.40.202301193
+   Machine model: ARM Corstone1000 FPGA MPS3 board
+
+Contributors
+------------
+   * Abdellatif El Khlifi <[email protected]>
+
+.. _`FF-A v1.0 specification`: https://documentation-service.arm.com/static/5fb7e8a6ca04df4095c1d65e
+.. _`SMC Calling Convention v1.2 specification`: https://documentation-service.arm.com/static/5f8edaeff86e16515cdbe4c6
diff --git a/doc/arch/index.rst b/doc/arch/index.rst
index b8da4b8c8e5..2f916f4026c 100644
--- a/doc/arch/index.rst
+++ b/doc/arch/index.rst
@@ -8,6 +8,7 @@ Architecture-specific doc
 
    arc
    arm64
+   arm64.ffa
    m68k
    mips
    nios2
diff --git a/doc/arch/sandbox/sandbox.rst b/doc/arch/sandbox/sandbox.rst
index 77ca6bc4cc7..a3631de7493 100644
--- a/doc/arch/sandbox/sandbox.rst
+++ b/doc/arch/sandbox/sandbox.rst
@@ -200,6 +200,7 @@ Supported Drivers
 
 U-Boot sandbox supports these emulations:
 
+- Arm FF-A
 - Block devices
 - Chrome OS EC
 - GPIO
diff --git a/doc/usage/cmd/armffa.rst b/doc/usage/cmd/armffa.rst
new file mode 100644
index 00000000000..3d422686c14
--- /dev/null
+++ b/doc/usage/cmd/armffa.rst
@@ -0,0 +1,93 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+armffa command
+==============
+
+Synopsis
+--------
+
+::
+
+   armffa [sub-command] [arguments]
+
+   sub-commands:
+
+        getpart [partition UUID]
+
+            lists the partition(s) info
+
+        ping [partition ID]
+
+            sends a data pattern to the specified partition
+
+        devlist
+
+            displays information about the FF-A device/driver
+
+Description
+-----------
+
+armffa is a command showcasing how to use the FF-A bus and how to invoke its operations.
+
+This provides a guidance to the client developers on how to call the FF-A bus interfaces.
+
+The command also allows to gather secure partitions information and ping these  partitions.
+
+The command is also helpful in testing the communication with secure partitions.
+
+Example
+-------
+
+The following examples are run on Corstone-1000 platform.
+
+* ping
+
+::
+
+   corstone1000# armffa ping 0x8003
+   SP response:
+   [LSB]
+   fffffffe
+   0
+   0
+   0
+   0
+
+* ping (failure case)
+
+::
+
+   corstone1000# armffa ping 0
+   Sending direct request error (-22)
+
+* getpart
+
+::
+
+   corstone1000# armffa getpart 33d532ed-e699-0942-c09c-a798d9cd722d
+   Partition: id = 8003 , exec_ctxt 1 , properties 3
+
+* getpart (failure case)
+
+::
+
+   corstone1000# armffa getpart 33d532ed-e699-0942-c09c-a798d9cd7221
+   INVALID_PARAMETERS: Unrecognized UUID
+   Failure in querying partitions count (error code: -22)
+
+* devlist
+
+::
+
+   corstone1000# armffa devlist
+   device name arm_ffa, dev 00000000fdf41c30, driver name arm_ffa, ops 00000000fffc0e98
+
+Configuration
+-------------
+
+The command is available if CONFIG_CMD_ARMFFA=y and CONFIG_ARM_FFA_TRANSPORT=y.
+
+Return value
+------------
+
+The return value $? is 0 (true) on success, 1 (false) on failure.
diff --git a/doc/usage/index.rst b/doc/usage/index.rst
index 072db53614c..3326ec82fff 100644
--- a/doc/usage/index.rst
+++ b/doc/usage/index.rst
@@ -22,6 +22,7 @@ Shell commands
 
    cmd/acpi
    cmd/addrmap
+   cmd/armffa
    cmd/askenv
    cmd/base
    cmd/bdinfo