Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-12-03 01:50:25 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/drivers/firmware/Makefile

7 lines
263 B
Makefile
Raw Normal View History

sysreset: psci: support system reset in a generic way with PSCI 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>
2017-04-14 02:10:24 +00:00
obj-$(CONFIG_FIRMWARE) += firmware-uclass.o
firmware: psci: introduce SPL_ARM_PSCI_FW Introduce a new macro SPL_ARM_PSCI_FW Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Stefano Babic <sbabic@denx.de>
2018-12-09 12:45:45 +00:00
obj-$(CONFIG_$(SPL_)ARM_PSCI_FW) += psci.o
firmware: Add basic support for TI System Control Interface (TI SCI) protocol 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>
2018-08-27 10:27:32 +00:00
obj-$(CONFIG_TI_SCI_PROTOCOL) += ti_sci.o
dm: test: Add "/firmware" node scan test Add a test which verifies that all subnodes under "/firmware" nodes are scanned. Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org> Added 'imply FIRMWARE' to sandbox Kconfig to fix test failures, fixed ordering of lines in arch/sandbox/dts/test.dts and test/dm/Makefile, updated #if condition in drivers/firmware/firmware-uclass.c: Signed-off-by: Simon Glass <sjg@chromium.org>
2018-09-19 10:43:46 +00:00
obj-$(CONFIG_SANDBOX) += firmware-sandbox.o
zynqmp: firmware: Add Xilinx ZynqMP firmware driver 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>
2019-02-15 12:45:32 +00:00
obj-$(CONFIG_ZYNQMP_FIRMWARE) += firmware-zynqmp.o
firmware: add SCMI agent uclass 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>
2020-09-09 16:44:00 +00:00
obj-$(CONFIG_SCMI_FIRMWARE) += scmi/
Reference in a new issue Copy permalink