This change introduces SCMI agent uclass to interact with a firmware
using the SCMI protocols [1].
SCMI agent uclass currently supports a single method to request
processing of the SCMI message by an identified server. A SCMI message
is made of a byte payload associated to a protocol ID and a message ID,
all defined by the SCMI specification [1]. On return from process_msg()
method, the caller gets the service response.
SCMI agent uclass defines a post bind generic sequence for all devices.
The sequence binds all the SCMI protocols listed in the FDT for that
SCMI agent device. Currently none, but later change will introduce
protocols.
This change implements a simple sandbox device for the SCMI agent uclass.
The sandbox nicely answers SCMI_NOT_SUPPORTED to SCMI messages.
To prepare for further test support, the sandbox exposes a architecture
function for test application to read the sandbox emulated devices state.
Currently supports 2 SCMI agents, identified by an ID in the FDT device
name. The simplistic DM test does nothing yet.
SCMI agent uclass is designed for platforms that embed a SCMI server in
a firmware hosted somewhere, for example in a companion co-processor or
in the secure world of the executing processor. SCMI protocols allow an
SCMI agent to discover and access external resources as clock, reset
controllers and more. SCMI agent and server communicate following the
SCMI specification [1]. This SCMI agent implementation complies with
the DT bindings defined in the Linux kernel source tree regarding
SCMI agent description since v5.8.
Links: [1] https://developer.arm.com/architectures/system-architectures/software-standards/scmi
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add simple ZynqMP firmware drive to populate child nodes under
zynqmp_firmware DT node.
Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
This adds separate kconfig options for drivers/sysreset and
drivers/firmware.
Up to now, CONFIG_SPL_DRIVERS_MISC_SUPPORT added drivers/misc to SPL
build but also added drivers/firmware and drivers/sysreset at the same
time.
Since that is confusing, this patch uses CONFIG_SPL_SYSRESET for
drivers/sysreset and adds CONFIG_SPL_FIRMWARE for
drivers/firmware (and accordingly for the TPL options).
CONFIG_SPL_DRIVERS_MISC_SUPPORT stays for including drivers/misc into
the SPL build (and accordingly for TPL) since there are boards using
non-DM (non UCLASS_MISC) files from drivers/misc. Such boards don't
have CONFIG_SPL_MISC enabled, so cannot use this to include
drivers/misc into the SPL build.
Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
There is no prompt string for FIRMWARE config. Without this,
FIRMWARE config cannot be enabled through menuconfing or
config file. Fix this by adding prompt summary.
Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Texas Instrument's System Control Interface (TI SCI) message protocol is
used in Texas Instrument's System on Chip (SoC) such as those in the K3
family AM654 SoC to communicate between various compute processors with
a central system controller entity.
The TI SCI message protocol provides support for management of various
hardware entities within the SoC. Add support driver to allow
communication with system controller entity within the SoC using the
mailbox client.
This is mostly derived from the TI SCI driver in Linux located at
drivers/firmware/ti_sci.c.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
If the system is running PSCI firmware, the System Reset function
(func ID: 0x80000009) is supposed to be handled by PSCI, that is,
the SoC/board specific reset implementation should be moved to PSCI.
U-Boot should call the PSCI service according to the arm-smccc
manner.
The arm-smccc is supported on ARMv7 or later. Especially, ARMv8
generation SoCs are likely to run ARM Trusted Firmware BL31. In
this case, U-Boot is a non-secure world boot loader, so it should
not be able to reset the system directly.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
