13 Dec, 2018

1 commit


03 Dec, 2018

1 commit

  • 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
    Reviewed-by: Sumit Garg
    Tested-by: Sumit Garg
    Signed-off-by: Alexander Graf

    Heinrich Schuchardt
     

30 Sep, 2018

2 commits

  • Add a test which verifies that all subnodes under "/firmware"
    nodes are scanned.

    Signed-off-by: Rajan Vaja
    Reviewed-by: Simon Glass
    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

    Rajan Vaja
     
  • 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
    Reviewed-by: Simon Glass

    Rajan Vaja
     

11 Sep, 2018

7 commits

  • 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
    Signed-off-by: Andreas Dannenberg
    Signed-off-by: Lokesh Vutla

    Andreas Dannenberg
     
  • 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
    Signed-off-by: Lokesh Vutla

    Lokesh Vutla
     
  • 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
    Signed-off-by: Andreas Dannenberg
    Signed-off-by: Lokesh Vutla
    Signed-off-by: Nishanth Menon

    Andreas Dannenberg
     
  • 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
    Signed-off-by: Lokesh Vutla
    Signed-off-by: Nishanth Menon

    Lokesh Vutla
     
  • 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
    Signed-off-by: Lokesh Vutla
    Signed-off-by: Nishanth Menon

    Andreas Dannenberg
     
  • 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
    Signed-off-by: Andreas Dannenberg
    Signed-off-by: Lokesh Vutla

    Andreas Dannenberg
     
  • 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
    Signed-off-by: Lokesh Vutla
    Signed-off-by: Nishanth Menon
    Signed-off-by: Andreas Dannenberg

    Lokesh Vutla
     

07 May, 2018

1 commit

  • 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

    Tom Rini
     

05 Mar, 2018

1 commit

  • 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 -> #include
    #include -> #include

    Reported-by: Thomas Petazzoni
    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     

04 Dec, 2017

1 commit


01 Jun, 2017

4 commits

  • 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

    Simon Glass
     
  • 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

    Simon Glass
     
  • 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

    Simon Glass
     
  • 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

    Simon Glass
     

18 Apr, 2017

1 commit

  • 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

    Masahiro Yamada