diff options
Diffstat (limited to 'Documentation/devicetree/bindings/firmware')
9 files changed, 402 insertions, 0 deletions
diff --git a/Documentation/devicetree/bindings/firmware/coreboot.txt b/Documentation/devicetree/bindings/firmware/coreboot.txt new file mode 100644 index 000000000..4c955703c --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/coreboot.txt @@ -0,0 +1,33 @@ +COREBOOT firmware information + +The device tree node to communicate the location of coreboot's memory-resident +bookkeeping structures to the kernel. Since coreboot itself cannot boot a +device-tree-based kernel (yet), this node needs to be inserted by a +second-stage bootloader (a coreboot "payload"). + +Required properties: + - compatible: Should be "coreboot" + - reg: Address and length of the following two memory regions, in order: + 1.) The coreboot table. This is a list of variable-sized descriptors + that contain various compile- and run-time generated firmware + parameters. It is identified by the magic string "LBIO" in its first + four bytes. + See coreboot's src/commonlib/include/commonlib/coreboot_tables.h for + details. + 2.) The CBMEM area. This is a downward-growing memory region used by + coreboot to dynamically allocate data structures that remain resident. + It may or may not include the coreboot table as one of its members. It + is identified by a root node descriptor with the magic number + 0xc0389481 that resides in the topmost 8 bytes of the area. + See coreboot's src/include/imd.h for details. + +Example: + firmware { + ranges; + + coreboot { + compatible = "coreboot"; + reg = <0xfdfea000 0x264>, + <0xfdfea000 0x16000>; + } + }; diff --git a/Documentation/devicetree/bindings/firmware/cznic,turris-mox-rwtm.txt b/Documentation/devicetree/bindings/firmware/cznic,turris-mox-rwtm.txt new file mode 100644 index 000000000..338169dea --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/cznic,turris-mox-rwtm.txt @@ -0,0 +1,19 @@ +Turris Mox rWTM firmware driver + +Required properties: + - compatible : Should be "cznic,turris-mox-rwtm" + - mboxes : Must contain a reference to associated mailbox + +This device tree node should be used on Turris Mox, or potentially another A3700 +compatible device running the Mox's rWTM firmware in the secure processor (for +example it is possible to flash this firmware into EspressoBin). + +Example: + + firmware { + turris-mox-rwtm { + compatible = "cznic,turris-mox-rwtm"; + mboxes = <&rwtm 0>; + status = "okay"; + }; + }; diff --git a/Documentation/devicetree/bindings/firmware/intel,ixp4xx-network-processing-engine.yaml b/Documentation/devicetree/bindings/firmware/intel,ixp4xx-network-processing-engine.yaml new file mode 100644 index 000000000..1bd2870c3 --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/intel,ixp4xx-network-processing-engine.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2019 Linaro Ltd. +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/firmware/intel,ixp4xx-network-processing-engine.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Intel IXP4xx Network Processing Engine + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +description: | + On the IXP4xx SoCs, the Network Processing Engine (NPE) is a small + processor that can load a firmware to perform offloading of networking + and crypto tasks. It also manages the MDIO bus to the ethernet PHYs + on the IXP4xx platform. All IXP4xx platforms have three NPEs at + consecutive memory locations. They are all included in the same + device node since they are not independent of each other. + +properties: + compatible: + oneOf: + - items: + - const: intel,ixp4xx-network-processing-engine + + reg: + items: + - description: NPE0 register range + - description: NPE1 register range + - description: NPE2 register range + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + npe@c8006000 { + compatible = "intel,ixp4xx-network-processing-engine"; + reg = <0xc8006000 0x1000>, <0xc8007000 0x1000>, <0xc8008000 0x1000>; + }; +... diff --git a/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.txt b/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.txt new file mode 100644 index 000000000..6eff1afd8 --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.txt @@ -0,0 +1,57 @@ +Intel Service Layer Driver for Stratix10 SoC +============================================ +Intel Stratix10 SoC is composed of a 64 bit quad-core ARM Cortex A53 hard +processor system (HPS) and Secure Device Manager (SDM). When the FPGA is +configured from HPS, there needs to be a way for HPS to notify SDM the +location and size of the configuration data. Then SDM will get the +configuration data from that location and perform the FPGA configuration. + +To meet the whole system security needs and support virtual machine requesting +communication with SDM, only the secure world of software (EL3, Exception +Layer 3) can interface with SDM. All software entities running on other +exception layers must channel through the EL3 software whenever it needs +service from SDM. + +Intel Stratix10 service layer driver, running at privileged exception level +(EL1, Exception Layer 1), interfaces with the service providers and provides +the services for FPGA configuration, QSPI, Crypto and warm reset. Service layer +driver also manages secure monitor call (SMC) to communicate with secure monitor +code running in EL3. + +Required properties: +------------------- +The svc node has the following mandatory properties, must be located under +the firmware node. + +- compatible: "intel,stratix10-svc" or "intel,agilex-svc" +- method: smc or hvc + smc - Secure Monitor Call + hvc - Hypervisor Call +- memory-region: + phandle to the reserved memory node. See + Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt + for details + +Example: +------- + + reserved-memory { + #address-cells = <2>; + #size-cells = <2>; + ranges; + + service_reserved: svcbuffer@0 { + compatible = "shared-dma-pool"; + reg = <0x0 0x0 0x0 0x1000000>; + alignment = <0x1000>; + no-map; + }; + }; + + firmware { + svc { + compatible = "intel,stratix10-svc"; + method = "smc"; + memory-region = <&service_reserved>; + }; + }; diff --git a/Documentation/devicetree/bindings/firmware/meson/meson_sm.txt b/Documentation/devicetree/bindings/firmware/meson/meson_sm.txt new file mode 100644 index 000000000..c248cd44f --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/meson/meson_sm.txt @@ -0,0 +1,15 @@ +* Amlogic Secure Monitor + +In the Amlogic SoCs the Secure Monitor code is used to provide access to the +NVMEM, enable JTAG, set USB boot, etc... + +Required properties for the secure monitor node: +- compatible: Should be "amlogic,meson-gxbb-sm" + +Example: + + firmware { + sm: secure-monitor { + compatible = "amlogic,meson-gxbb-sm"; + }; + }; diff --git a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt new file mode 100644 index 000000000..e44a13bc0 --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt @@ -0,0 +1,107 @@ +NVIDIA Tegra Boot and Power Management Processor (BPMP) + +The BPMP is a specific processor in Tegra chip, which is designed for +booting process handling and offloading the power management, clock +management, and reset control tasks from the CPU. The binding document +defines the resources that would be used by the BPMP firmware driver, +which can create the interprocessor communication (IPC) between the CPU +and BPMP. + +Required properties: +- compatible + Array of strings + One of: + - "nvidia,tegra186-bpmp" +- mboxes : The phandle of mailbox controller and the mailbox specifier. +- shmem : List of the phandle of the TX and RX shared memory area that + the IPC between CPU and BPMP is based on. +- #clock-cells : Should be 1. +- #power-domain-cells : Should be 1. +- #reset-cells : Should be 1. + +This node is a mailbox consumer. See the following files for details of +the mailbox subsystem, and the specifiers implemented by the relevant +provider(s): + +- .../mailbox/mailbox.txt +- .../mailbox/nvidia,tegra186-hsp.txt + +This node is a clock, power domain, and reset provider. See the following +files for general documentation of those features, and the specifiers +implemented by this node: + +- .../clock/clock-bindings.txt +- <dt-bindings/clock/tegra186-clock.h> +- ../power/power-domain.yaml +- <dt-bindings/power/tegra186-powergate.h> +- .../reset/reset.txt +- <dt-bindings/reset/tegra186-reset.h> + +The BPMP implements some services which must be represented by separate nodes. +For example, it can provide access to certain I2C controllers, and the I2C +bindings represent each I2C controller as a device tree node. Such nodes should +be nested directly inside the main BPMP node. + +Software can determine whether a child node of the BPMP node represents a device +by checking for a compatible property. Any node with a compatible property +represents a device that can be instantiated. Nodes without a compatible +property may be used to provide configuration information regarding the BPMP +itself, although no such configuration nodes are currently defined by this +binding. + +The BPMP firmware defines no single global name-/numbering-space for such +services. Put another way, the numbering scheme for I2C buses is distinct from +the numbering scheme for any other service the BPMP may provide (e.g. a future +hypothetical SPI bus service). As such, child device nodes will have no reg +property, and the BPMP node will have no #address-cells or #size-cells property. + +The shared memory bindings for BPMP +----------------------------------- + +The shared memory area for the IPC TX and RX between CPU and BPMP are +predefined and work on top of sysram, which is an SRAM inside the chip. + +See ".../sram/sram.txt" for the bindings. + +Example: + +hsp_top0: hsp@3c00000 { + ... + #mbox-cells = <2>; +}; + +sysram@30000000 { + compatible = "nvidia,tegra186-sysram", "mmio-sram"; + reg = <0x0 0x30000000 0x0 0x50000>; + #address-cells = <2>; + #size-cells = <2>; + ranges = <0 0x0 0x0 0x30000000 0x0 0x50000>; + + cpu_bpmp_tx: shmem@4e000 { + compatible = "nvidia,tegra186-bpmp-shmem"; + reg = <0x0 0x4e000 0x0 0x1000>; + label = "cpu-bpmp-tx"; + pool; + }; + + cpu_bpmp_rx: shmem@4f000 { + compatible = "nvidia,tegra186-bpmp-shmem"; + reg = <0x0 0x4f000 0x0 0x1000>; + label = "cpu-bpmp-rx"; + pool; + }; +}; + +bpmp { + compatible = "nvidia,tegra186-bpmp"; + mboxes = <&hsp_top0 TEGRA_HSP_MBOX_TYPE_DB TEGRA_HSP_DB_MASTER_BPMP>; + shmem = <&cpu_bpmp_tx &cpu_bpmp_rx>; + #clock-cells = <1>; + #power-domain-cells = <1>; + #reset-cells = <1>; + + i2c { + compatible = "..."; + ... + }; +}; diff --git a/Documentation/devicetree/bindings/firmware/nvidia,tegra210-bpmp.txt b/Documentation/devicetree/bindings/firmware/nvidia,tegra210-bpmp.txt new file mode 100644 index 000000000..68d814e8c --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra210-bpmp.txt @@ -0,0 +1,35 @@ +NVIDIA Tegra210 Boot and Power Management Processor (BPMP) + +The Boot and Power Management Processor (BPMP) is a co-processor found +in Tegra210 SoC. It is designed to handle the early stages of the boot +process as well as to assisting in entering deep low power state +(suspend to ram), and also offloading DRAM memory clock scaling on +some platforms. The binding document defines the resources that would +be used by the BPMP T210 firmware driver, which can create the +interprocessor communication (IPC) between the CPU and BPMP. + +Required properties: +- compatible + Array of strings + One of: + - "nvidia,tegra210-bpmp" +- reg: physical base address and length for HW synchornization primitives + 1) base address and length to Tegra 'atomics' hardware + 2) base address and length to Tegra 'semaphore' hardware +- interrupts: specifies the interrupt number for receiving messages ("rx") + and for triggering messages ("tx") + +Optional properties: +- #clock-cells : Should be 1 for platforms where DRAM clock control is + offloaded to bpmp. + +Example: + +bpmp@70016000 { + compatible = "nvidia,tegra210-bpmp"; + reg = <0x0 0x70016000 0x0 0x2000 + 0x0 0x60001000 0x0 0x1000>; + interrupts = <GIC_SPI 6 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 4 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "tx", "rx"; +}; diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt b/Documentation/devicetree/bindings/firmware/qcom,scm.txt new file mode 100644 index 000000000..78456437d --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt @@ -0,0 +1,47 @@ +QCOM Secure Channel Manager (SCM) + +Qualcomm processors include an interface to communicate to the secure firmware. +This interface allows for clients to request different types of actions. These +can include CPU power up/down, HDCP requests, loading of firmware, and other +assorted actions. + +Required properties: +- compatible: must contain one of the following: + * "qcom,scm-apq8064" + * "qcom,scm-apq8084" + * "qcom,scm-ipq4019" + * "qcom,scm-ipq806x" + * "qcom,scm-ipq8074" + * "qcom,scm-msm8660" + * "qcom,scm-msm8916" + * "qcom,scm-msm8960" + * "qcom,scm-msm8974" + * "qcom,scm-msm8994" + * "qcom,scm-msm8996" + * "qcom,scm-msm8998" + * "qcom,scm-sc7180" + * "qcom,scm-sdm845" + * "qcom,scm-sm8150" + and: + * "qcom,scm" +- clocks: Specifies clocks needed by the SCM interface, if any: + * core clock required for "qcom,scm-apq8064", "qcom,scm-msm8660" and + "qcom,scm-msm8960" + * core, iface and bus clocks required for "qcom,scm-apq8084", + "qcom,scm-msm8916" and "qcom,scm-msm8974" +- clock-names: Must contain "core" for the core clock, "iface" for the interface + clock and "bus" for the bus clock per the requirements of the compatible. +- qcom,dload-mode: phandle to the TCSR hardware block and offset of the + download mode control register (optional) + +Example for MSM8916: + + firmware { + scm { + compatible = "qcom,msm8916", "qcom,scm"; + clocks = <&gcc GCC_CRYPTO_CLK> , + <&gcc GCC_CRYPTO_AXI_CLK>, + <&gcc GCC_CRYPTO_AHB_CLK>; + clock-names = "core", "bus", "iface"; + }; + }; diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt new file mode 100644 index 000000000..18c3aea90 --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt @@ -0,0 +1,44 @@ +----------------------------------------------------------------- +Device Tree Bindings for the Xilinx Zynq MPSoC Firmware Interface +----------------------------------------------------------------- + +The zynqmp-firmware node describes the interface to platform firmware. +ZynqMP has an interface to communicate with secure firmware. Firmware +driver provides an interface to firmware APIs. Interface APIs can be +used by any driver to communicate to PMUFW(Platform Management Unit). +These requests include clock management, pin control, device control, +power management service, FPGA service and other platform management +services. + +Required properties: + - compatible: Must contain any of below: + "xlnx,zynqmp-firmware" for Zynq Ultrascale+ MPSoC + "xlnx,versal-firmware" for Versal + - method: The method of calling the PM-API firmware layer. + Permitted values are: + - "smc" : SMC #0, following the SMCCC + - "hvc" : HVC #0, following the SMCCC + +------- +Example +------- + +Zynq Ultrascale+ MPSoC +---------------------- +firmware { + zynqmp_firmware: zynqmp-firmware { + compatible = "xlnx,zynqmp-firmware"; + method = "smc"; + ... + }; +}; + +Versal +------ +firmware { + versal_firmware: versal-firmware { + compatible = "xlnx,versal-firmware"; + method = "smc"; + ... + }; +}; |