Commit graph

19 commits

Author SHA1 Message Date
Peng Fan
cdd7486616 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-12 12:14:25 -05:00
Heinrich Schuchardt
81ea00838c efi_loader: PSCI reset and shutdown
When an operating system started via bootefi tries to reset or power off
this is done by calling the EFI runtime ResetSystem(). On most ARMv8 system
the actual reset relies on PSCI. Depending on whether the PSCI firmware
resides the hypervisor (EL2) or in the secure monitor (EL3) either an HVC
or an SMC command has to be issued.

The current implementation always uses SMC. This results in crashes on
systems where the PSCI firmware is implemented in the hypervisor, e.g.
qemu-arm64_defconfig.

The logic to decide which call is needed based on the device tree is
already implemented in the PSCI firmware driver. During the EFI runtime
the device driver model is not available. But we can minimize code
duplication by merging the EFI runtime reset and poweroff code with
the PSCI firmware driver.

As the same HVC/SMC problem is also evident for the ARMv8 do_poweroff
and reset_misc routines let's move them into the same code module.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Tested-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2018-12-02 21:59:37 +01:00
Rajan Vaja
31b8217e83 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-29 11:49:35 -06:00
Rajan Vaja
e7a52ba65b firmware: Add FIRMWARE config prompt string
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>
2018-09-29 11:49:35 -06:00
Andreas Dannenberg
aec99c9776 dm: firmware: Automatically bind child devices
To support scenarios where a firmware device node has subnodes that
have their own drivers automatically scan the DT and bind those when
the firmware device gets bound.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2018-09-11 08:32:55 -04:00
Lokesh Vutla
ccbc8b2fdd firmware: ti_sci: Add support for processor control services
TI-SCI message protocol provides support for controlling of various
physical cores available in SoC. In order to control which host is
capable of controlling a physical processor core, there is a processor
access control list that needs to be populated as part of the board
configuration data.

Introduce support for the set of TI-SCI message protocol apis that
provide us with this capability of controlling physical cores.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2018-09-11 08:32:55 -04:00
Andreas Dannenberg
f369b0f26c firmware: ti_sci: Add support for reboot core service
Since system controller now has control over SoC power management, it
needs to be explicitly requested to reboot the SoC. Add support for
it.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
2018-09-11 08:32:55 -04:00
Lokesh Vutla
9b87181fd2 firmware: ti_sci: Add support for clock control
In general, we expect to function at a device level of abstraction,
however, for proper operation of hardware blocks, many clocks directly
supplying the hardware block needs to be queried or configured.

Introduce support for the set of SCI message protocol support that
provide us with this capability.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
2018-09-11 08:32:55 -04:00
Andreas Dannenberg
7bc330452c firmware: ti_sci: Add support for device control
TI-SCI message protocol provides support for management of various
hardware entitites within the SoC. Introduce the fundamental
device management capability support to the driver protocol
as part of this change.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
2018-09-11 08:32:55 -04:00
Andreas Dannenberg
dcfc52ad69 firmware: ti_sci: Add support for board configuration
TI-SCI message protocol provides support for board configuration
to assign resources and other board related operations.
Introduce the board configuration capability support to the driver protocol
as part of this change.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2018-09-11 08:32:55 -04:00
Lokesh Vutla
32cd25128b 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-09-11 08:32:55 -04:00
Tom Rini
83d290c56f SPDX: Convert all of our single license tags to Linux Kernel style
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from.  So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry.  Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.

In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.

This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents.  There's also a few places where I found we did not have a tag
and have introduced one.

Signed-off-by: Tom Rini <trini@konsulko.com>
2018-05-07 09:34:12 -04:00
Masahiro Yamada
b08c8c4870 libfdt: move headers to <linux/libfdt.h> and <linux/libfdt_env.h>
Thomas reported U-Boot failed to build host tools if libfdt-devel
package is installed because tools include libfdt headers from
/usr/include/ instead of using internal ones.

This commit moves the header code:
  include/libfdt.h         -> include/linux/libfdt.h
  include/libfdt_env.h     -> include/linux/libfdt_env.h

and replaces include directives:
  #include <libfdt.h>      -> #include <linux/libfdt.h>
  #include <libfdt_env.h>  -> #include <linux/libfdt_env.h>

Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-05 10:16:28 -05:00
Masahiro Yamada
af4e6d3a03 drivers: firmware: psci: use pr_* log functions instead of printf()
In Linux, the warning messages are printed out by pr_warn().

We can use Linux-like log functions in tree-wide.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2017-12-04 10:23:53 -05:00
Simon Glass
911f3aef35 dm: core: Rename of_device_is_compatible()
The of_ prefix conflicts with the livetree version of this function.
Rename it to avoid problems when we add livetree support.

Signed-off-by: Simon Glass <sjg@chromium.org>
2017-06-01 07:03:06 -06:00
Simon Glass
da409ccc4a dm: core: Replace of_offset with accessor (part 2)
At present devices use a simple integer offset to record the device tree
node associated with the device. In preparation for supporting a live
device tree, which uses a node pointer instead, refactor existing code to
access this field through an inline function.

Signed-off-by: Simon Glass <sjg@chromium.org>
2017-06-01 07:03:04 -06:00
Simon Glass
4af0d7e870 dm: Fix up inclusion of common.h
It is good practice to include common.h as the first header. This ensures
that required features like the DECLARE_GLOBAL_DATA_PTR macro,
configuration options and common types are available.

Fix up some files which currently don't do this. This is necessary because
driver model will soon start using global data and configuration in the
dm/read.h header file, included via dm.h. The gd->fdt_blob value will be
used to access the device tree and CONFIG options will be used to
determine whether to support inline functions in the header file.

Signed-off-by: Simon Glass <sjg@chromium.org>
2017-06-01 07:03:03 -06:00
Simon Glass
9d922450aa dm: Use dm.h header when driver mode is used
This header includes things that are needed to make driver build. Adjust
existing users to include that always, even if other dm/ includes are
present

Signed-off-by: Simon Glass <sjg@chromium.org>
2017-06-01 06:57:52 -06:00
Masahiro Yamada
573a3811ed 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-18 10:29:19 -04:00