lai/gk-sdk
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

GK SDK 源码库: XMIPCLinuxV100R005C00SPC030 (kernel/tools/open_source excluded)

Browse Source
This commit is contained in:
lai
2026-09-06 03:52:57 +08:00
commit b1928b41c0
21813 changed files with 4413081 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/README
+17
View File
@@ -0,0 +1,17 @@
Device Tree Bindings Staging Area
=================================
This directory contains device tree bindings for U-Boot.
These follow along with Linux kernel bindings, with a few additions. By
adding the files here, U-Boot patches can clearly show thees additions.
This makes it easier for device tree people to review these additions in
patches sent to the U-Boot mailing list.
The intent IS to commit these files to U-Boot. Hopefully at some point
the files will be stored in another repo (shared with Linux) which is
brought in as needed. Changes here are intended to mirror changes in the
Linux Documentation/devicetree/bindings/ directory.
sjg@chromium.org
17-Jan-12
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/adc/adc.txt
+62
View File
@@ -0,0 +1,62 @@
ADC device binding
There are no mandatory properties for ADC. However, if Voltage info is required,
then there are two options:
- use microvolts constraint or
- use regulator phandle to enable/read supply's Voltage
Properties and constraints:
*optional and always checked, Voltage polarity info:
- vdd-polarity-negative: positive reference Voltage has a negative polarity
- vss-polarity-negative: negative reference Voltage has a negative polarity
Chose one option, for each supply (Vdd/Vss):
*optional and always checked, supply Voltage constants:
- vdd-supply: phandle to Vdd regulator's node
- vss-supply: phandle to Vss regulator's node
*optional and checked only if the above corresponding, doesn't exist:
- vdd-microvolts: positive reference Voltage value [uV]
- vss-microvolts: negative reference Voltage value [uV]
Example with constant 'Vdd' value:
adc@1000000 {
compatible = "some-adc";
reg = <0xaabb000 0x100>;
status = "enabled";
vdd-microvolts = <1800000>;
};
Example of supply phandle usage, for the ADC's VDD/VSS references as below:
_______ _______
|Sandbox| |Sandbox|
: PMIC : : ADC :
. . . .
| | (Vdd) | AIN0|-->
| BUCK2|-------|VDDref |
| (3.3V)| _|VSSref |
|_______| | |_______|
_|_
For the above PMIC, the node can be defined as follows:
sandbox_pmic {
compatible = "sandbox,pmic";
...
buck2: buck2 {
regulator-name = "SUPPLY_3.3V";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
};
...
};
For the above ADC, the node can be defined as follows:
adc@0 {
compatible = "sandbox,adc";
vdd-supply = <&buck2>;
vss-microvolts = <0>;
};
The ADC uclass code, will enable the supply before start of the conversion,
but it will not configure the regulator settings.
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/adc/st,stm32-adc.txt
+141
View File
@@ -0,0 +1,141 @@
STMicroelectronics STM32 ADC device
STM32 ADC is a successive approximation analog-to-digital converter.
It has several multiplexed input channels. Conversions can be performed
in single, continuous, scan or discontinuous mode. Result of the ADC is
stored in a left-aligned or right-aligned 32-bit data register.
Conversions can be launched in software or using hardware triggers.
The analog watchdog feature allows the application to detect if the input
voltage goes beyond the user-defined, higher or lower thresholds.
Each STM32 ADC block can have up to 3 ADC instances.
Each instance supports two contexts to manage conversions, each one has its
own configurable sequence and trigger:
- regular conversion can be done in sequence, running in background
- injected conversions have higher priority, and so have the ability to
interrupt regular conversion sequence (either triggered in SW or HW).
Regular sequence is resumed, in case it has been interrupted.
Contents of a stm32 adc root node:
-----------------------------------
Required properties:
- compatible: Should be one of:
"st,stm32f4-adc-core"
"st,stm32h7-adc-core"
"st,stm32mp1-adc-core"
- reg: Offset and length of the ADC block register set.
- interrupts: One or more interrupts for ADC block. Some parts like stm32f4
and stm32h7 share a common ADC interrupt line. stm32mp1 has two separate
interrupt lines, one for each ADC within ADC block.
- clocks: Core can use up to two clocks, depending on part used:
- "adc" clock: for the analog circuitry, common to all ADCs.
It's required on stm32f4.
It's optional on stm32h7.
- "bus" clock: for registers access, common to all ADCs.
It's not present on stm32f4.
It's required on stm32h7.
- clock-names: Must be "adc" and/or "bus" depending on part used.
- interrupt-controller: Identifies the controller node as interrupt-parent
- vref-supply: Phandle to the vref input analog reference voltage.
- #interrupt-cells = <1>;
- #address-cells = <1>;
- #size-cells = <0>;
Optional properties:
- A pinctrl state named "default" for each ADC channel may be defined to set
inX ADC pins in mode of operation for analog input on external pin.
Contents of a stm32 adc child node:
-----------------------------------
An ADC block node should contain at least one subnode, representing an
ADC instance available on the machine.
Required properties:
- compatible: Should be one of:
"st,stm32f4-adc"
"st,stm32h7-adc"
"st,stm32mp1-adc"
- reg: Offset of ADC instance in ADC block (e.g. may be 0x0, 0x100, 0x200).
- clocks: Input clock private to this ADC instance. It's required only on
stm32f4, that has per instance clock input for registers access.
- interrupt-parent: Phandle to the parent interrupt controller.
- interrupts: IRQ Line for the ADC (e.g. may be 0 for adc@0, 1 for adc@100 or
2 for adc@200).
- st,adc-channels: List of single-ended channels muxed for this ADC.
It can have up to 16 channels on stm32f4 or 20 channels on stm32h7, numbered
from 0 to 15 or 19 (resp. for in0..in15 or in0..in19).
- st,adc-diff-channels: List of differential channels muxed for this ADC.
Depending on part used, some channels can be configured as differential
instead of single-ended (e.g. stm32h7). List here positive and negative
inputs pairs as <vinp vinn>, <vinp vinn>,... vinp and vinn are numbered
from 0 to 19 on stm32h7)
Note: At least one of "st,adc-channels" or "st,adc-diff-channels" is required.
Both properties can be used together. Some channels can be used as
single-ended and some other ones as differential (mixed). But channels
can't be configured both as single-ended and differential (invalid).
- #io-channel-cells = <1>: See the IIO bindings section "IIO consumers" in
Documentation/devicetree/bindings/iio/iio-bindings.txt
Optional properties:
- dmas: Phandle to dma channel for this ADC instance.
See ../../dma/dma.txt for details.
- dma-names: Must be "rx" when dmas property is being used.
- assigned-resolution-bits: Resolution (bits) to use for conversions. Must
match device available resolutions:
* can be 6, 8, 10 or 12 on stm32f4
* can be 8, 10, 12, 14 or 16 on stm32h7
Default is maximum resolution if unset.
- st,min-sample-time-nsecs: Minimum sampling time in nanoseconds.
Depending on hardware (board) e.g. high/low analog input source impedance,
fine tune of ADC sampling time may be recommended.
This can be either one value or an array that matches 'st,adc-channels' list,
to set sample time resp. for all channels, or independently for each channel.
Example:
adc: adc@40012000 {
compatible = "st,stm32f4-adc-core";
reg = <0x40012000 0x400>;
interrupts = <18>;
clocks = <&rcc 0 168>;
clock-names = "adc";
vref-supply = <&reg_vref>;
interrupt-controller;
pinctrl-names = "default";
pinctrl-0 = <&adc3_in8_pin>;
#interrupt-cells = <1>;
#address-cells = <1>;
#size-cells = <0>;
adc@0 {
compatible = "st,stm32f4-adc";
#io-channel-cells = <1>;
reg = <0x0>;
clocks = <&rcc 0 168>;
interrupt-parent = <&adc>;
interrupts = <0>;
st,adc-channels = <8>;
dmas = <&dma2 0 0 0x400 0x0>;
dma-names = "rx";
assigned-resolution-bits = <8>;
};
...
other adc child nodes follow...
};
Example to setup:
- channel 1 as single-ended
- channels 2 & 3 as differential (with resp. 6 & 7 negative inputs)
adc: adc@40022000 {
compatible = "st,stm32h7-adc-core";
...
adc1: adc@0 {
compatible = "st,stm32h7-adc";
...
st,adc-channels = <1>;
st,adc-diff-channels = <2 6>, <3 7>;
};
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/arm/l2c2x0.txt
+114
View File
@@ -0,0 +1,114 @@
* ARM L2 Cache Controller
ARM cores often have a separate L2C210/L2C220/L2C310 (also known as PL210/PL220/
PL310 and variants) based level 2 cache controller. All these various implementations
of the L2 cache controller have compatible programming models (Note 1).
Some of the properties that are just prefixed "cache-*" are taken from section
3.7.3 of the Devicetree Specification which can be found at:
https://www.devicetree.org/specifications/
The ARM L2 cache representation in the device tree should be done as follows:
Required properties:
- compatible : should be one of:
"arm,pl310-cache"
"arm,l220-cache"
"arm,l210-cache"
"bcm,bcm11351-a2-pl310-cache": DEPRECATED by "brcm,bcm11351-a2-pl310-cache"
"brcm,bcm11351-a2-pl310-cache": For Broadcom bcm11351 chipset where an
offset needs to be added to the address before passing down to the L2
cache controller
"marvell,aurora-system-cache": Marvell Controller designed to be
compatible with the ARM one, with system cache mode (meaning
maintenance operations on L1 are broadcasted to the L2 and L2
performs the same operation).
"marvell,aurora-outer-cache": Marvell Controller designed to be
compatible with the ARM one with outer cache mode.
"marvell,tauros3-cache": Marvell Tauros3 cache controller, compatible
with arm,pl310-cache controller.
- cache-unified : Specifies the cache is a unified cache.
- cache-level : Should be set to 2 for a level 2 cache.
- reg : Physical base address and size of cache controller's memory mapped
registers.
Optional properties:
- arm,data-latency : Cycles of latency for Data RAM accesses. Specifies 3 cells of
read, write and setup latencies. Minimum valid values are 1. Controllers
without setup latency control should use a value of 0.
- arm,tag-latency : Cycles of latency for Tag RAM accesses. Specifies 3 cells of
read, write and setup latencies. Controllers without setup latency control
should use 0. Controllers without separate read and write Tag RAM latency
values should only use the first cell.
- arm,dirty-latency : Cycles of latency for Dirty RAMs. This is a single cell.
- arm,filter-ranges : <start length> Starting address and length of window to
filter. Addresses in the filter window are directed to the M1 port. Other
addresses will go to the M0 port.
- arm,io-coherent : indicates that the system is operating in an hardware
I/O coherent mode. Valid only when the arm,pl310-cache compatible
string is used.
- interrupts : 1 combined interrupt.
- cache-size : specifies the size in bytes of the cache
- cache-sets : specifies the number of associativity sets of the cache
- cache-block-size : specifies the size in bytes of a cache block
- cache-line-size : specifies the size in bytes of a line in the cache,
if this is not specified, the line size is assumed to be equal to the
cache block size
- cache-id-part: cache id part number to be used if it is not present
on hardware
- wt-override: If present then L2 is forced to Write through mode
- arm,double-linefill : Override double linefill enable setting. Enable if
non-zero, disable if zero.
- arm,double-linefill-incr : Override double linefill on INCR read. Enable
if non-zero, disable if zero.
- arm,double-linefill-wrap : Override double linefill on WRAP read. Enable
if non-zero, disable if zero.
- arm,prefetch-drop : Override prefetch drop enable setting. Enable if non-zero,
disable if zero.
- arm,prefetch-offset : Override prefetch offset value. Valid values are
0-7, 15, 23, and 31.
- arm,shared-override : The default behavior of the L220 or PL310 cache
controllers with respect to the shareable attribute is to transform "normal
memory non-cacheable transactions" into "cacheable no allocate" (for reads)
or "write through no write allocate" (for writes).
On systems where this may cause DMA buffer corruption, this property must be
specified to indicate that such transforms are precluded.
- arm,parity-enable : enable parity checking on the L2 cache (L220 or PL310).
- arm,parity-disable : disable parity checking on the L2 cache (L220 or PL310).
- arm,outer-sync-disable : disable the outer sync operation on the L2 cache.
Some core tiles, especially ARM PB11MPCore have a faulty L220 cache that
will randomly hang unless outer sync operations are disabled.
- prefetch-data : Data prefetch. Value: <0> (forcibly disable), <1>
(forcibly enable), property absent (retain settings set by firmware)
- prefetch-instr : Instruction prefetch. Value: <0> (forcibly disable),
<1> (forcibly enable), property absent (retain settings set by
firmware)
- arm,dynamic-clock-gating : L2 dynamic clock gating. Value: <0> (forcibly
disable), <1> (forcibly enable), property absent (OS specific behavior,
preferably retain firmware settings)
- arm,standby-mode: L2 standby mode enable. Value <0> (forcibly disable),
<1> (forcibly enable), property absent (OS specific behavior,
preferably retain firmware settings)
- arm,early-bresp-disable : Disable the CA9 optimization Early BRESP (PL310)
- arm,full-line-zero-disable : Disable the CA9 optimization Full line of zero
write (PL310)
Example:
L2: cache-controller {
compatible = "arm,pl310-cache";
reg = <0xfff12000 0x1000>;
arm,data-latency = <1 1 1>;
arm,tag-latency = <2 2 2>;
arm,filter-ranges = <0x80000000 0x8000000>;
cache-unified;
cache-level = <2>;
interrupts = <45>;
};
Note 1: The description in this document doesn't apply to integrated L2
cache controllers as found in e.g. Cortex-A15/A7/A57/A53. These
integrated L2 controllers are assumed to be all preconfigured by
early secure boot code. Thus no need to deal with their configuration
in the kernel at all.
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/ata/intel-sata.txt
+26
View File
@@ -0,0 +1,26 @@
Intel Pantherpoint SATA Device Binding
======================================
The device tree node which describes the operation of the Intel Pantherpoint
SATA device is as follows:
Required properties :
- compatible = "intel,pantherpoint-ahci"
- intel,sata-mode : string, one of:
"ahci" : Use AHCI mode (default)
"combined" : Use combined IDE + legacy mode
"plain-ide" : Use plain IDE mode
- intel,sata-port-map : Which SATA ports are enabled, bit 0=enable first port,
bit 1=enable second port, etc.
- intel,sata-port0-gen3-tx : Value for the IOBP_SP0G3IR register
- intel,sata-port1-gen3-tx : Value for the IOBP_SP1G3IR register
Example
-------
sata {
compatible = "intel,pantherpoint-ahci";
intel,sata-mode = "ahci";
intel,sata-port-map = <1>;
intel,sata-port0-gen3-tx = <0x00880a7f>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/axi/gdsys,ihs_axi.txt
+22
View File
@@ -0,0 +1,22 @@
gdsys AXI busses of IHS FPGA devices
Certain gdsys IHS FPGAs offer a interface to their built-in AXI bus with which
the connected devices (usually IP cores) can be controlled via software.
Required properties:
- compatible: must be "gdsys,ihs_axi"
- reg: describes the address and length of the AXI bus's register map (within
the FPGA's register space)
Example:
fpga0_axi_video0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "gdsys,ihs_axi";
reg = <0x170 0x10>;
axi_dev_1 {
...
};
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/board/gdsys,board_gazerbeam.txt
+46
View File
@@ -0,0 +1,46 @@
gdsys Gazerbeam board driver
This driver provides capabilities to access the gdsys Gazerbeam board's device
information. Furthermore, phandles to some internal devices are provided for
the board files.
Required properties:
- compatible: should be "gdsys,board_gazerbeam"
- csb: phandle to the board's coherent system bus (CSB) device node
- rxaui[0-3]: phandles to the rxaui control device nodes
- fpga[0-1]: phandles to the board's gdsys FPGA device nodes
- ioep[0-1]: phandles to the board's IO endpoint device nodes
- ver-gpios: GPIO list to read the hardware version from
- var-gpios: GPIO list to read the hardware variant information from
- reset-gpios: GPIO list for the board's reset GPIOs
Example:
board {
compatible = "gdsys,board_gazerbeam";
csb = <&board_soc>;
serdes = <&SERDES>;
rxaui0 = <&RXAUI0>;
rxaui1 = <&RXAUI1>;
rxaui2 = <&RXAUI2>;
rxaui3 = <&RXAUI3>;
fpga0 = <&FPGA0>;
fpga1 = <&FPGA1>;
ioep0 = <&IOEP0>;
ioep1 = <&IOEP1>;
ver-gpios = <&PPCPCA 12 0
&PPCPCA 13 0
&PPCPCA 14 0
&PPCPCA 15 0>;
/* MC2/SC-Board */
var-gpios-mc2 = <&GPIO_VB0 0 0 /* VAR-MC_SC */
&GPIO_VB0 11 0>; /* VAR-CON */
/* MC4-Board */
var-gpios-mc4 = <&GPIO_VB1 0 0 /* VAR-MC_SC */
&GPIO_VB1 11 0>; /* VAR-CON */
reset-gpios = <&gpio0 1 0 &gpio0 2 1>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/chosen.txt
+136
View File
@@ -0,0 +1,136 @@
The chosen node
---------------
The chosen node does not represent a real device, but serves as a place
for passing data like which serial device to used to print the logs etc
stdout-path property
--------------------
Device trees may specify the device to be used for boot console output
with a stdout-path property under /chosen.
Example
-------
/ {
chosen {
stdout-path = "/serial@f00:115200";
};
serial@f00 {
compatible = "vendor,some-uart";
reg = <0xf00 0x10>;
};
};
tick-timer property
-------------------
In a system there are multiple timers, specify which timer to be used
as the tick-timer. Earlier it was hardcoded in the timer driver now
since device tree has all the timer nodes. Specify which timer to be
used as tick timer.
Example
-------
/ {
chosen {
tick-timer = "/timer2@f00";
};
timer2@f00 {
compatible = "vendor,some-timer";
reg = <0xf00 0x10>;
};
};
u-boot,bootcount-device property
--------------------------------
In a DM-based system, the bootcount may be stored in a device known to
the DM framework (e.g. in a battery-backed SRAM area within a RTC
device) managed by a device conforming to UCLASS_BOOTCOUNT. If
multiple such devices are present in a system concurrently, then the
u-boot,bootcount-device property can select the preferred target.
Example
-------
/ {
chosen {
u-boot,bootcount-device = &bootcount-rv3029;
};
bootcount-rv3029: bootcount@0 {
compatible = "u-boot,bootcount-rtc";
rtc = &rv3029;
offset = <0x38>;
};
i2c2 {
rv3029: rtc@56 {
compatible = "mc,rv3029";
reg = <0x56>;
};
};
};
u-boot,spl-boot-order property
------------------------------
In a system using an SPL stage and having multiple boot sources
(e.g. SPI NOR flash, on-board eMMC and a removable SD-card), the boot
device may be probed by reading the image and verifying an image
signature.
If the SPL is configured through the device-tree, the boot-order can
be configured with the spl-boot-order property under the /chosen node.
Each list element of the property should specify a device to be probed
in the order they are listed: references (i.e. implicit paths), a full
path or an alias is expected for each entry.
A special specifier "same-as-spl" can be used at any position in the
boot-order to direct U-Boot to insert the device the SPL was booted
from there. Whether this is indeed inserted or silently ignored (if
it is not supported on any given SoC/board or if the boot-device is
not available to continue booting from) is implementation-defined.
Note that if "same-as-spl" expands to an actual node for a given
board, the corresponding node may appear multiple times in the
boot-order (as there currently exists no mechanism to suppress
duplicates from the list).
Example
-------
/ {
chosen {
u-boot,spl-boot-order = "same-as-spl", &sdmmc, "/sdhci@fe330000";
};
};
u-boot,spl-boot-device property
-------------------------------
This property is a companion-property to the u-boot,spl-boot-order and
will be injected automatically by the SPL stage to notify a later stage
of where said later stage was booted from.
You should not define this property yourself in the device-tree, as it
may be overwritten without warning.
firmware-loader property
------------------------
Multiple file system firmware loader nodes could be defined in device trees for
multiple storage type and their default partition, then a property
"firmware-loader" can be used to pass default firmware loader
node(default storage type) to the firmware loader driver.
Example
-------
/ {
chosen {
firmware-loader = &fs_loader0;
};
fs_loader0: fs-loader@0 {
u-boot,dm-pre-reloc;
compatible = "u-boot,fs-loader";
phandlepart = <&mmc 1>;
};
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/clock/fixed-factor-clock.txt
+24
View File
@@ -0,0 +1,24 @@
Binding for simple fixed factor rate clock sources.
This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible : shall be "fixed-factor-clock".
- #clock-cells : from common clock binding; shall be set to 0.
- clock-div: fixed divider.
- clock-mult: fixed multiplier.
- clocks: parent clock.
Optional properties:
- clock-output-names : From common clock binding.
Example:
clock {
compatible = "fixed-factor-clock";
clocks = <&parentclk>;
#clock-cells = <0>;
clock-div = <2>;
clock-mult = <1>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/clock/fsl,mpc83xx-clk.txt
+23
View File
@@ -0,0 +1,23 @@
MPC83xx system clock devices
MPC83xx SoCs supply a variety of clocks to drive various components of a
system.
Required properties:
- compatible: must be one of "fsl,mpc8308-clk",
"fsl,mpc8309-clk",
"fsl,mpc8313-clk",
"fsl,mpc8315-clk",
"fsl,mpc832x-clk",
"fsl,mpc8349-clk",
"fsl,mpc8360-clk",
"fsl,mpc8379-clk"
depending on which SoC is employed
- #clock-cells: Must be 1
Example:
socclocks: clocks {
compatible = "fsl,mpc832x-clk";
#clock-cells = <1>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/clock/microchip,pic32-clock.txt
+33
View File
@@ -0,0 +1,33 @@
* Microchip PIC32 Clock and Oscillator
Microchip PIC32 clock tree consists of few oscillators, PLLs,
multiplexers and few divider modules capable of supplying clocks
to various controllers within SoC and also to off-chip.
PIC32 clock controller output is defined by indices as defined
in [0]
[0] include/dt-bindings/clock/microchip,clock.h
Required Properties:
- compatible: should be "microchip,pic32mzda_clk"
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.
Example: Clock controller node:
clock: clk@1f801200 {
compatible = "microchip,pic32mzda-clk";
reg = <0x1f801200 0x1000>;
};
Example: UART controller node that consumes the clock generated by the clock
controller:
uart1: serial@1f822000 {
compatible = "microchip,pic32mzda-uart";
reg = <0xbf822000 0x50>;
interrupts = <112 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clock PB2CLK>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/clock/nvidia,tegra20-car.txt
+207
View File
@@ -0,0 +1,207 @@
NVIDIA Tegra20 Clock And Reset Controller
This binding uses the common clock binding:
Documentation/devicetree/bindings/clock/clock-bindings.txt
The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
for muxing and gating Tegra's clocks, and setting their rates.
Required properties :
- compatible : Should be "nvidia,tegra20-car"
- reg : Should contain CAR registers location and length
- clocks : Should contain phandle and clock specifiers for two clocks:
the 32 KHz "32k_in", and the board-specific oscillator "osc".
- #clock-cells : Should be 1.
In clock consumers, this cell represents the clock ID exposed by the CAR.
The first 96 clocks are numbered to match the bits in the CAR's CLK_OUT_ENB
registers. These IDs often match those in the CAR's RST_DEVICES registers,
but not in all cases. Some bits in CLK_OUT_ENB affect multiple clocks. In
this case, those clocks are assigned IDs above 95 in order to highlight
this issue. Implementations that interpret these clock IDs as bit values
within the CLK_OUT_ENB or RST_DEVICES registers should be careful to
explicitly handle these special cases.
The balance of the clocks controlled by the CAR are assigned IDs of 96 and
above.
0 cpu
1 unassigned
2 unassigned
3 ac97
4 rtc
5 tmr
6 uart1
7 unassigned (register bit affects uart2 and vfir)
8 gpio
9 sdmmc2
10 unassigned (register bit affects spdif_in and spdif_out)
11 i2s1
12 i2c1
13 ndflash
14 sdmmc1
15 sdmmc4
16 twc
17 pwm
18 i2s2
19 epp
20 unassigned (register bit affects vi and vi_sensor)
21 2d
22 usbd
23 isp
24 3d
25 ide
26 disp2
27 disp1
28 host1x
29 vcp
30 unassigned
31 cache2
32 mem
33 ahbdma
34 apbdma
35 unassigned
36 kbc
37 stat_mon
38 pmc
39 fuse
40 kfuse
41 sbc1
42 snor
43 spi1
44 sbc2
45 xio
46 sbc3
47 dvc
48 dsi
49 unassigned (register bit affects tvo and cve)
50 mipi
51 hdmi
52 csi
53 tvdac
54 i2c2
55 uart3
56 unassigned
57 emc
58 usb2
59 usb3
60 mpe
61 vde
62 bsea
63 bsev
64 speedo
65 uart4
66 uart5
67 i2c3
68 sbc4
69 sdmmc3
70 pcie
71 owr
72 afi
73 csite
74 unassigned
75 avpucq
76 la
77 unassigned
78 unassigned
79 unassigned
80 unassigned
81 unassigned
82 unassigned
83 unassigned
84 irama
85 iramb
86 iramc
87 iramd
88 cram2
89 audio_2x a/k/a audio_2x_sync_clk
90 clk_d
91 unassigned
92 sus
93 cdev1
94 cdev2
95 unassigned
96 uart2
97 vfir
98 spdif_in
99 spdif_out
100 vi
101 vi_sensor
102 tvo
103 cve
104 osc
105 clk_32k a/k/a clk_s
106 clk_m
107 sclk
108 cclk
109 hclk
110 pclk
111 blink
112 pll_a
113 pll_a_out0
114 pll_c
115 pll_c_out1
116 pll_d
117 pll_d_out0
118 pll_e
119 pll_m
120 pll_m_out1
121 pll_p
122 pll_p_out1
123 pll_p_out2
124 pll_p_out3
125 pll_p_out4
126 pll_s
127 pll_u
128 pll_x
129 cop a/k/a avp
130 audio a/k/a audio_sync_clk
Example SoC include file:
/ {
tegra_car: clock@60006000 {
compatible = "nvidia,tegra20-car";
reg = <0x60006000 0x1000>;
#clock-cells = <1>;
};
usb@c5004000 {
clocks = <&tegra_car 58>; /* usb2 */
};
};
Example board file:
/ {
clocks {
#address-cells = <1>;
#size-cells = <0>;
osc: clock {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <12000000>;
};
};
i2c@7000d000 {
pmic@34 {
compatible = "ti,tps6586x";
reg = <0x34>;
clk_32k: clock {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <32768>;
};
};
};
&tegra_car {
clocks = <&clk_32k> <&osc>;
};
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/clock/rockchip,rk3188-cru.txt
+61
View File
@@ -0,0 +1,61 @@
* Rockchip RK3188/RK3066 Clock and Reset Unit
The RK3188/RK3066 clock controller generates and supplies clock to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
Required Properties:
- compatible: should be "rockchip,rk3188-cru", "rockchip,rk3188a-cru" or
"rockchip,rk3066a-cru"
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.
- #reset-cells: should be 1.
Optional Properties:
- rockchip,grf: phandle to the syscon managing the "general register files"
If missing pll rates are not changable, due to the missing pll lock status.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as
preprocessor macros in the dt-bindings/clock/rk3188-cru.h and
dt-bindings/clock/rk3066-cru.h headers and can be used in device tree sources.
Similar macros exist for the reset sources in these files.
External clocks:
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names:
- "xin24m" - crystal input - required,
- "xin32k" - rtc clock - optional,
- "xin27m" - 27mhz crystal input on rk3066 - optional,
- "ext_hsadc" - external HSADC clock - optional,
- "ext_cif0" - external camera clock - optional,
- "ext_rmii" - external RMII clock - optional,
- "ext_jtag" - externalJTAG clock - optional
Example: Clock controller node:
cru: cru@20000000 {
compatible = "rockchip,rk3188-cru";
reg = <0x20000000 0x1000>;
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
};
Example: UART controller node that consumes the clock generated by the clock
controller:
uart0: serial@10124000 {
compatible = "snps,dw-apb-uart";
reg = <0x10124000 0x400>;
interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
reg-shift = <2>;
reg-io-width = <1>;
clocks = <&cru SCLK_UART0>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/clock/rockchip,rk3288-cru.txt
+61
View File
@@ -0,0 +1,61 @@
* Rockchip RK3288 Clock and Reset Unit
The RK3288 clock controller generates and supplies clock to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
Required Properties:
- compatible: should be "rockchip,rk3288-cru"
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.
- #reset-cells: should be 1.
Optional Properties:
- rockchip,grf: phandle to the syscon managing the "general register files"
If missing pll rates are not changable, due to the missing pll lock status.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as
preprocessor macros in the dt-bindings/clock/rk3288-cru.h headers and can be
used in device tree sources. Similar macros exist for the reset sources in
these files.
External clocks:
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names:
- "xin24m" - crystal input - required,
- "xin32k" - rtc clock - optional,
- "ext_i2s" - external I2S clock - optional,
- "ext_hsadc" - external HSADC clock - optional,
- "ext_edp_24m" - external display port clock - optional,
- "ext_vip" - external VIP clock - optional,
- "ext_isp" - external ISP clock - optional,
- "ext_jtag" - external JTAG clock - optional
Example: Clock controller node:
cru: cru@20000000 {
compatible = "rockchip,rk3188-cru";
reg = <0x20000000 0x1000>;
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
};
Example: UART controller node that consumes the clock generated by the clock
controller:
uart0: serial@10124000 {
compatible = "snps,dw-apb-uart";
reg = <0x10124000 0x400>;
interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
reg-shift = <2>;
reg-io-width = <1>;
clocks = <&cru SCLK_UART0>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/clock/rockchip,rk3288-dmc.txt
+155
View File
@@ -0,0 +1,155 @@
Rockchip Dynamic Memory Controller Driver
Required properties:
- compatible: "rockchip,rk3288-dmc", "syscon"
- rockchip,cru: this driver should access cru regs, so need get cru here
- rockchip,grf: this driver should access grf regs, so need get grf here
- rockchip,pmu: this driver should access pmu regs, so need get pmu here
- rockchip,sgrf: this driver should access sgrf regs, so need get sgrf here
- rockchip,noc: this driver should access noc regs, so need get noc here
- reg: dynamic ram protocol controller(PCTL) address and phy controller(PHYCTL) address
- clock: must include clock specifiers corresponding to entries in the clock-names property.
- clock-output-names: from common clock binding to override the default output clock name
Must contain
pclk_ddrupctl0: support clock for access protocol controller registers of channel 0
pclk_publ0: support clock for access phy controller registers of channel 0
pclk_ddrupctl1: support clock for access protocol controller registers of channel 1
pclk_publ1: support clock for access phy controller registers of channel 1
arm_clk: for get arm frequency
-logic-supply: this driver should adjust VDD_LOGIC according to dmc frequency, so need get logic-supply here
-timings:
Must contain
rockchip,odt-disable-freq: if ddr clock frequency low than odt-disable-freq,this driver should disable DDR ODT
rockchip,dll-disable-freq: if ddr clock frequency low than dll-disable-freq,this driver should disable DDR DLL
rockchip,sr-enable-freq: if ddr clock frequency high than sr-enable-freq,this driver should enable the automatic self refresh function
rockchip,pd-enable-freq: if ddr clock frequency high than pd-enable-freq,this driver should enable the automatic power down function
rockchip,auto-self-refresh-cnt: Self Refresh idle period. Memories are placed into Self-Refresh mode if the NIF is idle in Access state for auto-self-refresh-cnt * 32 * n_clk cycles.The automatic self refresh function is disabled when auto-self-refresh-cnt=0.
rockchip,auto-power-down-cnt: Power-down idle period. Memories are placed into power-down mode if the NIF is idle for auto-power-down-cnt n_clk cycles.The automatic power down function is disabled when auto-power-down-cnt=0.
rockchip,ddr-speed-bin: DDR3 type,AC timing parameters from the memory data-sheet
0.DDR3_800D (5-5-5)
1.DDR3_800E (6-6-6)
2.DDR3_1066E (6-6-6)
3.DDR3_1066F (7-7-7)
4.DDR3_1066G (8-8-8)
5.DDR3_1333F (7-7-7)
6.DDR3_1333G (8-8-8)
7.DDR3_1333H (9-9-9)
8.DDR3_1333J (10-10-10)
9.DDR3_1600G (8-8-8)
10.DDR3_1600H (9-9-9)
11.DDR3_1600J (10-10-10)
12.DDR3_1600K (11-11-11)
13.DDR3_1866J (10-10-10)
14.DDR3_1866K (11-11-11)
15.DDR3_1866L (12-12-12)
16.DDR3_1866M (13-13-13)
17.DDR3_2133K (11-11-11)
18.DDR3_2133L (12-12-12)
19.DDR3_2133M (13-13-13)
20.DDR3_2133N (14-14-14)
21.DDR3_DEFAULT
rockchip,trcd: tRCD,AC timing parameters from the memory data-sheet
rockchip,trp: tRP,AC timing parameters from the memory data-sheet
-rockchip,num-channels: number of SDRAM channels (1 or 2)
-rockchip,pctl-timing: parameters for the SDRAM setup, in this order:
togcnt1u
tinit
trsth
togcnt100n
trefi
tmrd
trfc
trp
trtw
tal
tcl
tcwl
tras
trc
trcd
trrd
trtp
twr
twtr
texsr
txp
txpdll
tzqcs
tzqcsi
tdqs
tcksre
tcksrx
tcke
tmod
trstl
tzqcl
tmrr
tckesr
tdpd
-rockchip,phy-timing: PHY timing information in this order:
dtpr0
dtpr1
dtpr2
mr0..mr3
-rockchip,sdram-channel: SDRAM channel information, each 8 bits. Both channels
will be set up the same. The parameters are in this order:
rank
col
bk
bw
dbw
row_3_4
cs0_row
cs1_row
- rockchip,sdram-params: SDRAM base parameters, in this order:
NOC timing - value for ddrtiming register
NOC activate - value for activate register
ddrconf - value for ddrconf register
DDR frequency in MHz
DRAM type (3=DDR3, 6=LPDDR3)
stride - stride value for soc_con2 register
odt - 1 to enable DDR ODT, 0 to disable
Example:
dmc: dmc@ff610000 {
compatible = "rockchip,rk3288-dmc", "syscon";
rockchip,cru = <&cru>;
rockchip,grf = <&grf>;
rockchip,pmu = <&pmu>;
rockchip,sgrf = <&sgrf>;
rockchip,noc = <&noc>;
reg = <0xff610000 0x3fc
0xff620000 0x294
0xff630000 0x3fc
0xff640000 0x294>;
clocks = <&cru PCLK_DDRUPCTL0>, <&cru PCLK_PUBL0>,
<&cru PCLK_DDRUPCTL1>, <&cru PCLK_PUBL1>,
<&cru ARMCLK>;
clock-names = "pclk_ddrupctl0", "pclk_publ0",
"pclk_ddrupctl1", "pclk_publ1",
"arm_clk";
};
&dmc {
logic-supply = <&vdd_logic>;
timings {
rockchip,odt-disable-freq = <333000000>;
rockchip,dll-disable-freq = <333000000>;
rockchip,sr-enable-freq = <333000000>;
rockchip,pd-enable-freq = <666000000>;
rockchip,auto-self-refresh-cnt = <0>;
rockchip,auto-power-down-cnt = <64>;
rockchip,ddr-speed-bin = <21>;
rockchip,trcd = <10>;
rockchip,trp = <10>;
};
rockchip,num-channels = <2>;
rockchip,pctl-timing = <0x29a 0x1f4 0xc8 0x42 0x4e 0x4 0xea 0xa
0x5 0x0 0xa 0x7 0x19 0x24 0xa 0x7
0x5 0xa 0x5 0x200 0x5 0x10 0x40 0x0
0x1 0x7 0x7 0x4 0xc 0x43 0x100 0x0
0x5 0x0>;
rockchip,phy-timing = <0x48f9aab4 0xea0910 0x1002c200
0xa60 0x40 0x10 0x0>;
rockchip,sdram-channel = /bits/ 8 <0x1 0xa 0x3 0x2 0x1 0x0 0xf 0xf>;
rockchip,sdram-params = <0x30B25564 0x627 3 666000000 3 9 1>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/clock/rockchip,rk3368-dmc.txt
+67
View File
@@ -0,0 +1,67 @@
RK3368 dynamic memory controller driver
=======================================
The RK3368 DMC (dynamic memory controller) driver supports setup/initialisation
during TPL using configuration data from the DTS (i.e. OF_PLATDATA), based on
the following key configuration data:
(a) a target-frequency (i.e. operating point) for the memory operation
(b) a speed-bin (as defined in JESD-79) for the DDR3 used in hardware
(c) a memory-schedule (i.e. mapping from physical addresses to the address
pins of the memory bus)
Required properties
-------------------
- compatible: "rockchip,rk3368-dmc"
- reg
protocol controller (PCTL) address and PHY controller (DDRPHY) address
- rockchip,ddr-speed-bin
the DDR3 device's speed-bin (as specified according to JESD-79)
DDR3_800D (5-5-5)
DDR3_800E (6-6-6)
DDR3_1066E (6-6-6)
DDR3_1066F (7-7-7)
DDR3_1066G (8-8-8)
DDR3_1333F (7-7-7)
DDR3_1333G (8-8-8)
DDR3_1333H (9-9-9)
DDR3_1333J (10-10-10)
DDR3_1600G (8-8-8)
DDR3_1600H (9-9-9)
DDR3_1600J (10-10-10)
DDR3_1600K (11-11-11)
DDR3_1866J (10-10-10)
DDR3_1866K (11-11-11)
DDR3_1866L (12-12-12)
DDR3_1866M (13-13-13)
DDR3_2133K (11-11-11)
DDR3_2133L (12-12-12)
DDR3_2133M (13-13-13)
DDR3_2133N (14-14-14)
- rockchip,ddr-frequency:
target DDR clock frequency in Hz (not all frequencies may be supported,
as there's some cooperation from the clock-driver required)
- rockchip,memory-schedule:
controls the decoding of physical addresses to DRAM addressing (i.e. how
the physical address maps onto the address pins/chip-select of the device)
DMC_MSCH_CBDR: column -> bank -> device -> row
DMC_MSCH_CBRD: column -> band -> row -> device
DMC_MSCH_CRBD: column -> row -> band -> device
Example (for DDR3-1600K and 800MHz)
-----------------------------------
#include <dt-bindings/memory/rk3368-dmc.h>
dmc: dmc@ff610000 {
u-boot,dm-pre-reloc;
compatible = "rockchip,rk3368-dmc";
reg = <0 0xff610000 0 0x400
0 0xff620000 0 0x400>;
};
&dmc {
rockchip,ddr-speed-bin = <DDR3_1600K>;
rockchip,ddr-frequency = <800000000>;
rockchip,memory-schedule = <DMC_MSCH_CBRD>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/clock/rockchip,rk3399-dmc.txt
+42
View File
@@ -0,0 +1,42 @@
Rockchip Dynamic Memory Controller Driver
Required properties:
- compatible: "rockchip,rk3399-dmc", "syscon"
- rockchip,cru: this driver should access cru regs, so need get cru here
- rockchip,pmucru: this driver should access pmucru regs, so need get pmucru here
- rockchip,pmugrf: this driver should access pmugrf regs, so need get pmugrf here
- rockchip,pmusgrf: this driver should access pmusgrf regs, so need get pmusgrf here
- rockchip,cic: this driver should access cic regs, so need get cic here
- reg: dynamic ram protocol controller(PCTL) address, PHY Independent(PI) address, phy controller(PHYCTL) address and memory schedule(MSCH) address
- clock: must include clock specifiers corresponding to entries in the clock-names property.
Must contain
dmc_clk: for ddr working frequency
- rockchip,sdram-params: SDRAM parameters, including all the information by ddr driver:
Must contain
Genarate by vendor tool and adjust for U-Boot dtsi.
Example:
dmc: dmc {
u-boot,dm-pre-reloc;
compatible = "rockchip,rk3399-dmc";
devfreq-events = <&dfi>;
interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH 0>;
clocks = <&cru SCLK_DDRCLK>;
clock-names = "dmc_clk";
reg = <0x0 0xffa80000 0x0 0x0800
0x0 0xffa80800 0x0 0x1800
0x0 0xffa82000 0x0 0x2000
0x0 0xffa84000 0x0 0x1000
0x0 0xffa88000 0x0 0x0800
0x0 0xffa88800 0x0 0x1800
0x0 0xffa8a000 0x0 0x2000
0x0 0xffa8c000 0x0 0x1000>;
};
&dmc {
rockchip,sdram-params = <
0x2
0xa
0x3
...
>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/clock/rockchip.txt
+77
View File
@@ -0,0 +1,77 @@
Device Tree Clock bindings for arch-rockchip
This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
== Gate clocks ==
These bindings are deprecated!
Please use the soc specific CRU bindings instead.
The gate registers form a continuos block which makes the dt node
structure a matter of taste, as either all gates can be put into
one gate clock spanning all registers or they can be divided into
the 10 individual gates containing 16 clocks each.
The code supports both approaches.
Required properties:
- compatible : "rockchip,rk2928-gate-clk"
- reg : shall be the control register address(es) for the clock.
- #clock-cells : from common clock binding; shall be set to 1
- clock-output-names : the corresponding gate names that the clock controls
- clocks : should contain the parent clock for each individual gate,
therefore the number of clocks elements should match the number of
clock-output-names
Example using multiple gate clocks:
clk_gates0: gate-clk@200000d0 {
compatible = "rockchip,rk2928-gate-clk";
reg = <0x200000d0 0x4>;
clocks = <&dummy>, <&dummy>,
<&dummy>, <&dummy>,
<&dummy>, <&dummy>,
<&dummy>, <&dummy>,
<&dummy>, <&dummy>,
<&dummy>, <&dummy>,
<&dummy>, <&dummy>,
<&dummy>, <&dummy>;
clock-output-names =
"gate_core_periph", "gate_cpu_gpll",
"gate_ddrphy", "gate_aclk_cpu",
"gate_hclk_cpu", "gate_pclk_cpu",
"gate_atclk_cpu", "gate_i2s0",
"gate_i2s0_frac", "gate_i2s1",
"gate_i2s1_frac", "gate_i2s2",
"gate_i2s2_frac", "gate_spdif",
"gate_spdif_frac", "gate_testclk";
#clock-cells = <1>;
};
clk_gates1: gate-clk@200000d4 {
compatible = "rockchip,rk2928-gate-clk";
reg = <0x200000d4 0x4>;
clocks = <&xin24m>, <&xin24m>,
<&xin24m>, <&dummy>,
<&dummy>, <&xin24m>,
<&xin24m>, <&dummy>,
<&xin24m>, <&dummy>,
<&xin24m>, <&dummy>,
<&xin24m>, <&dummy>,
<&xin24m>, <&dummy>;
clock-output-names =
"gate_timer0", "gate_timer1",
"gate_timer2", "gate_jtag",
"gate_aclk_lcdc1_src", "gate_otgphy0",
"gate_otgphy1", "gate_ddr_gpll",
"gate_uart0", "gate_frac_uart0",
"gate_uart1", "gate_frac_uart1",
"gate_uart2", "gate_frac_uart2",
"gate_uart3", "gate_frac_uart3";
#clock-cells = <1>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/clock/snps,hsdk-cgu.txt
+35
View File
@@ -0,0 +1,35 @@
* Synopsys HSDK clock generation unit
The Synopsys HSDK clock controller generates and supplies clock to various
controllers and peripherals within the SoC.
Required Properties:
- compatible: should be "snps,hsdk-cgu-clock"
- reg: the pair of physical base address and length of clock generation unit
memory mapped region and creg arc core divider memory mapped region.
- #clock-cells: should be 1.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as
preprocessor macros in the dt-bindings/clock/snps,hsdk-cgu.h headers and can be
used in device tree sources.
Example: Clock controller node:
cgu_clk: cgu-clk@f0000000 {
compatible = "snps,hsdk-cgu-clock";
reg = <0xf0000000 0x1000>, <0xf00014B8 0x4>;
#clock-cells = <1>;
};
Example: UART controller node that consumes the clock generated by the clock
controller:
uart0: serial0@f0005000 {
compatible = "snps,dw-apb-uart";
reg = <0xf0005000 0x1000>;
reg-shift = <2>;
reg-io-width = <4>;
clocks = <&cgu_clk CLK_SYS_UART_REF>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/clock/st,stm32-rcc.txt
+95
View File
@@ -0,0 +1,95 @@
STMicroelectronics STM32 Reset and Clock Controller
===================================================
The RCC IP is both a reset and a clock controller.
Please refer to clock-bindings.txt for common clock controller binding usage.
Please also refer to reset.txt for common reset controller binding usage.
Required properties:
- compatible: Should be:
"st,stm32f42xx-rcc"
"st,stm32f469-rcc"
- reg: should be register base and length as documented in the
datasheet
- #reset-cells: 1, see below
- #clock-cells: 2, device nodes should specify the clock in their "clocks"
property, containing a phandle to the clock device node, an index selecting
between gated clocks and other clocks and an index specifying the clock to
use.
Example:
rcc: rcc@40023800 {
#reset-cells = <1>;
#clock-cells = <2>
compatible = "st,stm32f42xx-rcc", "st,stm32-rcc";
reg = <0x40023800 0x400>;
};
Specifying gated clocks
=======================
The primary index must be set to 0.
The secondary index is the bit number within the RCC register bank, starting
from the first RCC clock enable register (RCC_AHB1ENR, address offset 0x30).
It is calculated as: index = register_offset / 4 * 32 + bit_offset.
Where bit_offset is the bit offset within the register (LSB is 0, MSB is 31).
To simplify the usage and to share bit definition with the reset and clock
drivers of the RCC IP, macros are available to generate the index in
human-readble format.
For STM32F4 series, the macro are available here:
- include/dt-bindings/mfd/stm32f4-rcc.h
Example:
/* Gated clock, AHB1 bit 0 (GPIOA) */
... {
clocks = <&rcc 0 STM32F4_AHB1_CLOCK(GPIOA)>
};
/* Gated clock, AHB2 bit 4 (CRYP) */
... {
clocks = <&rcc 0 STM32F4_AHB2_CLOCK(CRYP)>
};
Specifying other clocks
=======================
The primary index must be set to 1.
The secondary index is bound with the following magic numbers:
0 SYSTICK
1 FCLK
Example:
/* Misc clock, FCLK */
... {
clocks = <&rcc 1 STM32F4_APB1_CLOCK(TIM2)>
};
Specifying softreset control of devices
=======================================
Device nodes should specify the reset channel required in their "resets"
property, containing a phandle to the reset device node and an index specifying
which channel to use.
The index is the bit number within the RCC registers bank, starting from RCC
base address.
It is calculated as: index = register_offset / 4 * 32 + bit_offset.
Where bit_offset is the bit offset within the register.
For example, for CRC reset:
crc = AHB1RSTR_offset / 4 * 32 + CRCRST_bit_offset = 0x10 / 4 * 32 + 12 = 140
example:
timer2 {
resets = <&rcc STM32F4_APB1_RESET(TIM2)>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/clock/st,stm32h7-rcc.txt
+152
View File
@@ -0,0 +1,152 @@
STMicroelectronics STM32H7 Reset and Clock Controller
=====================================================
The RCC IP is both a reset and a clock controller.
Please refer to clock-bindings.txt for common clock controller binding usage.
Please also refer to reset.txt for common reset controller binding usage.
Required properties:
- compatible: Should be:
"st,stm32h743-rcc"
- reg: should be register base and length as documented in the
datasheet
- #reset-cells: 1, see below
- #clock-cells : from common clock binding; shall be set to 1
- clocks: External oscillator clock phandle
- high speed external clock signal (HSE)
- low speed external clock signal (LSE)
- external I2S clock (I2S_CKIN)
- st,syscfg: phandle for pwrcfg, mandatory to disable/enable backup domain
write protection (RTC clock).
- pll x node: Allow to register a pll with specific parameters.
Please see PLL section below.
Example:
rcc: rcc@58024400 {
#reset-cells = <1>;
#clock-cells = <2>
compatible = "st,stm32h743-rcc", "st,stm32-rcc";
reg = <0x58024400 0x400>;
clocks = <&clk_hse>, <&clk_lse>, <&clk_i2s_ckin>;
st,syscfg = <&pwrcfg>;
#address-cells = <1>;
#size-cells = <0>;
vco1@58024430 {
#clock-cells = <0>;
compatible = "stm32,pll";
reg = <0>;
};
vco2@58024438 {
#clock-cells = <0>;
compatible = "stm32,pll";
reg = <1>;
st,clock-div = <2>;
st,clock-mult = <40>;
st,frac-status = <0>;
st,frac = <0>;
st,vcosel = <1>;
st,pllrge = <2>;
};
};
STM32H7 PLL
-----------
The VCO of STM32 PLL could be reprensented like this:
Vref --------- --------
---->| / DIVM |---->| x DIVN | ------> VCO
--------- --------
^
|
-------
| FRACN |
-------
When the PLL is configured in integer mode:
- VCO = ( Vref / DIVM ) * DIVN
When the PLL is configured in fractional mode:
- VCO = ( Vref / DIVM ) * ( DIVN + FRACN / 2^13)
Required properties for pll node:
- compatible: Should be:
"stm32,pll"
- #clock-cells: from common clock binding; shall be set to 0
- reg: Should be the pll number.
Optional properties:
- st,clock-div: DIVM division factor : <1..63>
- st,clock-mult: DIVN multiplication factor : <4..512>
- st,frac-status:
- 0 Pll is configured in integer mode
- 1 Pll is configure in fractional mode
- st,frac: Fractional part of the multiplication factor : <0..8191>
- st,vcosel: VCO selection
- 0: Wide VCO range:192 to 836 MHz
- 1: Medium VCO range:150 to 420 MHz
- st,pllrge: PLL input frequency range
- 0: The PLL input (Vref / DIVM) clock range frequency is between 1 and 2 MHz
- 1: The PLL input (Vref / DIVM) clock range frequency is between 2 and 4 MHz
- 2: The PLL input (Vref / DIVM) clock range frequency is between 4 and 8 MHz
- 3: The PLL input (Vref / DIVM) clock range frequency is between 8 and 16 MHz
The peripheral clock consumer should specify the desired clock by
having the clock ID in its "clocks" phandle cell.
All available clocks are defined as preprocessor macros in
dt-bindings/clock/stm32h7-clks.h header and can be used in device
tree sources.
Example:
timer5: timer@40000c00 {
compatible = "st,stm32-timer";
reg = <0x40000c00 0x400>;
interrupts = <50>;
clocks = <&rcc TIM5_CK>;
};
Specifying softreset control of devices
=======================================
Device nodes should specify the reset channel required in their "resets"
property, containing a phandle to the reset device node and an index specifying
which channel to use.
The index is the bit number within the RCC registers bank, starting from RCC
base address.
It is calculated as: index = register_offset / 4 * 32 + bit_offset.
Where bit_offset is the bit offset within the register.
For example, for CRC reset:
crc = AHB4RSTR_offset / 4 * 32 + CRCRST_bit_offset = 0x88 / 4 * 32 + 19 = 1107
All available preprocessor macros for reset are defined dt-bindings//mfd/stm32h7-rcc.h
header and can be used in device tree sources.
example:
timer2 {
resets = <&rcc STM32H7_APB1L_RESET(TIM2)>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/clock/st,stm32mp1.txt
+377
View File
@@ -0,0 +1,377 @@
STMicroelectronics STM32MP1 clock tree initialization
=====================================================
The STM32MP1 clock tree initialization is based on device tree information
for RCC IP node (st,stm32mp1-rcc) and on fixed-clock nodes.
RCC IP = st,stm32mp1-rcc
========================
The RCC IP is both a reset and a clock controller but this documentation only
describes the fields added for clock tree initialization which are not present
in Linux binding for compatible "st,stm32mp1-rcc" defined in st,stm32mp1-rcc.txt
file.
The added properties for clock tree initialization are:
Required properties:
- st,clksrc : The clock sources configuration array in a platform specific
order.
For the STM32MP15x family there are 9 clock sources selector which are
configured in the following order:
MPU AXI MCU PLL12 PLL3 PLL4 RTC MCO1 MCO2
Clock source configuration values are defined by macros CLK_<NAME>_<SOURCE>
from dt-bindings/clock/stm32mp1-clksrc.h.
Example:
st,clksrc = <
CLK_MPU_PLL1P
CLK_AXI_PLL2P
CLK_MCU_PLL3P
CLK_PLL12_HSE
CLK_PLL3_HSE
CLK_PLL4_HSE
CLK_RTC_LSE
CLK_MCO1_DISABLED
CLK_MCO2_DISABLED
>;
- st,clkdiv : The clock main dividers value specified in an array
in a platform specific order.
When used, it shall describe the whole clock dividers tree.
For the STM32MP15x family there are 11 dividers values expected.
They shall be configured in the following order:
MPU AXI MCU APB1 APB2 APB3 APB4 APB5 RTC MCO1 MCO2
The each divider value uses the DIV coding defined in RCC associated
register RCC_xxxDIVR. In most the case, it is:
0x0: not divided
0x1: division by 2
0x2: division by 4
0x3: division by 8
...
Note that for RTC MCO1 MCO2, the coding is different:
0x0: not divided
0x1: division by 2
0x2: division by 3
0x3: division by 4
...
Example:
st,clkdiv = <
1 /*MPU*/
0 /*AXI*/
0 /*MCU*/
1 /*APB1*/
1 /*APB2*/
1 /*APB3*/
1 /*APB4*/
2 /*APB5*/
23 /*RTC*/
0 /*MCO1*/
0 /*MCO2*/
>;
Optional Properties:
- st,pll : A specific PLL configuration, including frequency.
PLL children nodes for PLL1 to PLL4 (see ref manual for details)
are listed with associated index 0 to 3 (st,pll@0 to st,pll@3).
PLLx is off when the associated node is absent.
Here are the available properties for each PLL node:
- cfg: The parameters for PLL configuration in the following order:
DIVM DIVN DIVP DIVQ DIVR Output.
DIVx values are defined as in RCC spec:
0x0: bypass (division by 1)
0x1: division by 2
0x2: division by 3
0x3: division by 4
...
Output contains a bitfield for each output value (1:ON/0:OFF)
BIT(0) => output P : DIVPEN
BIT(1) => output Q : DIVQEN
BIT(2) => output R : DIVREN
NB: macro PQR(p,q,r) can be used to build this value
with p,q,r = 0 or 1.
- frac : Fractional part of the multiplication factor
(optional, PLL is in integer mode when absent).
- csg : Clock Spreading Generator (optional) with parameters in the
following order: MOD_PER INC_STEP SSCG_MODE.
MOD_PER: Modulation Period Adjustment
INC_STEP: Modulation Depth Adjustment
SSCG_MODE: Spread spectrum clock generator mode, with associated
defined from stm32mp1-clksrc.h:
- SSCG_MODE_CENTER_SPREAD = 0
- SSCG_MODE_DOWN_SPREAD = 1
Example:
st,pll@0 {
cfg = < 1 53 0 0 0 1 >;
frac = < 0x810 >;
};
st,pll@1 {
cfg = < 1 43 1 0 0 PQR(0,1,1) >;
csg = < 10 20 1 >;
};
st,pll@2 {
cfg = < 2 85 3 13 3 0 >;
csg = < 10 20 SSCG_MODE_CENTER_SPREAD >;
};
st,pll@3 {
cfg = < 2 78 4 7 9 3 >;
};
- st,pkcs : used to configure the peripherals kernel clock selection.
The property is a list of peripheral kernel clock source identifiers defined
by macros CLK_<KERNEL-CLOCK>_<PARENT-CLOCK> as defined by header file
dt-bindings/clock/stm32mp1-clksrc.h.
st,pkcs may not list all the kernel clocks and has no ordering requirements.
Example:
st,pkcs = <
CLK_STGEN_HSE
CLK_CKPER_HSI
CLK_USBPHY_PLL2P
CLK_DSI_PLL2Q
CLK_I2C46_HSI
CLK_UART1_HSI
CLK_UART24_HSI
>;
other clocks = fixed-clock
==========================
The clock tree is also based on 5 fixed-clock in clocks node
used to define the state of associated ST32MP1 oscillators:
- clk-lsi
- clk-lse
- clk-hsi
- clk-hse
- clk-csi
At boot the clock tree initialization will
- enable oscillators present in device tree and not disabled
(node with status="disabled"),
- disable HSI oscillator if the node is absent (always activated by bootrom)
and not disabled (node with status="disabled").
Optional properties :
a) for external oscillator: "clk-lse", "clk-hse"
4 optional fields are managed
- "st,bypass" configures the oscillator bypass mode (HSEBYP, LSEBYP)
- "st,digbypass" configures the bypass mode as full-swing digital
signal (DIGBYP)
- "st,css" activates the clock security system (HSECSSON, LSECSSON)
- "st,drive" (only for LSE) contains the value of the drive for the
oscillator (see LSEDRV_ defined in the file
dt-bindings/clock/stm32mp1-clksrc.h)
Example board file:
/ {
clocks {
clk_hse: clk-hse {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <64000000>;
st,bypass;
};
clk_lse: clk-lse {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <32768>;
st,css;
st,drive = <LSEDRV_LOWEST>;
};
};
b) for internal oscillator: "clk-hsi"
Internally HSI clock is fixed to 64MHz for STM32MP157 SoC.
In device tree, clk-hsi is the clock after HSIDIV (clk_hsi in RCC
doc). So this clock frequency is used to compute the expected HSI_DIV
for the clock tree initialization.
Example with HSIDIV = /1:
/ {
clocks {
clk_hsi: clk-hsi {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <64000000>;
};
};
Example with HSIDIV = /2
/ {
clocks {
clk_hsi: clk-hsi {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <32000000>;
};
};
Example of clock tree initialization
====================================
/ {
clocks {
u-boot,dm-pre-reloc;
clk_hse: clk-hse {
u-boot,dm-pre-reloc;
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <24000000>;
st,digbypass;
};
clk_hsi: clk-hsi {
u-boot,dm-pre-reloc;
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <64000000>;
};
clk_lse: clk-lse {
u-boot,dm-pre-reloc;
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <32768>;
};
clk_lsi: clk-lsi {
u-boot,dm-pre-reloc;
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <32000>;
};
clk_csi: clk-csi {
u-boot,dm-pre-reloc;
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <4000000>;
};
};
soc {
rcc: rcc@50000000 {
u-boot,dm-pre-reloc;
compatible = "st,stm32mp1-rcc", "syscon";
reg = <0x50000000 0x1000>;
#clock-cells = <1>;
#reset-cells = <1>;
interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
st,clksrc = <
CLK_MPU_PLL1P
CLK_AXI_PLL2P
CLK_MCU_PLL3P
CLK_PLL12_HSE
CLK_PLL3_HSE
CLK_PLL4_HSE
CLK_RTC_LSE
CLK_MCO1_DISABLED
CLK_MCO2_DISABLED
>;
st,clkdiv = <
1 /*MPU*/
0 /*AXI*/
0 /*MCU*/
1 /*APB1*/
1 /*APB2*/
1 /*APB3*/
1 /*APB4*/
2 /*APB5*/
23 /*RTC*/
0 /*MCO1*/
0 /*MCO2*/
>;
st,pkcs = <
CLK_CKPER_HSE
CLK_FMC_ACLK
CLK_QSPI_ACLK
CLK_ETH_DISABLED
CLK_SDMMC12_PLL4P
CLK_DSI_DSIPLL
CLK_STGEN_HSE
CLK_USBPHY_HSE
CLK_SPI2S1_PLL3Q
CLK_SPI2S23_PLL3Q
CLK_SPI45_HSI
CLK_SPI6_HSI
CLK_I2C46_HSI
CLK_SDMMC3_PLL4P
CLK_USBO_USBPHY
CLK_ADC_CKPER
CLK_CEC_LSE
CLK_I2C12_HSI
CLK_I2C35_HSI
CLK_UART1_HSI
CLK_UART24_HSI
CLK_UART35_HSI
CLK_UART6_HSI
CLK_UART78_HSI
CLK_SPDIF_PLL4P
CLK_FDCAN_PLL4Q
CLK_SAI1_PLL3Q
CLK_SAI2_PLL3Q
CLK_SAI3_PLL3Q
CLK_SAI4_PLL3Q
CLK_RNG1_LSI
CLK_RNG2_LSI
CLK_LPTIM1_PCLK1
CLK_LPTIM23_PCLK3
CLK_LPTIM45_LSE
>;
/* VCO = 1300.0 MHz => P = 650 (CPU) */
pll1: st,pll@0 {
cfg = < 2 80 0 0 0 PQR(1,0,0) >;
frac = < 0x800 >;
u-boot,dm-pre-reloc;
};
/* VCO = 1066.0 MHz => P = 266 (AXI), Q = 533 (GPU),
R = 533 (DDR) */
pll2: st,pll@1 {
cfg = < 2 65 1 0 0 PQR(1,1,1) >;
frac = < 0x1400 >;
u-boot,dm-pre-reloc;
};
/* VCO = 417.8 MHz => P = 209, Q = 24, R = 11 */
pll3: st,pll@2 {
cfg = < 1 33 1 16 36 PQR(1,1,1) >;
frac = < 0x1a04 >;
u-boot,dm-pre-reloc;
};
/* VCO = 594.0 MHz => P = 99, Q = 74, R = 74 */
pll4: st,pll@3 {
cfg = < 3 98 5 7 7 PQR(1,1,1) >;
u-boot,dm-pre-reloc;
};
};
};
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/clock/ti,cdce9xx.txt
+49
View File
@@ -0,0 +1,49 @@
Binding for TI CDCE913/925/937/949 programmable I2C clock synthesizers.
Reference
This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
[2] http://www.ti.com/product/cdce913
[3] http://www.ti.com/product/cdce925
[4] http://www.ti.com/product/cdce937
[5] http://www.ti.com/product/cdce949
The driver provides clock sources for each output Y1 through Y5.
Required properties:
- compatible: Shall be one of the following:
- "ti,cdce913": 1-PLL, 3 Outputs
- "ti,cdce925": 2-PLL, 5 Outputs
- "ti,cdce937": 3-PLL, 7 Outputs
- "ti,cdce949": 4-PLL, 9 Outputs
- reg: I2C device address.
- clocks: Points to a fixed parent clock that provides the input frequency.
- #clock-cells: From common clock bindings: Shall be 1.
Optional properties:
- xtal-load-pf: Crystal load-capacitor value to fine-tune performance on a
board, or to compensate for external influences.
For all PLL1, PLL2, ... an optional child node can be used to specify spread
spectrum clocking parameters for a board.
- spread-spectrum: SSC mode as defined in the data sheet.
- spread-spectrum-center: Use "centered" mode instead of "max" mode. When
present, the clock runs at the requested frequency on average. Otherwise
the requested frequency is the maximum value of the SCC range.
Example:
clockgen: cdce925pw@64 {
compatible = "cdce925";
reg = <0x64>;
clocks = <&xtal_27Mhz>;
#clock-cells = <1>;
xtal-load-pf = <5>;
/* PLL options to get SSC 1% centered */
PLL2 {
spread-spectrum = <4>;
spread-spectrum-center;
};
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/clock/ti,sci-clk.txt
+53
View File
@@ -0,0 +1,53 @@
Texas Instruments TI SCI Clock Controller
=========================================
All clocks on Texas Instruments' SoCs that contain a System Controller,
are only controlled by this entity. Communication between a host processor
running an OS and the System Controller happens through a protocol known
as TI SCI[1]. This clock implementation plugs into the common clock
framework and makes use of the TI SCI protocol on clock API requests.
[1] http://processors.wiki.ti.com/index.php/TISCI
Clock Controller Node
=====================
The clock controller node represents the clocks managed by the SYSFW. Because
this relies on the TI SCI protocol to communicate with the SYSFW it must be a
child of the sysfw node.
Required Properties:
--------------------
- compatible: Must be "ti,k2g-sci-clk"
- #clock-cells: Must be be 2. In clock consumers, this cell represents the
device ID and clock ID exposed by the SYSFW firmware.
Example (AM65x):
----------------
dmsc: dmsc {
compatible = "ti,k2g-sci";
...
k3_clks: clocks {
compatible = "ti,k2g-sci-clk";
#clock-cells = <2>;
};
};
Clock Consumers
===============
Hardware blocks supplied by a clock should contain a "clocks" property that is
a phandle pointing to the clock controller node along with an index representing
the device id together with a clock ID to be passed to the SYSFW for device
control.
Required Properties:
--------------------
- clocks: phandle pointing to the corresponding clock node, an ID representing
the device, and an index representing a clock.
Example (AM65x):
----------------
uart2: serial@02800000 {
compatible = "ti,omap4-uart";
...
clocks = <&k3_clks 0x0007 1>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/config.txt
+54
View File
@@ -0,0 +1,54 @@
The /config node (Configuration Options)
----------------------------------------
A number of run-time configuration options are provided in the /config node
of the control device tree. You can access these using fdtdec_get_config_int(),
fdtdec_get_config_bool() and fdtdec_get_config_string().
Available options are:
silent-console
If present and non-zero, the console is silenced by default on boot.
no-keyboard
Tells U-Boot not to expect an attached keyboard with a VGA console
u-boot,efi-partition-entries-offset
If present, this provides an offset (in bytes, from the start of a
device) that should be skipped over before the partition entries.
This is used by the EFI/GPT partition implementation when a device
is formatted.
This setting will override any values configured via Kconfig.
u-boot,mmc-env-partition
if present, the environment shall be placed at the last
CONFIG_ENV_SIZE blocks of the partition on the
CONFIG_SYS_MMC_ENV_DEV.
if u-boot,mmc-env-offset* is present, this setting will take
precedence. In that case, only if the partition is not found,
mmc-env-offset* will be tried.
u-boot,mmc-env-offset
u-boot,mmc-env-offset-redundant
If present, the values of the 'u-boot,mmc-env-offset' and/or
of the u-boot,mmc-env-offset-redundant' properties overrides
CONFIG_ENV_OFFSET and CONFIG_ENV_OFFSET_REDUND, respectively,
for SD/MMC devices.
Values are interpreted as the offset from the start of the
device, specified in bytes. It is assumed that the setting
will point at the beginning of a LBA and values that are not
LBA-aligned will be rounded up to the next LBA address.
u-boot,spl-payload-offset
If present (and SPL is controlled by the device-tree), this allows
to override the CONFIG_SYS_SPI_U_BOOT_OFFS setting using a value
from the device-tree.
sysreset-gpio
If present (and supported by the specific board), indicates a
GPIO that can be set to trigger a system reset. It is assumed
that such a system reset will effect a complete platform reset,
being roughly equivalent to a power-on reset.
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/cpu/fsl,mpc83xx.txt
+34
View File
@@ -0,0 +1,34 @@
MPC83xx CPU devices
MPC83xx SoCs contain a e300 core as their main processor.
Required properties:
- compatible: must be one of "fsl,mpc83xx",
"fsl,mpc8308",
"fsl,mpc8309",
"fsl,mpc8313",
"fsl,mpc8315",
"fsl,mpc832x",
"fsl,mpc8349",
"fsl,mpc8360",
"fsl,mpc8379"
- clocks: has to have two entries, which must be the core clock at index 0 and
the CSB (Coherent System Bus) clock at index 1. Both are given by a suitable
"fsl,mpc83xx-clk" device
Example:
socclocks: clocks {
compatible = "fsl,mpc8315-clk";
#clock-cells = <1>;
};
cpus {
compatible = "cpu_bus";
PowerPC,8315@0 {
compatible = "fsl,mpc8315";
clocks = <&socclocks MPC83XX_CLK_CORE
&socclocks MPC83XX_CLK_CSB>;
};
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/cpu/nios2.txt
+54
View File
@@ -0,0 +1,54 @@
* Nios II Processor Binding
This binding specifies what properties available in the device tree
representation of a Nios II Processor Core.
Users can use sopc2dts tool for generating device tree sources (dts) from a
Qsys system. See more detail in: http://www.alterawiki.com/wiki/Sopc2dts
Required properties:
- compatible: Compatible property value should be "altr,nios2-1.0" or
"altr,nios2-1.1".
- reg: Contains CPU index.
- clock-frequency: Contains the clock frequency for CPU, in Hz.
- dcache-line-size: Contains data cache line size.
- icache-line-size: Contains instruction line size.
- dcache-size: Contains data cache size.
- icache-size: Contains instruction cache size.
- altr,reset-addr: Specifies CPU reset address
- altr,exception-addr: Specifies CPU exception address
Optional properties:
- altr,has-initda: Specifies CPU support initda instruction, should be 1.
- altr,has-mmu: Specifies CPU support MMU support.
- altr,has-mul: Specifies CPU hardware multipy support.
- altr,has-div: Specifies CPU hardware divide support
- altr,implementation: Nios II core implementation, this should be "fast";
Example:
cpu@0x0 {
device_type = "cpu";
compatible = "altr,nios2-1.0";
reg = <0>;
interrupt-controller;
#interrupt-cells = <1>;
clock-frequency = <125000000>;
dcache-line-size = <32>;
icache-line-size = <32>;
dcache-size = <32768>;
icache-size = <32768>;
altr,implementation = "fast";
altr,pid-num-bits = <8>;
altr,tlb-num-ways = <16>;
altr,tlb-num-entries = <128>;
altr,tlb-ptr-sz = <7>;
altr,has-div = <1>;
altr,has-mul = <1>;
altr,reset-addr = <0xc2800000>;
altr,fast-tlb-miss-addr = <0xc7fff400>;
altr,exception-addr = <0xd0000020>;
altr,has-initda = <1>;
altr,has-mmu = <1>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/exynos/dwmmc.txt
+54
View File
@@ -0,0 +1,54 @@
* Exynos DWC_mobile_storage
The Exynos provides DWC_mobile_storage interface which supports
. Embedded Multimedia Cards (EMMC-version 4.5)
. Secure Digital memory (SD mem-version 2.0)
. Secure Digital I/O (SDIO-version 3.0)
. Consumer Electronics Advanced Transport Architecture (CE-ATA-version 1.1)
The Exynos DWC_mobile_storage provides four channels.
SOC specific and Board specific properties are channel specific.
Required SoC Specific Properties:
- compatible: should be
- samsung,exynos-dwmmc: for exynos platforms
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: The interrupt number to the cpu.
Required Board Specific Properties:
- #address-cells: should be 1.
- #size-cells: should be 0.
- samsung,bus-width: The width of the bus used to interface the devices
supported by DWC_mobile_storage (SD-MMC/EMMC/SDIO).
. Typically the bus width is 4 or 8.
- samsung,timing: The timing values to be written into the
Drv/sample clock selection register of corresponding channel.
. It is comprised of 3 values corresponding to the 3 fileds
'SelClk_sample', 'SelClk_drv' and 'DIVRATIO' of CLKSEL register.
. SelClk_sample: Select sample clock among 8 shifted clocks.
. SelClk_drv: Select drv clock among 8 shifted clocks.
. DIVRATIO: Clock Divide ratio select.
. The above 3 values are used by the clock phase shifter.
Example:
mmc@12200000 {
samsung,bus-width = <8>;
samsung,timing = <1 3 3>;
samsung,removable = <1>;
}
In the above example,
. The bus width is 8
. Timing is comprised of 3 values as explained below
1 - SelClk_sample
3 - SelClk_drv
3 - DIVRATIO
. The 'removable' flag indicates whether the the particilar device
cannot be removed (always present) or it is a removable device.
1 - Indicates that the device is removable.
0 - Indicates that the device cannot be removed.
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/exynos/emmc-reset.txt
+15
View File
@@ -0,0 +1,15 @@
* Samsung eMMC reset
Some exynos boards require special handling of nRESET_OUT line for eMMC memory
to perform complete reboot.
Required properties:
- compatible: should be "samsung,emmc-reset"
- reset-gpio: gpio chip for eMMC reset.
Example:
emmc-reset {
compatible = "samsung,emmc-reset";
reset-gpio = <&gpk1 2 0>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/exynos/isp-spi.txt
+22
View File
@@ -0,0 +1,22 @@
Exynos ISP SPI Subsystem
The device node for ISP SPI subsytem.
Since Peripheral id in EXYNOS is decoded based on Interrupts, currently
ISP SPI have no individual interrupts hence we add ad dummy interrupt node
which will have a value beyond the maximum number of interrupts exynos5 can
support.
Required properties :
- compatible : Should be "samsung,exynos-spi" for spi.
- reg : Base adrress of the the subsystem.
- interrupts : A value which is beyond the maximum number of interrupts
exynos5 can support.
Example:
spi@131a0000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "samsung,exynos-spi";
reg = <0x131a0000 0x30>;
interrupts = <0 129 0>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/exynos/soc.txt
+21
View File
@@ -0,0 +1,21 @@
Exynos SoC model
The "cpu-model" property is a non-standard extension for the device tree root
node. Since the cpu id of some Exynos variants does not correspond to product
name, this property fills the gap.
For almost all Exynos based boards in the kernel, the product name corresponds
to the device tree file name. The same name is generated in U-Boot, so the new
property allows doing it automatically.
Required properties:
- cpu-model : Exynos product name
Example:
/ {
model = "Samsung/Google Peach Pi board based on Exynos5800";
cpu-model = "Exynos5800";
compatible = ...
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/exynos/sound.txt
+27
View File
@@ -0,0 +1,27 @@
Exynos Sound Subsystem
The device node for sound subsytem which contains codec and i2s block
that is a part of Exynos5250
Required properties :
- compatible : Should be "samsung,exynos-sound" for sound
- samsung,i2s-epll-clock-frequency : epll clock output frequency in Hz
- samsung,i2s-sampling-rate : sampling rate, default is 48000
- samsung,i2s-bits-per-sample : sample width, defalut is 16 bit
- samsung,i2s-channels : nummber of channels, default is 2
- samsung,i2s-lr-clk-framesize : lr clock frame size
- samsung,i2s-bit-clk-framesize : bit clock frame size
- samsung,codec-type : sound codec type
Example:
sound@12d60000 {
compatible = "samsung,exynos-sound"
samsung,i2s-epll-clock-frequency = <192000000>;
samsung,i2s-sampling-rate = <48000>;
samsung,i2s-bits-per-sample = <16>;
samsung,i2s-channels = <2>;
samsung,i2s-lr-clk-framesize = <256>;
samsung,i2s-bit-clk-framesize = <32>;
samsung,codec-type = "wm8994";
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/exynos/tmu.txt
+44
View File
@@ -0,0 +1,44 @@
Exynos Thermal management Unit
Required properties:
- compatible : Should be "samsung,exynos-tmu" for TMU
- samsung,min-temp : Minimum temperature value (25 degree celsius)
- Current temperature of SoC should be more than this value.
- samsung,max-temp : Maximum temperature value (125 degree celsius)
- Current temperature of SoC should be less than this value.
- samsung,start-warning : Temperature at which TMU starts giving warning (degree celsius)
- samsung,start-tripping : Temperature at which TMU shuts down the system (degree celsius)
- samsung,hw-tripping : Temperature at which hardware tripping should happen
in case TMU fails to power off (degree celsius)
- samsung,efuse-min-value : SOC efuse min value (Constant 40)
- efuse-value should be more than this value.
- samsung,efuse-value : SOC actual efuse value (Literal value)
- This is the data trimming info.
- This value is used to calculate measuring error.
- samsung,efuse-max-value : SoC max efuse value (Constant 100)
- efuse-value should be less than this value.
- samsung,slope : Default value 274761730 (Constant 0x1060_8802).
- This is the default value for TMU_CONTROL register.
- It sets the gain of amplifier to the positive-tc generator block.
- It selects thermal tripping mode and enables thermal tripping.
- samsung,dc-value : Measured data calibration value (Constant 25)
- Used for tempearture calculation.
- This is 25 because temperature measured is always above 25 degrees.
Example:
tmu@10060000 {
compatible = "samsung,exynos-tmu"
samsung,min-temp = <25>;
samsung,max-temp = <125>;
samsung,start-warning = <95>;
samsung,start-tripping = <105>;
samsung,hw-tripping = <110>;
samsung,efuse-min-value = <40>;
samsung,efuse-value = <55>;
samsung,efuse-max-value = <100>;
samsung,slope = <274761730>;
samsung,dc-value = <25>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/firmware/linaro,optee-tz.txt
+31
View File
@@ -0,0 +1,31 @@
OP-TEE Device Tree Bindings
OP-TEE is a piece of software using hardware features to provide a Trusted
Execution Environment. The security can be provided with ARM TrustZone, but
also by virtualization or a separate chip.
We're using "linaro" as the first part of the compatible property for
the reference implementation maintained by Linaro.
* OP-TEE based on ARM TrustZone required properties:
- compatible : should contain "linaro,optee-tz"
- method : The method of calling the OP-TEE Trusted OS. Permitted
values are:
"smc" : SMC #0, with the register assignments specified
in drivers/tee/optee/optee_smc.h
"hvc" : HVC #0, with the register assignments specified
in drivers/tee/optee/optee_smc.h
Example:
firmware {
optee {
compatible = "linaro,optee-tz";
method = "smc";
};
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/firmware/nvidia,tegra186-bpmp.txt
+104
View File
@@ -0,0 +1,104 @@
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:
- name : Should be bpmp
- 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.txt
- <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@03c00000 {
...
#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: bpmp_shmem@4e000 {
compatible = "nvidia,tegra186-bpmp-shmem";
reg = <0x0 0x4e000 0x0 0x1000>;
};
cpu_bpmp_rx: bpmp_shmem@4f000 {
compatible = "nvidia,tegra186-bpmp-shmem";
reg = <0x0 0x4f000 0x0 0x1000>;
};
};
bpmp {
compatible = "nvidia,tegra186-bpmp";
mboxes = <&hsp_top0 HSP_MBOX_TYPE_DB HSP_DB_MASTER_BPMP>;
shmem = <&cpu_bpmp_tx &cpu_bpmp_rx>;
#clock-cells = <1>;
#power-domain-cells = <1>;
#reset-cells = <1>;
i2c {
compatible = "...";
...
};
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/firmware/ti,sci.txt
+76
View File
@@ -0,0 +1,76 @@
Texas Instruments System Control Interface (TI-SCI) Message Protocol
--------------------------------------------------------------------
Texas Instrument's processors including those belonging to Keystone generation
of processors have separate hardware entity which is now responsible for the
management of the System on Chip (SoC) system. These include various system
level functions as well.
An example of such an SoC is K2G, which contains the system control hardware
block called Power Management Micro Controller (PMMC). This hardware block is
initialized early into boot process and provides services to Operating Systems
on multiple processors including ones running Linux.
See http://processors.wiki.ti.com/index.php/TISCI for protocol definition.
TI-SCI controller Device Node:
=============================
The TI-SCI node describes the Texas Instrument's System Controller entity node.
This parent node may optionally have additional children nodes which describe
specific functionality such as clocks, power domain, reset or additional
functionality as may be required for the SoC. This hierarchy also describes the
relationship between the TI-SCI parent node to the child node.
Required properties:
-------------------
- compatible: should be "ti,k2g-sci"
- mbox-names:
"rx" - Mailbox corresponding to receive path
"tx" - Mailbox corresponding to transmit path
- mboxes: Mailboxes corresponding to the mbox-names. Each value of the mboxes
property should contain a phandle to the mailbox controller device
node and an args specifier that will be the phandle to the intended
sub-mailbox child node to be used for communication.
Optional Properties:
-------------------
- reg-names:
debug_messages - Map the Debug message region
- reg: register space corresponding to the debug_messages
- ti,system-reboot-controller: If system reboot can be triggered by SoC reboot
- ti,secure-host: If the host is defined as secure.
Example:
-------------
dmsc: dmsc {
compatible = "ti,k2g-sci";
ti,host-id = <12>;
#address-cells = <1>;
#size-cells = <1>;
ranges;
}
TI-SCI Client Device Node:
=========================
Client nodes are maintained as children of the relevant TI-SCI device node.
Example:
-------------
dmsc: dmsc {
compatible = "ti,k2g-sci";
...
my_clk_node: clk_node {
...
...
};
my_pd_node: pd_node {
...
...
};
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt
+43
View File
@@ -0,0 +1,43 @@
Altera SOCFPGA Arria10 FPGA Manager
Required properties:
- compatible : should contain "altr,socfpga-a10-fpga-mgr"
- reg : base address and size for memory mapped io.
- The first index is for FPGA manager register access.
- The second index is for writing FPGA configuration data.
- resets : Phandle and reset specifier for the device's reset.
- clocks : Clocks used by the device.
- altr,bitstream : Fit image file name for both FPGA peripheral bitstream,
FPGA core bitstream and full bitstream.
Full bitstream, consist of peripheral bitstream and core
bitstream.
FPGA peripheral bitstream is used to initialize FPGA IOs,
PLL, IO48 and DDR. This bitstream is required to get DDR up
running.
FPGA core bitstream contains FPGA design which is used to
program FPGA CRAM and ERAM.
Example: Bundles both peripheral bitstream and core bitstream into FIT image
called fit_spl_fpga.itb. This FIT image can be created through running
this command: tools/mkimage
-E -p 400
-f board/altera/arria10-socdk/fit_spl_fpga.its
fit_spl_fpga.itb
For details of describing structure and contents of the FIT image,
please refer board/altera/arria10-socdk/fit_spl_fpga.its
- Examples for booting with full release or booting with early IO release, then
follow by entering early user mode:
fpga_mgr: fpga-mgr@ffd03000 {
compatible = "altr,socfpga-a10-fpga-mgr";
reg = <0xffd03000 0x100
0xffcfe400 0x20>;
clocks = <&l4_mp_clk>;
resets = <&rst FPGAMGR_RESET>;
altr,bitstream = "fit_spl_fpga.itb";
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/gpio/altera_pio.txt
+28
View File
@@ -0,0 +1,28 @@
Altera GPIO controller bindings
Required properties:
- compatible:
- "altr,pio-1.0"
- reg: Physical base address and length of the controller's registers.
Optional properties:
- altr,gpio-bank-width: Width of the GPIO bank. This defines how many pins the
GPIO device has. Ranges between 1-32. Optional and defaults to 32 if not
specified.
- gpio-bank-name: bank name attached to this device.
Example:
user_led_pio_8out: gpio@0x4cc0 {
compatible = "altr,pio-1.0";
reg = <0x00004cc0 0x00000010>;
resetvalue = <255>;
altr,gpio-bank-width = <8>;
#gpio-cells = <2>;
gpio-controller;
gpio-bank-name = "led";
};
In this example, the gpio can be accessed as led[0..7] using gpio command of
u-boot.
==> gpio clear led0
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/gpio/bcm2835-gpio.txt
+5
View File
@@ -0,0 +1,5 @@
* Broadcom BCM283x GPIO controller
Required properties:
- compatible: must be "brcm,bcm2835-gpio"
- reg: exactly one register range with length 0xb4
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/gpio/gpio-msm.txt
+22
View File
@@ -0,0 +1,22 @@
Qualcomm Snapdragon GPIO controller
Required properties:
- compatible : "qcom,msm8916-pinctrl" or "qcom,apq8016-pinctrl"
- reg : Physical base address and length of the controller's registers.
This controller is called "Top Level Mode Multiplexing" in
Qualcomm documentation.
- #gpio-cells : Should be one (pin number).
- gpio-controller : Marks the device node as a GPIO controller.
- gpio-count: Number of GPIO pins.
- gpio-bank-name: (optional) name of gpio bank. As default "soc" is used.
Example:
soc_gpios: pinctrl@1000000 {
compatible = "qcom,msm8916-pinctrl";
reg = <0x1000000 0x300000>;
gpio-controller;
gpio-count = <122>;
gpio-bank-name="soc";
#gpio-cells = <1>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/gpio/gpio-pcf857x.txt
+71
View File
@@ -0,0 +1,71 @@
* PCF857x-compatible I/O expanders
The PCF857x-compatible chips have "quasi-bidirectional" I/O lines that can be
driven high by a pull-up current source or driven low to ground. This combines
the direction and output level into a single bit per line, which can't be read
back. We can't actually know at initialization time whether a line is configured
(a) as output and driving the signal low/high, or (b) as input and reporting a
low/high value, without knowing the last value written since the chip came out
of reset (if any). The only reliable solution for setting up line direction is
thus to do it explicitly.
Required Properties:
- compatible: should be one of the following.
- "maxim,max7328": For the Maxim MAX7378
- "maxim,max7329": For the Maxim MAX7329
- "nxp,pca8574": For the NXP PCA8574
- "nxp,pca8575": For the NXP PCA8575
- "nxp,pca9670": For the NXP PCA9670
- "nxp,pca9671": For the NXP PCA9671
- "nxp,pca9672": For the NXP PCA9672
- "nxp,pca9673": For the NXP PCA9673
- "nxp,pca9674": For the NXP PCA9674
- "nxp,pca9675": For the NXP PCA9675
- "nxp,pcf8574": For the NXP PCF8574
- "nxp,pcf8574a": For the NXP PCF8574A
- "nxp,pcf8575": For the NXP PCF8575
- "ti,tca9554": For the TI TCA9554
- reg: I2C slave address.
- gpio-controller: Marks the device node as a gpio controller.
- #gpio-cells: Should be 2. The first cell is the GPIO number and the second
cell specifies GPIO flags, as defined in <dt-bindings/gpio/gpio.h>. Only the
GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported.
Optional Properties:
- lines-initial-states: Bitmask that specifies the initial state of each
line. When a bit is set to zero, the corresponding line will be initialized to
the input (pulled-up) state. When the bit is set to one, the line will be
initialized the low-level output state. If the property is not specified
all lines will be initialized to the input state.
The I/O expander can detect input state changes, and thus optionally act as
an interrupt controller. When the expander interrupt line is connected all the
following properties must be set. For more information please see the
interrupt controller device tree bindings documentation available at
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt.
- interrupt-controller: Identifies the node as an interrupt controller.
- #interrupt-cells: Number of cells to encode an interrupt source, shall be 2.
- interrupt-parent: phandle of the parent interrupt controller.
- interrupts: Interrupt specifier for the controllers interrupt.
Please refer to gpio.txt in this directory for details of the common GPIO
bindings used by client devices.
Example: PCF8575 I/O expander node
pcf8575: gpio@20 {
compatible = "nxp,pcf8575";
reg = <0x20>;
interrupt-parent = <&irqpin2>;
interrupts = <3 0>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/gpio/gpio-samsung.txt
+41
View File
@@ -0,0 +1,41 @@
Samsung Exynos4 GPIO Controller
Required properties:
- compatible: Compatible property value should be "samsung,exynos4-gpio>".
- reg: Physical base address of the controller and length of memory mapped
region.
- #gpio-cells: Should be 4. The syntax of the gpio specifier used by client nodes
should be the following with values derived from the SoC user manual.
<[phandle of the gpio controller node]
[pin number within the gpio controller]
[mux function]
[flags and pull up/down]
[drive strength]>
Values for gpio specifier:
- Pin number: is a value between 0 to 7.
- Flags and Pull Up/Down: 0 - Pull Up/Down Disabled.
1 - Pull Down Enabled.
3 - Pull Up Enabled.
Bit 16 (0x00010000) - Input is active low.
- Drive Strength: 0 - 1x,
1 - 3x,
2 - 2x,
3 - 4x
- gpio-controller: Specifies that the node is a gpio controller.
- #address-cells: should be 1.
- #size-cells: should be 1.
Example:
gpa0: gpio-controller@11400000 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "samsung,exynos4-gpio";
reg = <0x11400000 0x20>;
#gpio-cells = <4>;
gpio-controller;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/gpio/gpio.txt
+272
View File
@@ -0,0 +1,272 @@
Specifying GPIO information for devices
============================================
1) gpios property
-----------------
Nodes that makes use of GPIOs should specify them using one or more
properties, each containing a 'gpio-list':
gpio-list ::= <single-gpio> [gpio-list]
single-gpio ::= <gpio-phandle> <gpio-specifier>
gpio-phandle : phandle to gpio controller node
gpio-specifier : Array of #gpio-cells specifying specific gpio
(controller specific)
GPIO properties should be named "[<name>-]gpios", with <name> being the purpose
of this GPIO for the device. While a non-existent <name> is considered valid
for compatibility reasons (resolving to the "gpios" property), it is not allowed
for new bindings.
GPIO properties can contain one or more GPIO phandles, but only in exceptional
cases should they contain more than one. If your device uses several GPIOs with
distinct functions, reference each of them under its own property, giving it a
meaningful name. The only case where an array of GPIOs is accepted is when
several GPIOs serve the same function (e.g. a parallel data line).
The exact purpose of each gpios property must be documented in the device tree
binding of the device.
The following example could be used to describe GPIO pins used as device enable
and bit-banged data signals:
gpio1: gpio1 {
gpio-controller
#gpio-cells = <2>;
};
gpio2: gpio2 {
gpio-controller
#gpio-cells = <1>;
};
[...]
enable-gpios = <&gpio2 2>;
data-gpios = <&gpio1 12 0>,
<&gpio1 13 0>,
<&gpio1 14 0>,
<&gpio1 15 0>;
Note that gpio-specifier length is controller dependent. In the
above example, &gpio1 uses 2 cells to specify a gpio, while &gpio2
only uses one.
gpio-specifier may encode: bank, pin position inside the bank,
whether pin is open-drain and whether pin is logically inverted.
Exact meaning of each specifier cell is controller specific, and must
be documented in the device tree binding for the device. Use the macros
defined in include/dt-bindings/gpio/gpio.h whenever possible:
Example of a node using GPIOs:
node {
enable-gpios = <&qe_pio_e 18 GPIO_ACTIVE_HIGH>;
};
GPIO_ACTIVE_HIGH is 0, so in this example gpio-specifier is "18 0" and encodes
GPIO pin number, and GPIO flags as accepted by the "qe_pio_e" gpio-controller.
1.1) GPIO specifier best practices
----------------------------------
A gpio-specifier should contain a flag indicating the GPIO polarity; active-
high or active-low. If it does, the following best practices should be
followed:
The gpio-specifier's polarity flag should represent the physical level at the
GPIO controller that achieves (or represents, for inputs) a logically asserted
value at the device. The exact definition of logically asserted should be
defined by the binding for the device. If the board inverts the signal between
the GPIO controller and the device, then the gpio-specifier will represent the
opposite physical level than the signal at the device's pin.
When the device's signal polarity is configurable, the binding for the
device must either:
a) Define a single static polarity for the signal, with the expectation that
any software using that binding would statically program the device to use
that signal polarity.
The static choice of polarity may be either:
a1) (Preferred) Dictated by a binding-specific DT property.
or:
a2) Defined statically by the DT binding itself.
In particular, the polarity cannot be derived from the gpio-specifier, since
that would prevent the DT from separately representing the two orthogonal
concepts of configurable signal polarity in the device, and possible board-
level signal inversion.
or:
b) Pick a single option for device signal polarity, and document this choice
in the binding. The gpio-specifier should represent the polarity of the signal
(at the GPIO controller) assuming that the device is configured for this
particular signal polarity choice. If software chooses to program the device
to generate or receive a signal of the opposite polarity, software will be
responsible for correctly interpreting (inverting) the GPIO signal at the GPIO
controller.
2) gpio-controller nodes
------------------------
Every GPIO controller node must contain both an empty "gpio-controller"
property, and a #gpio-cells integer property, which indicates the number of
cells in a gpio-specifier.
Example of two SOC GPIO banks defined as gpio-controller nodes:
qe_pio_a: gpio-controller@1400 {
compatible = "fsl,qe-pario-bank-a", "fsl,qe-pario-bank";
reg = <0x1400 0x18>;
gpio-controller;
#gpio-cells = <2>;
};
qe_pio_e: gpio-controller@1460 {
compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
reg = <0x1460 0x18>;
gpio-controller;
#gpio-cells = <2>;
};
2.1) gpio- and pin-controller interaction
-----------------------------------------
Some or all of the GPIOs provided by a GPIO controller may be routed to pins
on the package via a pin controller. This allows muxing those pins between
GPIO and other functions.
It is useful to represent which GPIOs correspond to which pins on which pin
controllers. The gpio-ranges property described below represents this, and
contains information structures as follows:
gpio-range-list ::= <single-gpio-range> [gpio-range-list]
single-gpio-range ::= <numeric-gpio-range> | <named-gpio-range>
numeric-gpio-range ::=
<pinctrl-phandle> <gpio-base> <pinctrl-base> <count>
named-gpio-range ::= <pinctrl-phandle> <gpio-base> '<0 0>'
pinctrl-phandle : phandle to pin controller node
gpio-base : Base GPIO ID in the GPIO controller
pinctrl-base : Base pinctrl pin ID in the pin controller
count : The number of GPIOs/pins in this range
The "pin controller node" mentioned above must conform to the bindings
described in ../pinctrl/pinctrl-bindings.txt.
In case named gpio ranges are used (ranges with both <pinctrl-base> and
<count> set to 0), the property gpio-ranges-group-names contains one string
for every single-gpio-range in gpio-ranges:
gpiorange-names-list ::= <gpiorange-name> [gpiorange-names-list]
gpiorange-name : Name of the pingroup associated to the GPIO range in
the respective pin controller.
Elements of gpiorange-names-list corresponding to numeric ranges contain
the empty string. Elements of gpiorange-names-list corresponding to named
ranges contain the name of a pin group defined in the respective pin
controller. The number of pins/GPIOs in the range is the number of pins in
that pin group.
Previous versions of this binding required all pin controller nodes that
were referenced by any gpio-ranges property to contain a property named
#gpio-range-cells with value <3>. This requirement is now deprecated.
However, that property may still exist in older device trees for
compatibility reasons, and would still be required even in new device
trees that need to be compatible with older software.
Example 1:
qe_pio_e: gpio-controller@1460 {
#gpio-cells = <2>;
compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
reg = <0x1460 0x18>;
gpio-controller;
gpio-ranges = <&pinctrl1 0 20 10>, <&pinctrl2 10 50 20>;
};
Here, a single GPIO controller has GPIOs 0..9 routed to pin controller
pinctrl1's pins 20..29, and GPIOs 10..19 routed to pin controller pinctrl2's
pins 50..59.
Example 2:
gpio_pio_i: gpio-controller@14B0 {
#gpio-cells = <2>;
compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
reg = <0x1480 0x18>;
gpio-controller;
gpio-ranges = <&pinctrl1 0 20 10>,
<&pinctrl2 10 0 0>,
<&pinctrl1 15 0 10>,
<&pinctrl2 25 0 0>;
gpio-ranges-group-names = "",
"foo",
"",
"bar";
};
Here, three GPIO ranges are defined wrt. two pin controllers. pinctrl1 GPIO
ranges are defined using pin numbers whereas the GPIO ranges wrt. pinctrl2
are named "foo" and "bar".
3) GPIO hog definitions
-----------------------
The GPIO chip may contain GPIO hog definitions. GPIO hogging is a mechanism
providing automatic GPIO request and configuration as part of the
gpio-controller's driver probe function.
Each GPIO hog definition is represented as a child node of the GPIO controller.
Required properties:
- gpio-hog: A property specifying that this child node represents a GPIO hog.
- gpios: Store the GPIO information (id, flags) for the GPIO to
affect.
! Not yet support more than one gpio !
Only one of the following properties scanned in the order shown below.
- input: A property specifying to set the GPIO direction as input.
- output-low A property specifying to set the GPIO direction as output with
the value low.
- output-high A property specifying to set the GPIO direction as output with
the value high.
Optional properties:
- line-name: The GPIO label name. If not present the node name is used.
Example:
tca6416@20 {
compatible = "ti,tca6416";
reg = <0x20>;
#gpio-cells = <2>;
gpio-controller;
env_reset {
gpio-hog;
input;
gpios = <6 GPIO_ACTIVE_LOW>;
};
boot_rescue {
gpio-hog;
input;
line-name = "foo-bar-gpio";
gpios = <7 GPIO_ACTIVE_LOW>;
};
};
For the above Example you can than access the gpio in your boardcode
with:
struct gpio_desc *desc;
int ret;
ret = gpio_hog_lookup_name("boot_rescue", &desc);
if (ret)
return;
if (dm_gpio_get_value(desc) == 1)
printf("\nBooting into Rescue System\n");
else if (dm_gpio_get_value(desc) == 0)
printf("\nBoot normal\n");
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/gpio/intel,x86-broadwell-pinctrl.txt
+208
View File
@@ -0,0 +1,208 @@
Intel x86 PINCTRL/GPIO controller
Pin-muxing on broadwell devices can be described with a node for the PINCTRL
master node and a set of child nodes for each required pin state on the SoC.
These pin states use phandles and are referred to but a configuration section
which lists all pins in the device.
The PINCTRL master node requires the following properties:
- compatible : "intel,x86-broadwell-pinctrl"
Pin state nodes must be sub-nodes of the pinctrl master node. The must have
a phandle. They can contain the following optional properties:
- mode-gpio - forces the pin into GPIO mode
- output-value - sets the default output value of the GPIO, 0 (low, default)
or 1 (high)
- direction - sets the direction of the gpio, either PIN_INPUT (default)
or PIN_OUTPUT
- invert - the input pin is inverted
- trigger - sets the trigger type, either TRIGGER_EDGE (default) or
TRIGGER_LEVEL
- sense-disable - the input state sense is disabled
- owner 0 sets the owner of the pin, either OWNER_ACPI (default) or
ONWER_GPIO
- route - sets whether the pin is routed, either PIRQ_APIC_MASK or
PIRQ_APIC_ROUTE
- irq-enable - the interrupt is enabled
- reset-rsmrst - the pin will only be reset by RSMRST
- pirq-apic - the pin will be routed to the IOxAPIC
The first pin state will be the default, so pins without a configuration will
use that.
The pin configuration node is also a sub-node of the pinctrl master node, but
does not have a phandle. It has a single property:
- config - configuration to use for each pin. Each entry has of 3 cells:
- GPIO number (0..94)
- phandle of configuration (above)
- interrupt number (0..15)
There should be one entry for each pin (i.e. 95 entries).
But missing pins will receive the default configuration.
Example:
pch_pinctrl {
compatible = "intel,x86-broadwell-pinctrl";
/* Put this first: it is the default */
gpio_unused: gpio-unused {
mode-gpio;
direction = <PIN_INPUT>;
owner = <OWNER_GPIO>;
sense-disable;
};
gpio_acpi_sci: acpi-sci {
mode-gpio;
direction = <PIN_INPUT>;
invert;
route = <ROUTE_SCI>;
};
gpio_acpi_smi: acpi-smi {
mode-gpio;
direction = <PIN_INPUT>;
invert;
route = <ROUTE_SMI>;
};
gpio_input: gpio-input {
mode-gpio;
direction = <PIN_INPUT>;
owner = <OWNER_GPIO>;
};
gpio_input_invert: gpio-input-invert {
mode-gpio;
direction = <PIN_INPUT>;
owner = <OWNER_GPIO>;
invert;
};
gpio_native: gpio-native {
};
gpio_out_high: gpio-out-high {
mode-gpio;
direction = <PIN_OUTPUT>;
output-value = <1>;
owner = <OWNER_GPIO>;
sense-disable;
};
gpio_out_low: gpio-out-low {
mode-gpio;
direction = <PIN_OUTPUT>;
output-value = <0>;
owner = <OWNER_GPIO>;
sense-disable;
};
gpio_pirq: gpio-pirq {
mode-gpio;
direction = <PIN_INPUT>;
owner = <OWNER_GPIO>;
pirq-apic = <PIRQ_APIC_ROUTE>;
};
soc_gpio@0 {
config =
<0 &gpio_unused 0>, /* unused */
<1 &gpio_unused 0>, /* unused */
<2 &gpio_unused 0>, /* unused */
<3 &gpio_unused 0>, /* unused */
<4 &gpio_native 0>, /* native: i2c0_sda_gpio4 */
<5 &gpio_native 0>, /* native: i2c0_scl_gpio5 */
<6 &gpio_native 0>, /* native: i2c1_sda_gpio6 */
<7 &gpio_native 0>, /* native: i2c1_scl_gpio7 */
<8 &gpio_acpi_sci 0>, /* pch_lte_wake_l */
<9 &gpio_input_invert 0>,/* trackpad_int_l (wake) */
<10 &gpio_acpi_sci 0>, /* pch_wlan_wake_l */
<11 &gpio_unused 0>, /* unused */
<12 &gpio_unused 0>, /* unused */
<13 &gpio_pirq 3>, /* trackpad_int_l (pirql) */
<14 &gpio_pirq 4>, /* touch_int_l (pirqm) */
<15 &gpio_unused 0>, /* unused (strap) */
<16 &gpio_input 0>, /* pch_wp */
<17 &gpio_unused 0>, /* unused */
<18 &gpio_unused 0>, /* unused */
<19 &gpio_unused 0>, /* unused */
<20 &gpio_native 0>, /* pcie_wlan_clkreq_l */
<21 &gpio_out_high 0>, /* pp3300_ssd_en */
<22 &gpio_unused 0>, /* unused */
<23 &gpio_out_low 0>, /* pp3300_autobahn_en */
<24 &gpio_unused 0>, /* unused */
<25 &gpio_input 0>, /* ec_in_rw */
<26 &gpio_unused 0>, /* unused */
<27 &gpio_acpi_sci 0>, /* pch_wake_l */
<28 &gpio_unused 0>, /* unused */
<29 &gpio_unused 0>, /* unused */
<30 &gpio_native 0>, /* native: pch_suswarn_l */
<31 &gpio_native 0>, /* native: acok_buf */
<32 &gpio_native 0>, /* native: lpc_clkrun_l */
<33 &gpio_native 0>, /* native: ssd_devslp */
<34 &gpio_acpi_smi 0>, /* ec_smi_l */
<35 &gpio_acpi_smi 0>, /* pch_nmi_dbg_l (route in nmi_en) */
<36 &gpio_acpi_sci 0>, /* ec_sci_l */
<37 &gpio_unused 0>, /* unused */
<38 &gpio_unused 0>, /* unused */
<39 &gpio_unused 0>, /* unused */
<40 &gpio_native 0>, /* native: pch_usb1_oc_l */
<41 &gpio_native 0>, /* native: pch_usb2_oc_l */
<42 &gpio_unused 0>, /* wlan_disable_l */
<43 &gpio_out_high 0>, /* pp1800_codec_en */
<44 &gpio_unused 0>, /* unused */
<45 &gpio_acpi_sci 0>, /* dsp_int - codec wake */
<46 &gpio_pirq 6>, /* hotword_det_l_3v3 (pirqo) - codec irq */
<47 &gpio_out_low 0>, /* ssd_reset_l */
<48 &gpio_unused 0>, /* unused */
<49 &gpio_unused 0>, /* unused */
<50 &gpio_unused 0>, /* unused */
<51 &gpio_unused 0>, /* unused */
<52 &gpio_input 0>, /* sim_det */
<53 &gpio_unused 0>, /* unused */
<54 &gpio_unused 0>, /* unused */
<55 &gpio_unused 0>, /* unused */
<56 &gpio_unused 0>, /* unused */
<57 &gpio_out_high 0>, /* codec_reset_l */
<58 &gpio_unused 0>, /* unused */
<59 &gpio_out_high 0>, /* lte_disable_l */
<60 &gpio_unused 0>, /* unused */
<61 &gpio_native 0>, /* native: pch_sus_stat */
<62 &gpio_native 0>, /* native: pch_susclk */
<63 &gpio_native 0>, /* native: pch_slp_s5_l */
<64 &gpio_unused 0>, /* unused */
<65 &gpio_input 0>, /* ram_id3 */
<66 &gpio_input 0>, /* ram_id3_old (strap) */
<67 &gpio_input 0>, /* ram_id0 */
<68 &gpio_input 0>, /* ram_id1 */
<69 &gpio_input 0>, /* ram_id2 */
<70 &gpio_unused 0>, /* unused */
<71 &gpio_native 0>, /* native: modphy_en */
<72 &gpio_unused 0>, /* unused */
<73 &gpio_unused 0>, /* unused */
<74 &gpio_unused 0>, /* unused */
<75 &gpio_unused 0>, /* unused */
<76 &gpio_unused 0>, /* unused */
<77 &gpio_unused 0>, /* unused */
<78 &gpio_unused 0>, /* unused */
<79 &gpio_unused 0>, /* unused */
<80 &gpio_unused 0>, /* unused */
<81 &gpio_unused 0>, /* unused */
<82 &gpio_native 0>, /* native: ec_rcin_l */
<83 &gpio_native 0>, /* gspi0_cs */
<84 &gpio_native 0>, /* gspi0_clk */
<85 &gpio_native 0>, /* gspi0_miso */
<86 &gpio_native 0>, /* gspi0_mosi (strap) */
<87 &gpio_unused 0>, /* unused */
<88 &gpio_unused 0>, /* unused */
<89 &gpio_out_high 0>, /* pp3300_sd_en */
<90 &gpio_unused 0>, /* unused */
<91 &gpio_unused 0>, /* unused */
<92 &gpio_unused 0>, /* unused */
<93 &gpio_unused 0>, /* unused */
<94 &gpio_unused 0 >; /* unused */
};
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/gpio/intel,x86-pinctrl.txt
+33
View File
@@ -0,0 +1,33 @@
Intel x86 PINCTRL/GPIO controller
Pin-muxing on x86 can be described with a node for the PINCTRL master
node and a set of child nodes for each pin on the SoC.
The PINCTRL master node requires the following properties:
- compatible : "intel,x86-pinctrl"
Pin nodes must be children of the pinctrl master node and can
contain the following properties:
- pad-offset - (required) offset in the IOBASE for the pin to configure
- gpio-offset - (required only when 'mode-gpio' is set) 2 cells
- offset in the GPIOBASE for the pin to configure
- the bit shift in this register (4 = bit 4)
- mode-gpio - (optional) standalone property to force the pin into GPIO mode
- mode-func - (optional) function number to assign to the pin. If
'mode-gpio' is set, this property will be ignored.
in case of 'mode-gpio' property set:
- output-value - (optional) this set the default output value of the GPIO
- direction - (optional) this set the direction of the gpio
- pull-strength - (optional) this set the pull strength of the pin
- pull-assign - (optional) this set the pull assignement (up/down) of the pin
- invert - (optional) this input pin is inverted
Example:
pin_usb_host_en0@0 {
gpio-offset = <0x80 8>;
pad-offset = <0x260>;
mode-gpio;
output-value = <1>;
direction = <PIN_OUTPUT>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/gpio/mscc_sgpio.txt
+45
View File
@@ -0,0 +1,45 @@
Microsemi Corporation (MSCC) Serial GPIO driver
The MSCC serial GPIO extends the number or GPIO's on the system by
means of 4 dedicated pins: one input, one output, one clock and one
strobe pin. By attaching a number of (external) shift registers, the
effective GPIO count can be extended by up to 128 GPIO's per
controller.
Required properties:
- compatible : "mscc,luton-sgpio" or "mscc,ocelot-sgpio"
- clock: Reference clock used to generate clock divider setting. See
mscc,sgpio-frequency property.
- reg : Physical base address and length of the controller's registers.
- #gpio-cells : Should be two. The first cell is the pin number and the
second cell is used to specify optional parameters:
- bit 0 specifies polarity (0 for normal, 1 for inverted)
- gpio-controller : Marks the device node as a GPIO controller.
- gpio-ranges: Standard gpio range(s): phandle, gpio base, pinctrl base
and count.
Optional properties:
- ngpios: See gpio.txt
- mscc,sgpio-frequency: The frequency at which the serial bitstream is
generated and sampled. Default: 12500000 (Hz).
- mscc,sgpio-ports: A bitmask (32 bits) of which ports are enabled in
the serialized gpio stream. One 'port' will transport from 1 to 4
gpio bits. Default: 0xFFFFFFFF.
Typically the pinctrl-0 and pinctrl-names properties will also be
present to enable the use of the SIO CLK, LD, DI and DO for some
regular GPIO pins.
Example:
sgpio: gpio@10700f8 {
compatible = "mscc,ocelot-sgpio";
pinctrl-0 = <&sgpio_pins>;
pinctrl-names = "default";
reg = <0x10700f8 0x100>;
gpio-controller;
#gpio-cells = <2>;
gpio-ranges = <&sgpio 0 0 64>;
mscc,sgpio-frequency = <12500>;
mscc,sgpio-ports = <0x000FFFFF>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/gpio/nvidia,tegra186-gpio.txt
+161
View File
@@ -0,0 +1,161 @@
NVIDIA Tegra186 GPIO controllers
Tegra186 contains two GPIO controllers; a main controller and an "AON"
controller. This binding document applies to both controllers. The register
layouts for the controllers share many similarities, but also some significant
differences. Hence, this document describes closely related but different
bindings and compatible values.
The Tegra186 GPIO controller allows software to set the IO direction of, and
read/write the value of, numerous GPIO signals. Routing of GPIO signals to
package balls is under the control of a separate pin controller HW block. Two
major sets of registers exist:
a) Security registers, which allow configuration of allowed access to the GPIO
register set. These registers exist in a single contiguous block of physical
address space. The size of this block, and the security features available,
varies between the different GPIO controllers.
Access to this set of registers is not necessary in all circumstances. Code
that wishes to configure access to the GPIO registers needs access to these
registers to do so. Code which simply wishes to read or write GPIO data does not
need access to these registers.
b) GPIO registers, which allow manipulation of the GPIO signals. In some GPIO
controllers, these registers are exposed via multiple "physical aliases" in
address space, each of which access the same underlying state. See the hardware
documentation for rationale. Any particular GPIO client is expected to access
just one of these physical aliases.
Tegra HW documentation describes a unified naming convention for all GPIOs
implemented by the SoC. Each GPIO is assigned to a port, and a port may control
a number of GPIOs. Thus, each GPIO is named according to an alphabetical port
name and an integer GPIO name within the port. For example, GPIO_PA0, GPIO_PN6,
or GPIO_PCC3.
The number of ports implemented by each GPIO controller varies. The number of
implemented GPIOs within each port varies. GPIO registers within a controller
are grouped and laid out according to the port they affect.
The mapping from port name to the GPIO controller that implements that port, and
the mapping from port name to register offset within a controller, are both
extremely non-linear. The header file <dt-bindings/gpio/tegra186-gpio.h>
describes the port-level mapping. In that file, the naming convention for ports
matches the HW documentation. The values chosen for the names are alphabetically
sorted within a particular controller. Drivers need to map between the DT GPIO
IDs and HW register offsets using a lookup table.
Each GPIO controller can generate a number of interrupt signals. Each signal
represents the aggregate status for all GPIOs within a set of ports. Thus, the
number of interrupt signals generated by a controller varies as a rough function
of the number of ports it implements. Note that the HW documentation refers to
both the overall controller HW module and the sets-of-ports as "controllers".
Each GPIO controller in fact generates multiple interrupts signals for each set
of ports. Each GPIO may be configured to feed into a specific one of the
interrupt signals generated by a set-of-ports. The intent is for each generated
signal to be routed to a different CPU, thus allowing different CPUs to each
handle subsets of the interrupts within a port. The status of each of these
per-port-set signals is reported via a separate register. Thus, a driver needs
to know which status register to observe. This binding currently defines no
configuration mechanism for this. By default, drivers should use register
GPIO_${port}_INTERRUPT_STATUS_G1_0. Future revisions to the binding could
define a property to configure this.
Required properties:
- compatible
Array of strings.
One of:
- "nvidia,tegra186-gpio".
- "nvidia,tegra186-gpio-aon".
- reg-names
Array of strings.
Contains a list of names for the register spaces described by the reg
property. May contain the following entries, in any order:
- "gpio": Mandatory. GPIO control registers. This may cover either:
a) The single physical alias that this OS should use.
b) All physical aliases that exist in the controller. This is
appropriate when the OS is responsible for managing assignment of
the physical aliases.
- "security": Optional. Security configuration registers.
Users of this binding MUST look up entries in the reg property by name,
using this reg-names property to do so.
- reg
Array of (physical base address, length) tuples.
Must contain one entry per entry in the reg-names property, in a matching
order.
- interrupts
Array of interrupt specifiers.
The interrupt outputs from the HW block, one per set of ports, in the
order the HW manual describes them. The number of entries required varies
depending on compatible value:
- "nvidia,tegra186-gpio": 6 entries.
- "nvidia,tegra186-gpio-aon": 1 entry.
- gpio-controller
Boolean.
Marks the device node as a GPIO controller/provider.
- #gpio-cells
Single-cell integer.
Must be <2>.
Indicates how many cells are used in a consumer's GPIO specifier.
In the specifier:
- The first cell is the pin number.
See <dt-bindings/gpio/tegra186-gpio.h>.
- The second cell contains flags:
- Bit 0 specifies polarity
- 0: Active-high (normal).
- 1: Active-low (inverted).
- interrupt-controller
Boolean.
Marks the device node as an interrupt controller/provider.
- #interrupt-cells
Single-cell integer.
Must be <2>.
Indicates how many cells are used in a consumer's interrupt specifier.
In the specifier:
- The first cell is the GPIO number.
See <dt-bindings/gpio/tegra186-gpio.h>.
- The second cell is contains flags:
- Bits [3:0] indicate trigger type and level:
- 1: Low-to-high edge triggered.
- 2: High-to-low edge triggered.
- 4: Active high level-sensitive.
- 8: Active low level-sensitive.
Valid combinations are 1, 2, 3, 4, 8.
Example:
#include <dt-bindings/interrupt-controller/irq.h>
gpio@2200000 {
compatible = "nvidia,tegra186-gpio";
reg-names = "security", "gpio";
reg =
<0x0 0x2200000 0x0 0x10000>,
<0x0 0x2210000 0x0 0x10000>;
interrupts =
<0 47 IRQ_TYPE_LEVEL_HIGH>,
<0 50 IRQ_TYPE_LEVEL_HIGH>,
<0 53 IRQ_TYPE_LEVEL_HIGH>,
<0 56 IRQ_TYPE_LEVEL_HIGH>,
<0 59 IRQ_TYPE_LEVEL_HIGH>,
<0 180 IRQ_TYPE_LEVEL_HIGH>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};
gpio@c2f0000 {
compatible = "nvidia,tegra186-gpio-aon";
reg-names = "security", "gpio";
reg =
<0x0 0xc2f0000 0x0 0x1000>,
<0x0 0xc2f1000 0x0 0x1000>;
interrupts =
<0 60 IRQ_TYPE_LEVEL_HIGH>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/gpio/nvidia,tegra20-gpio.txt
+40
View File
@@ -0,0 +1,40 @@
NVIDIA Tegra GPIO controller
Required properties:
- compatible : "nvidia,tegra<chip>-gpio"
- reg : Physical base address and length of the controller's registers.
- interrupts : The interrupt outputs from the controller. For Tegra20,
there should be 7 interrupts specified, and for Tegra30, there should
be 8 interrupts specified.
- #gpio-cells : Should be two. The first cell is the pin number and the
second cell is used to specify optional parameters:
- bit 0 specifies polarity (0 for normal, 1 for inverted)
- gpio-controller : Marks the device node as a GPIO controller.
- #interrupt-cells : Should be 2.
The first cell is the GPIO number.
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
1 = low-to-high edge triggered.
2 = high-to-low edge triggered.
4 = active high level-sensitive.
8 = active low level-sensitive.
Valid combinations are 1, 2, 3, 4, 8.
- interrupt-controller : Marks the device node as an interrupt controller.
Example:
gpio: gpio@6000d000 {
compatible = "nvidia,tegra20-gpio";
reg = < 0x6000d000 0x1000 >;
interrupts = < 0 32 0x04
0 33 0x04
0 34 0x04
0 35 0x04
0 55 0x04
0 87 0x04
0 89 0x04 >;
#gpio-cells = <2>;
gpio-controller;
#interrupt-cells = <2>;
interrupt-controller;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/gpio/pm8916_gpio.txt
+48
View File
@@ -0,0 +1,48 @@
Driver for part of pm8916 PMIC - gpio and power/reset keys
This device should be child of SPMI pmic.
1) GPIO driver
Required properties:
- compatible: "qcom,pm8916-gpio"
- reg: peripheral ID, size of register block
- gpio-controller
- gpio-count: number of GPIOs
- #gpio-cells: 2
Optional properties:
- gpio-bank-name: name of bank (as default "pm8916" is used)
Example:
pmic_gpios: gpios@c000 {
compatible = "qcom,pm8916-gpio";
reg = <0xc000 0x400>;
gpio-controller;
gpio-count = <4>;
#gpio-cells = <2>;
gpio-bank-name="pmic";
};
2) Power/Reset key driver
Required properties:
- compatible: "qcom,pm8916-pwrkey"
- reg: peripheral ID, size of register block
- gpio-controller
- #gpio-cells: 2
Optional properties:
- gpio-bank-name: name of bank (as default "pm8916_key" is used)
Example:
pmic_pon: pon@800 {
compatible = "qcom,pm8916-pwrkey";
reg = <0x800 0x96>;
#gpio-cells = <2>;
gpio-controller;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/gpio/snps,creg-gpio.txt
+43
View File
@@ -0,0 +1,43 @@
GPIO via CREG (control registers) driver
31 9 7 5 0 < bit number
| | | | |
[ not used | gpio-1 | gpio-0 | <-shift-> ] < 32 bit register
^ ^
| |
write 0x2 == set output to "1" (activate)
write 0x3 == set output to "0" (deactivate)
Required properties:
- compatible : "snps,creg-gpio"
- reg : Exactly one register range with length 0x4.
- #gpio-cells : Should be one - the pin number.
- gpio-controller : Marks the device node as a GPIO controller.
- gpio-count: Number of GPIO pins.
- gpio-bit-per-line: Number of bits per gpio line (see picture).
- gpio-first-shift: Shift (in bits) of the first GPIO field in register
(see picture).
- gpio-activate-val: Value should be set in corresponding field to set
output to "1" (see picture). Applied to all GPIO ports.
- gpio-deactivate-val: Value should be set in corresponding field to set
output to "0" (see picture). Applied to all GPIO ports.
Optional properties:
- gpio-bank-name: name of bank (as default driver name is used is used)
- gpio-default-val: array of default output values (must me 0 or 1)
Example (see picture):
gpio: gpio@f00014b0 {
compatible = "snps,creg-gpio";
reg = <0xf00014b0 0x4>;
gpio-controller;
#gpio-cells = <1>;
gpio-bank-name = "hsdk-spi-cs";
gpio-count = <2>;
gpio-first-shift = <5>;
gpio-bit-per-line = <2>;
gpio-activate-val = <2>;
gpio-deactivate-val = <3>;
gpio-default-val = <1 1>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/gpu/nvidia,tegra20-host1x.txt
+372
View File
@@ -0,0 +1,372 @@
NVIDIA Tegra host1x
Required properties:
- compatible: "nvidia,tegra<chip>-host1x"
- reg: Physical base address and length of the controller's registers.
- interrupts: The interrupt outputs from the controller.
- #address-cells: The number of cells used to represent physical base addresses
in the host1x address space. Should be 1.
- #size-cells: The number of cells used to represent the size of an address
range in the host1x address space. Should be 1.
- ranges: The mapping of the host1x address space to the CPU address space.
- clocks: Must contain one entry, for the module clock.
See ../clocks/clock-bindings.txt for details.
- resets: Must contain an entry for each entry in reset-names.
See ../reset/reset.txt for details.
- reset-names: Must include the following entries:
- host1x
The host1x top-level node defines a number of children, each representing one
of the following host1x client modules:
- mpe: video encoder
Required properties:
- compatible: "nvidia,tegra<chip>-mpe"
- reg: Physical base address and length of the controller's registers.
- interrupts: The interrupt outputs from the controller.
- clocks: Must contain one entry, for the module clock.
See ../clocks/clock-bindings.txt for details.
- resets: Must contain an entry for each entry in reset-names.
See ../reset/reset.txt for details.
- reset-names: Must include the following entries:
- mpe
- vi: video input
Required properties:
- compatible: "nvidia,tegra<chip>-vi"
- reg: Physical base address and length of the controller's registers.
- interrupts: The interrupt outputs from the controller.
- clocks: Must contain one entry, for the module clock.
See ../clocks/clock-bindings.txt for details.
- resets: Must contain an entry for each entry in reset-names.
See ../reset/reset.txt for details.
- reset-names: Must include the following entries:
- vi
- epp: encoder pre-processor
Required properties:
- compatible: "nvidia,tegra<chip>-epp"
- reg: Physical base address and length of the controller's registers.
- interrupts: The interrupt outputs from the controller.
- clocks: Must contain one entry, for the module clock.
See ../clocks/clock-bindings.txt for details.
- resets: Must contain an entry for each entry in reset-names.
See ../reset/reset.txt for details.
- reset-names: Must include the following entries:
- epp
- isp: image signal processor
Required properties:
- compatible: "nvidia,tegra<chip>-isp"
- reg: Physical base address and length of the controller's registers.
- interrupts: The interrupt outputs from the controller.
- clocks: Must contain one entry, for the module clock.
See ../clocks/clock-bindings.txt for details.
- resets: Must contain an entry for each entry in reset-names.
See ../reset/reset.txt for details.
- reset-names: Must include the following entries:
- isp
- gr2d: 2D graphics engine
Required properties:
- compatible: "nvidia,tegra<chip>-gr2d"
- reg: Physical base address and length of the controller's registers.
- interrupts: The interrupt outputs from the controller.
- clocks: Must contain one entry, for the module clock.
See ../clocks/clock-bindings.txt for details.
- resets: Must contain an entry for each entry in reset-names.
See ../reset/reset.txt for details.
- reset-names: Must include the following entries:
- 2d
- gr3d: 3D graphics engine
Required properties:
- compatible: "nvidia,tegra<chip>-gr3d"
- reg: Physical base address and length of the controller's registers.
- clocks: Must contain an entry for each entry in clock-names.
See ../clocks/clock-bindings.txt for details.
- clock-names: Must include the following entries:
(This property may be omitted if the only clock in the list is "3d")
- 3d
This MUST be the first entry.
- 3d2 (Only required on SoCs with two 3D clocks)
- resets: Must contain an entry for each entry in reset-names.
See ../reset/reset.txt for details.
- reset-names: Must include the following entries:
- 3d
- 3d2 (Only required on SoCs with two 3D clocks)
- dc: display controller
Required properties:
- compatible: "nvidia,tegra<chip>-dc"
- reg: Physical base address and length of the controller's registers.
- interrupts: The interrupt outputs from the controller.
- clocks: Must contain an entry for each entry in clock-names.
See ../clocks/clock-bindings.txt for details.
- clock-names: Must include the following entries:
- dc
This MUST be the first entry.
- parent
- resets: Must contain an entry for each entry in reset-names.
See ../reset/reset.txt for details.
- reset-names: Must include the following entries:
- dc
- nvidia,head: The number of the display controller head. This is used to
setup the various types of output to receive video data from the given
head.
Each display controller node has a child node, named "rgb", that represents
the RGB output associated with the controller. It can take the following
optional properties:
- nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
- nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
- nvidia,edid: supplies a binary EDID blob
- nvidia,panel: phandle of a display panel
- hdmi: High Definition Multimedia Interface
Required properties:
- compatible: "nvidia,tegra<chip>-hdmi"
- reg: Physical base address and length of the controller's registers.
- interrupts: The interrupt outputs from the controller.
- hdmi-supply: supply for the +5V HDMI connector pin
- vdd-supply: regulator for supply voltage
- pll-supply: regulator for PLL
- clocks: Must contain an entry for each entry in clock-names.
See ../clocks/clock-bindings.txt for details.
- clock-names: Must include the following entries:
- hdmi
This MUST be the first entry.
- parent
- resets: Must contain an entry for each entry in reset-names.
See ../reset/reset.txt for details.
- reset-names: Must include the following entries:
- hdmi
Optional properties:
- nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
- nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
- nvidia,edid: supplies a binary EDID blob
- nvidia,panel: phandle of a display panel
- tvo: TV encoder output
Required properties:
- compatible: "nvidia,tegra<chip>-tvo"
- reg: Physical base address and length of the controller's registers.
- interrupts: The interrupt outputs from the controller.
- clocks: Must contain one entry, for the module clock.
See ../clocks/clock-bindings.txt for details.
- dsi: display serial interface
Required properties:
- compatible: "nvidia,tegra<chip>-dsi"
- reg: Physical base address and length of the controller's registers.
- clocks: Must contain an entry for each entry in clock-names.
See ../clocks/clock-bindings.txt for details.
- clock-names: Must include the following entries:
- dsi
This MUST be the first entry.
- lp
- parent
- resets: Must contain an entry for each entry in reset-names.
See ../reset/reset.txt for details.
- reset-names: Must include the following entries:
- dsi
- avdd-dsi-supply: phandle of a supply that powers the DSI controller
- nvidia,mipi-calibrate: Should contain a phandle and a specifier specifying
which pads are used by this DSI output and need to be calibrated. See also
../mipi/nvidia,tegra114-mipi.txt.
Optional properties:
- nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
- nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
- nvidia,edid: supplies a binary EDID blob
- nvidia,panel: phandle of a display panel
- sor: serial output resource
Required properties:
- compatible: "nvidia,tegra124-sor"
- reg: Physical base address and length of the controller's registers.
- interrupts: The interrupt outputs from the controller.
- clocks: Must contain an entry for each entry in clock-names.
See ../clocks/clock-bindings.txt for details.
- clock-names: Must include the following entries:
- sor: clock input for the SOR hardware
- parent: input for the pixel clock
- dp: reference clock for the SOR clock
- safe: safe reference for the SOR clock during power up
- resets: Must contain an entry for each entry in reset-names.
See ../reset/reset.txt for details.
- reset-names: Must include the following entries:
- sor
Optional properties:
- nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
- nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
- nvidia,edid: supplies a binary EDID blob
- nvidia,panel: phandle of a display panel
Optional properties when driving an eDP output:
- nvidia,dpaux: phandle to a DispayPort AUX interface
- dpaux: DisplayPort AUX interface
- compatible: "nvidia,tegra124-dpaux"
- reg: Physical base address and length of the controller's registers.
- interrupts: The interrupt outputs from the controller.
- clocks: Must contain an entry for each entry in clock-names.
See ../clocks/clock-bindings.txt for details.
- clock-names: Must include the following entries:
- dpaux: clock input for the DPAUX hardware
- parent: reference clock
- resets: Must contain an entry for each entry in reset-names.
See ../reset/reset.txt for details.
- reset-names: Must include the following entries:
- dpaux
- vdd-supply: phandle of a supply that powers the DisplayPort link
Example:
/ {
...
host1x {
compatible = "nvidia,tegra20-host1x", "simple-bus";
reg = <0x50000000 0x00024000>;
interrupts = <0 65 0x04 /* mpcore syncpt */
0 67 0x04>; /* mpcore general */
clocks = <&tegra_car TEGRA20_CLK_HOST1X>;
resets = <&tegra_car 28>;
reset-names = "host1x";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x54000000 0x54000000 0x04000000>;
mpe {
compatible = "nvidia,tegra20-mpe";
reg = <0x54040000 0x00040000>;
interrupts = <0 68 0x04>;
clocks = <&tegra_car TEGRA20_CLK_MPE>;
resets = <&tegra_car 60>;
reset-names = "mpe";
};
vi {
compatible = "nvidia,tegra20-vi";
reg = <0x54080000 0x00040000>;
interrupts = <0 69 0x04>;
clocks = <&tegra_car TEGRA20_CLK_VI>;
resets = <&tegra_car 100>;
reset-names = "vi";
};
epp {
compatible = "nvidia,tegra20-epp";
reg = <0x540c0000 0x00040000>;
interrupts = <0 70 0x04>;
clocks = <&tegra_car TEGRA20_CLK_EPP>;
resets = <&tegra_car 19>;
reset-names = "epp";
};
isp {
compatible = "nvidia,tegra20-isp";
reg = <0x54100000 0x00040000>;
interrupts = <0 71 0x04>;
clocks = <&tegra_car TEGRA20_CLK_ISP>;
resets = <&tegra_car 23>;
reset-names = "isp";
};
gr2d {
compatible = "nvidia,tegra20-gr2d";
reg = <0x54140000 0x00040000>;
interrupts = <0 72 0x04>;
clocks = <&tegra_car TEGRA20_CLK_GR2D>;
resets = <&tegra_car 21>;
reset-names = "2d";
};
gr3d {
compatible = "nvidia,tegra20-gr3d";
reg = <0x54180000 0x00040000>;
clocks = <&tegra_car TEGRA20_CLK_GR3D>;
resets = <&tegra_car 24>;
reset-names = "3d";
};
dc@54200000 {
compatible = "nvidia,tegra20-dc";
reg = <0x54200000 0x00040000>;
interrupts = <0 73 0x04>;
clocks = <&tegra_car TEGRA20_CLK_DISP1>,
<&tegra_car TEGRA20_CLK_PLL_P>;
clock-names = "dc", "parent";
resets = <&tegra_car 27>;
reset-names = "dc";
rgb {
status = "disabled";
};
};
dc@54240000 {
compatible = "nvidia,tegra20-dc";
reg = <0x54240000 0x00040000>;
interrupts = <0 74 0x04>;
clocks = <&tegra_car TEGRA20_CLK_DISP2>,
<&tegra_car TEGRA20_CLK_PLL_P>;
clock-names = "dc", "parent";
resets = <&tegra_car 26>;
reset-names = "dc";
rgb {
status = "disabled";
};
};
hdmi {
compatible = "nvidia,tegra20-hdmi";
reg = <0x54280000 0x00040000>;
interrupts = <0 75 0x04>;
clocks = <&tegra_car TEGRA20_CLK_HDMI>,
<&tegra_car TEGRA20_CLK_PLL_D_OUT0>;
clock-names = "hdmi", "parent";
resets = <&tegra_car 51>;
reset-names = "hdmi";
status = "disabled";
};
tvo {
compatible = "nvidia,tegra20-tvo";
reg = <0x542c0000 0x00040000>;
interrupts = <0 76 0x04>;
clocks = <&tegra_car TEGRA20_CLK_TVO>;
status = "disabled";
};
dsi {
compatible = "nvidia,tegra20-dsi";
reg = <0x54300000 0x00040000>;
clocks = <&tegra_car TEGRA20_CLK_DSI>,
<&tegra_car TEGRA20_CLK_PLL_D_OUT0>;
clock-names = "dsi", "parent";
resets = <&tegra_car 48>;
reset-names = "dsi";
status = "disabled";
};
};
...
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/i2c/i2c-at91.txt
+26
View File
@@ -0,0 +1,26 @@
I2C for Atmel platforms
Required properties :
- compatible : Must be "atmel,at91rm9200-i2c", "atmel,at91sam9261-i2c",
"atmel,at91sam9260-i2c", "atmel,at91sam9g20-i2c", "atmel,at91sam9g10-i2c",
"atmel,at91sam9x5-i2c", "atmel,sama5d4-i2c" or "atmel,sama5d2-i2c".
- reg: physical base address of the controller and length of memory mapped
region.
- #address-cells = <1>;
- #size-cells = <0>;
- clocks: phandles to input clocks.
Optional properties:
- clock-frequency: Desired I2C bus frequency in Hz, default value is 100000.
- Child nodes conforming to i2c bus binding.
Examples :
i2c0: i2c@f8028000 {
compatible = "atmel,sama5d2-i2c";
reg = <0xf8028000 0x100>;
#address-cells = <1>;
#size-cells = <0>;
clocks = <&twi0_clk>;
clock-frequency = <100000>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/i2c/i2c-cdns.txt
+20
View File
@@ -0,0 +1,20 @@
Cadence I2C controller Device Tree Bindings
-------------------------------------------
Required properties:
- compatible : Should be "cdns,i2c-r1p10" or "xlnx,zynq-spi-r1p10".
- reg : Physical base address and size of I2C registers map.
- interrupts : Property with a value describing the interrupt
number.
- interrupt-parent : Must be core interrupt controller
- clocks : Clock phandles (see clock bindings for details).
Example:
i2c0: i2c@e0004000 {
compatible = "cdns,i2c-r1p10";
reg = <0xe0004000 0x1000>;
clocks = <&clkc 38>;
interrupts = <0 25 4>;
interrupt-parent = <&intc>;
status = "disabled";
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/i2c/i2c-gpio.txt
+37
View File
@@ -0,0 +1,37 @@
I2C gpio device binding
=======================
Driver:
- drivers/i2c/i2c-gpio.c
Software i2c device-tree node properties:
Required:
* #address-cells = <1>;
* #size-cells = <0>;
* compatible = "i2c-gpio";
* gpios = <sda ...>, <scl ...>;
Optional:
* i2c-gpio,delay-us = <5>;
The resulting transfer speed can be adjusted by setting the delay[us]
between gpio-toggle operations. Speed [Hz] = 1000000 / 4 * udelay[us],
It not defined, then default is 5us (~50KHz).
Example:
i2c-gpio@1 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "i2c-gpio";
gpios = <&gpd1 0 GPIO_ACTIVE_HIGH>, /* SDA */
<&gpd1 1 GPIO_ACTIVE_HIGH>; /* CLK */
i2c-gpio,delay-us = <5>;
some_device@5 {
compatible = "some_device";
reg = <0x5>;
...
};
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/i2c/i2c-mux.txt
+60
View File
@@ -0,0 +1,60 @@
Common i2c bus multiplexer/switch properties.
An i2c bus multiplexer/switch will have several child busses that are
numbered uniquely in a device dependent manner. The nodes for an i2c bus
multiplexer/switch will have one child node for each child
bus.
Required properties:
- #address-cells = <1>;
- #size-cells = <0>;
Required properties for child nodes:
- #address-cells = <1>;
- #size-cells = <0>;
- reg : The sub-bus number.
Optional properties for child nodes:
- Other properties specific to the multiplexer/switch hardware.
- Child nodes conforming to i2c bus binding
Example :
/*
An NXP pca9548 8 channel I2C multiplexer at address 0x70
with two NXP pca8574 GPIO expanders attached, one each to
ports 3 and 4.
*/
mux@70 {
compatible = "nxp,pca9548";
reg = <0x70>;
#address-cells = <1>;
#size-cells = <0>;
i2c@3 {
#address-cells = <1>;
#size-cells = <0>;
reg = <3>;
gpio1: gpio@38 {
compatible = "nxp,pca8574";
reg = <0x38>;
#gpio-cells = <2>;
gpio-controller;
};
};
i2c@4 {
#address-cells = <1>;
#size-cells = <0>;
reg = <4>;
gpio2: gpio@38 {
compatible = "nxp,pca8574";
reg = <0x38>;
#gpio-cells = <2>;
gpio-controller;
};
};
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/i2c/i2c-stm32.txt
+30
View File
@@ -0,0 +1,30 @@
* I2C controller embedded in STMicroelectronis STM32 platforms
Required properties :
- compatible : Must be "st,stm32f7-i2c"
- reg : Offset and length of the register set for the device
- resets: Must contain the phandle to the reset controller
- clocks: Must contain the input clock of the I2C instance
- A pinctrl state named "default" must be defined to set pins in mode of
operation for I2C transfer
- #address-cells = <1>;
- #size-cells = <0>;
Optional properties :
- clock-frequency : Desired I2C bus clock frequency in Hz. If not specified,
the default 100 kHz frequency will be used. As only Normal, Fast and Fast+
modes are implemented, possible values are 100000, 400000 and 1000000.
Example :
i2c1: i2c@40005400 {
compatible = "st,stm32f7-i2c";
reg = <0x40005400 0x400>;
resets = <&rcc 181>;
clocks = <&clk_pclk1>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c1>;
clock-frequency = <400000>;
#address-cells = <1>;
#size-cells = <0>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/i2c/i2c.txt
+46
View File
@@ -0,0 +1,46 @@
U-Boot I2C
----------
U-Boot's I2C model has the concept of an offset within a chip (I2C target
device). The offset can be up to 4 bytes long, but is normally 1 byte,
meaning that offsets from 0 to 255 are supported by the chip. This often
corresponds to register numbers.
Apart from the controller-specific I2C bindings, U-Boot supports a special
property which allows the chip offset length to be selected.
Optional properties:
- u-boot,i2c-offset-len - length of chip offset in bytes. If omitted the
default value of 1 is used.
- u-boot,i2c-transaction-bytes - the length of single I2C transaction on
the bus. Some devices require more than single byte transmission
(e.g. mc34708 mfd). This information is necessary to correctly
initialize (put into idle state) I2C bus after soft reset.
- gpios = <sda ...>, <scl ...>;
pinctrl-names = "default", "gpio";
pinctrl-0 = <&i2c_xfer>;
pinctrl-1 = <&i2c_gpio>;
Pin description for I2C bus software deblocking.
Example
-------
i2c4: i2c@12ca0000 {
cros-ec@1e {
reg = <0x1e>;
compatible = "google,cros-ec";
i2c-max-frequency = <100000>;
u-boot,i2c-offset-len = <0>;
u-boot,i2c-transaction-bytes = <3>;
ec-interrupt = <&gpx1 6 GPIO_ACTIVE_LOW>;
};
};
&i2c1 {
pinctrl-names = "default", "gpio";
pinctrl-0 = <&i2c1_xfer>;
pinctrl-1 = <&i2c1_gpio>;
gpios = <&gpio1 26 GPIO_ACTIVE_LOW>, /* SDA */
<&gpio1 27 GPIO_ACTIVE_LOW>; /* SCL */
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/i2c/nvidia,tegra186-bpmp-i2c.txt
+42
View File
@@ -0,0 +1,42 @@
NVIDIA Tegra186 BPMP I2C controller
In Tegra186, the BPMP (Boot and Power Management Processor) owns certain HW
devices, such as the I2C controller for the power management I2C bus. Software
running on other CPUs must perform IPC to the BPMP in order to execute
transactions on that I2C bus. This binding describes an I2C bus that is
accessed in such a fashion.
The BPMP I2C node must be located directly inside the main BPMP node. See
../firmware/nvidia,tegra186-bpmp.txt for details of the BPMP binding.
This node represents an I2C controller. See ../i2c/i2c.txt for details of the
core I2C binding.
Required properties:
- compatible:
Array of strings.
One of:
- "nvidia,tegra186-bpmp-i2c".
- #address-cells: Address cells for I2C device address.
Single-cell integer.
Must be <1>.
- #size-cells:
Single-cell integer.
Must be <0>.
- nvidia,bpmp-bus-id:
Single-cell integer.
Indicates the I2C bus number this DT node represent, as defined by the
BPMP firmware.
Example:
bpmp {
...
i2c {
compatible = "nvidia,tegra186-bpmp-i2c";
#address-cells = <1>;
#size-cells = <0>;
nvidia,bpmp-bus-id = <5>;
};
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/i2c/tegra20-i2c.txt
+23
View File
@@ -0,0 +1,23 @@
(Placeholder note while we locate the kernel Tegra20 bindings)
Added in U-Boot:
Required properties:
- clocks : Two clocks must be given, each as a phandle to the Tegra's
CAR node and the clock number as a parameter:
- the I2C clock to use for the peripheral
- the pll_p_out3 clock, which can be used for fast operation. This
does not change and is the same for all I2C nodes.
Example:
(TODO: merge with existing example):
i2c@7000c400 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "nvidia,tegra20-i2c";
reg = <0x7000C400 0x100>;
interrupts = < 116 >;
/* PERIPH_ID_I2C2, PLL_P_OUT3 */
clocks = <&tegra_car 54>, <&tegra_car 124>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/input/cros-ec-keyb.txt
+72
View File
@@ -0,0 +1,72 @@
ChromeOS EC Keyboard
Google's ChromeOS EC Keyboard is a simple matrix keyboard implemented on
a separate EC (Embedded Controller) device. It provides a message for reading
key scans from the EC. These are then converted into keycodes for processing
by the kernel.
This binding is based on matrix-keymap.txt and extends/modifies it as follows:
Required properties:
- compatible: "google,cros-ec-keyb"
Optional properties:
- google,needs-ghost-filter: True to enable a ghost filter for the matrix
keyboard. This is recommended if the EC does not have its own logic or
hardware for this.
Example:
cros-ec-keyb {
compatible = "google,cros-ec-keyb";
keypad,num-rows = <8>;
keypad,num-columns = <13>;
google,needs-ghost-filter;
/*
* Keymap entries take the form of 0xRRCCKKKK where
* RR=Row CC=Column KKKK=Key Code
* The values below are for a US keyboard layout and
* are taken from the Linux driver. Note that the
* 102ND key is not used for US keyboards.
*/
linux,keymap = <
/* CAPSLCK F1 B F10 */
0x0001003a 0x0002003b 0x00030030 0x00040044
/* N = R_ALT ESC */
0x00060031 0x0008000d 0x000a0064 0x01010001
/* F4 G F7 H */
0x0102003e 0x01030022 0x01040041 0x01060023
/* ' F9 BKSPACE L_CTRL */
0x01080028 0x01090043 0x010b000e 0x0200001d
/* TAB F3 T F6 */
0x0201000f 0x0202003d 0x02030014 0x02040040
/* ] Y 102ND [ */
0x0205001b 0x02060015 0x02070056 0x0208001a
/* F8 GRAVE F2 5 */
0x02090042 0x03010029 0x0302003c 0x03030006
/* F5 6 - \ */
0x0304003f 0x03060007 0x0308000c 0x030b002b
/* R_CTRL A D F */
0x04000061 0x0401001e 0x04020020 0x04030021
/* S K J ; */
0x0404001f 0x04050025 0x04060024 0x04080027
/* L ENTER Z C */
0x04090026 0x040b001c 0x0501002c 0x0502002e
/* V X , M */
0x0503002f 0x0504002d 0x05050033 0x05060032
/* L_SHIFT / . SPACE */
0x0507002a 0x05080035 0x05090034 0x050B0039
/* 1 3 4 2 */
0x06010002 0x06020004 0x06030005 0x06040003
/* 8 7 0 9 */
0x06050009 0x06060008 0x0608000b 0x0609000a
/* L_ALT DOWN RIGHT Q */
0x060a0038 0x060b006c 0x060c006a 0x07010010
/* E R W I */
0x07020012 0x07030013 0x07040011 0x07050017
/* U R_SHIFT P O */
0x07060016 0x07070036 0x07080019 0x07090018
/* UP LEFT */
0x070b0067 0x070c0069>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/input/i8042.txt
+10
View File
@@ -0,0 +1,10 @@
i8042 Keyboard
The Intel i8042 is a keyboard controller used on many x86 PCs.
Required properties:
- compatible: "intel,i8042-keyboard"
Optional properties:
- intel,duplicate-por: Indicates that a keyboard reset may result in a
duplicate POR byte, which should be ignored.
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/leds/common.txt
+23
View File
@@ -0,0 +1,23 @@
Common leds properties.
Optional properties for child nodes:
- label : The label for this LED. If omitted, the label is
taken from the node name (excluding the unit address).
- linux,default-trigger : This parameter, if present, is a
string defining the trigger assigned to the LED. Current triggers are:
"backlight" - LED will act as a back-light, controlled by the framebuffer
system
"default-on" - LED will turn on (but for leds-gpio see "default-state"
property in Documentation/devicetree/bindings/gpio/led.txt)
"heartbeat" - LED "double" flashes at a load average based rate
"ide-disk" - LED indicates disk activity
"timer" - LED flashes at a fixed, configurable rate
Examples:
system-status {
label = "Status";
linux,default-trigger = "heartbeat";
...
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/leds/leds-bcm6328.txt
+106
View File
@@ -0,0 +1,106 @@
LEDs connected to Broadcom BCM6328 controller
This controller is present on BCM6318, BCM6328, BCM6362 and BCM63268.
In these SoCs it's possible to control LEDs both as GPIOs or by hardware.
However, on some devices there are Serial LEDs (LEDs connected to a 74x164
controller), which can either be controlled by software (exporting the 74x164
as spi-gpio. See Documentation/devicetree/bindings/gpio/gpio-74x164.txt), or
by hardware using this driver.
Some of these Serial LEDs are hardware controlled (e.g. ethernet LEDs) and
exporting the 74x164 as spi-gpio prevents those LEDs to be hardware
controlled, so the only chance to keep them working is by using this driver.
Required properties:
- compatible : should be "brcm,bcm6328-leds".
- #address-cells : must be 1.
- #size-cells : must be 0.
- reg : BCM6328 LED controller address and size.
Optional properties:
- brcm,serial-leds : Boolean, enables Serial LEDs.
Default : false
- brcm,serial-mux : Boolean, enables Serial LEDs multiplexing.
Default : false
- brcm,serial-clk-low : Boolean, makes clock signal active low.
Default : false
- brcm,serial-dat-low : Boolean, makes data signal active low.
Default : false
- brcm,serial-shift-inv : Boolean, inverts Serial LEDs shift direction.
Default : false
Each LED is represented as a sub-node of the brcm,bcm6328-leds device.
LED sub-node required properties:
- reg : LED pin number (only LEDs 0 to 23 are valid).
LED sub-node optional properties:
- label : see Documentation/devicetree/bindings/leds/common.txt
- active-low : Boolean, makes LED active low.
Default : false
Examples:
Scenario 1 : BCM6328 with 4 GPIO LEDs
leds0: led-controller@10000800 {
compatible = "brcm,bcm6328-leds";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x10000800 0x24>;
alarm_red@2 {
reg = <2>;
active-low;
label = "red:alarm";
};
inet_green@3 {
reg = <3>;
active-low;
label = "green:inet";
};
power_green@4 {
reg = <4>;
active-low;
label = "green:power";
};
};
Scenario 2 : BCM63268 with Serial LEDs
leds0: led-controller@10001900 {
compatible = "brcm,bcm6328-leds";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x10001900 0x24>;
brcm,serial-leds;
brcm,serial-dat-low;
brcm,serial-shift-inv;
inet_red@2 {
reg = <2>;
active-low;
label = "red:inet";
};
dsl_green@3 {
reg = <3>;
active-low;
label = "green:dsl";
};
usb_green@4 {
reg = <4>;
active-low;
label = "green:usb";
};
wps_green@7 {
reg = <7>;
active-low;
label = "green:wps";
};
inet_green@8 {
reg = <8>;
active-low;
label = "green:inet";
};
power_green@20 {
reg = <20>;
active-low;
label = "green:power";
};
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/leds/leds-bcm6358.txt
+141
View File
@@ -0,0 +1,141 @@
LEDs connected to Broadcom BCM6358 controller
This controller is present on BCM6358 and BCM6368.
In these SoCs there are Serial LEDs (LEDs connected to a 74x164 controller),
which can either be controlled by software (exporting the 74x164 as spi-gpio.
See Documentation/devicetree/bindings/gpio/gpio-74x164.txt), or
by hardware using this driver.
Required properties:
- compatible : should be "brcm,bcm6358-leds".
- #address-cells : must be 1.
- #size-cells : must be 0.
- reg : BCM6358 LED controller address and size.
Optional properties:
- brcm,clk-div : SCK signal divider. Possible values are 1, 2, 4 and 8.
Default : 1
- brcm,clk-dat-low : Boolean, makes clock and data signals active low.
Default : false
Each LED is represented as a sub-node of the brcm,bcm6358-leds device.
LED sub-node required properties:
- reg : LED pin number (only LEDs 0 to 31 are valid).
LED sub-node optional properties:
- label : see Documentation/devicetree/bindings/leds/common.txt
- active-low : Boolean, makes LED active low.
Default : false
Examples:
Scenario 1 : BCM6358
leds0: led-controller@fffe00d0 {
compatible = "brcm,bcm6358-leds";
#address-cells = <1>;
#size-cells = <0>;
reg = <0xfffe00d0 0x8>;
alarm_white {
reg = <0>;
active-low;
label = "white:alarm";
};
tv_white {
reg = <2>;
active-low;
label = "white:tv";
};
tel_white {
reg = <3>;
active-low;
label = "white:tel";
};
adsl_white {
reg = <4>;
active-low;
label = "white:adsl";
};
};
Scenario 2 : BCM6368
leds0: led-controller@100000d0 {
compatible = "brcm,bcm6358-leds";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x100000d0 0x8>;
brcm,pol-low;
brcm,clk-div = <4>;
power_red {
reg = <0>;
active-low;
label = "red:power";
};
power_green {
reg = <1>;
active-low;
label = "green:power";
default-state = "on";
};
power_blue {
reg = <2>;
label = "blue:power";
};
broadband_red {
reg = <3>;
active-low;
label = "red:broadband";
};
broadband_green {
reg = <4>;
label = "green:broadband";
};
broadband_blue {
reg = <5>;
active-low;
label = "blue:broadband";
};
wireless_red {
reg = <6>;
active-low;
label = "red:wireless";
};
wireless_green {
reg = <7>;
active-low;
label = "green:wireless";
};
wireless_blue {
reg = <8>;
label = "blue:wireless";
};
phone_red {
reg = <9>;
active-low;
label = "red:phone";
};
phone_green {
reg = <10>;
active-low;
label = "green:phone";
};
phone_blue {
reg = <11>;
label = "blue:phone";
};
upgrading_red {
reg = <12>;
active-low;
label = "red:upgrading";
};
upgrading_green {
reg = <13>;
active-low;
label = "green:upgrading";
};
upgrading_blue {
reg = <14>;
label = "blue:upgrading";
};
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/leds/leds-bcm6858.txt
+51
View File
@@ -0,0 +1,51 @@
LEDs connected to Broadcom BCM6858 controller
This controller is present on BCM6858, BCM6328, BCM6362 and BCM63268.
In these SoCs it's possible to control LEDs both as GPIOs or by hardware.
Required properties:
- compatible : should be "brcm,bcm6858-leds".
- #address-cells : must be 1.
- #size-cells : must be 0.
- reg : BCM6858 LED controller address and size.
Optional properties:
- brcm,serial-led-msb-first : Boolean, msb data come out first on serial data pin
Default : false
- brcm,serial-led-en-pol : Boolean, serial led polarity (true => active high)
Default : false
- brcm,serial-led-clk-pol : Boolean, serial clock polarity (true => active high)
Default : false
- brcm,serial-led-data-ppol : Boolean, serial data polarity (true => active high)
Default : false
- brcm,serial-shift-inv : Boolean, led test mode
Default : false
Each LED is represented as a sub-node of the brcm,bcm6858-leds device.
LED sub-node required properties:
- reg : LED pin number (only LEDs 0 to 32 are valid).
LED sub-node optional properties:
- label : see Documentation/devicetree/bindings/leds/common.txt
- active-low : Boolean, makes LED active low.
Default : false
Examples:
BCM6328 with 2 GPIO LEDs
leds0: led-controller@ff800800 {
compatible = "brcm,bcm6858-leds";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x0 0xff800800 0x0 0xe4>;
led@2 {
reg = <2>;
label = "green:inet";
};
led@5 {
reg = <5>;
label = "red:alarm";
};
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/leds/leds-gpio.txt
+52
View File
@@ -0,0 +1,52 @@
LEDs connected to GPIO lines
Required properties:
- compatible : should be "gpio-leds".
Each LED is represented as a sub-node of the gpio-leds device. Each
node's name represents the name of the corresponding LED.
LED sub-node properties:
- gpios : Should specify the LED's GPIO, see "gpios property" in
Documentation/devicetree/bindings/gpio/gpio.txt. Active low LEDs should be
indicated using flags in the GPIO specifier.
- label : (optional)
see Documentation/devicetree/bindings/leds/common.txt
- linux,default-trigger : (optional)
see Documentation/devicetree/bindings/leds/common.txt
- default-state: (optional) The initial state of the LED. Valid
values are "on", "off", and "keep". If the LED is already on or off
and the default-state property is set the to same value, then no
glitch should be produced where the LED momentarily turns off (or
on). The "keep" setting will keep the LED at whatever its current
state is, without producing a glitch. The default is off if this
property is not present.
Examples:
leds {
compatible = "gpio-leds";
hdd {
label = "IDE Activity";
gpios = <&mcu_pio 0 1>; /* Active low */
linux,default-trigger = "ide-disk";
};
fault {
gpios = <&mcu_pio 1 0>;
/* Keep LED on if BIOS detected hardware fault */
default-state = "keep";
};
};
run-control {
compatible = "gpio-leds";
red {
gpios = <&mpc8572 6 0>;
default-state = "off";
};
green {
gpios = <&mpc8572 7 0>;
default-state = "on";
};
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/mailbox/k3-secure-proxy.txt
+40
View File
@@ -0,0 +1,40 @@
Texas Instruments' K3 Secure Proxy
===================================
The Texas Instruments' K3 Secure Proxy is a mailbox controller that has
configurable threads maintained by System power processor. Each thread
has different address space that can be used to send or receive messages.
Secure Proxy Device Node:
===========================
Required properties:
--------------------
- compatible: Shall be: "ti,am654-secure-proxy"
- reg-names data - Map the data region
scfg - Map the secure configuration region
rt - Map the Realtime region.
- reg: Contains the register map per reg-names.
- #mbox-cells Shall be 1. Contains the thread ID.
Example:
--------
secproxy: secproxy@285b0000 {
compatible = "ti,am654-secure-proxy";
reg = <0x2a380000 0x80000>,
<0x2a400000 0x80000>,
<0x2a480000 0x80000>;
reg-names = "rt", "scfg", "data";
#mbox-cells = <1>;
};
client:
systemcontroller: systemcontroller {
[...]
# RX thread ID is 4.
# TX thread ID is 5.
mboxes= <&secproxy 4>,
<&secproxy 5>;
[...]
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/mailbox/mailbox.txt
+32
View File
@@ -0,0 +1,32 @@
* Generic Mailbox Controller and client driver bindings
Generic binding to provide a way for Mailbox controller drivers to
assign appropriate mailbox channel to client drivers.
* Mailbox Controller
Required property:
- #mbox-cells: Must be at least 1. Number of cells in a mailbox
specifier.
Example:
mailbox: mailbox {
...
#mbox-cells = <1>;
};
* Mailbox Client
Required property:
- mboxes: List of phandle and mailbox channel specifiers.
Optional property:
- mbox-names: List of identifier strings for each mailbox channel.
Example:
pwr_cntrl: power {
...
mbox-names = "pwr-ctrl", "rpc";
mboxes = <&mailbox 0 &mailbox 1>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/mailbox/nvidia,tegra186-hsp.txt
+52
View File
@@ -0,0 +1,52 @@
NVIDIA Tegra Hardware Synchronization Primitives (HSP)
The HSP modules are used for the processors to share resources and communicate
together. It provides a set of hardware synchronization primitives for
interprocessor communication. So the interprocessor communication (IPC)
protocols can use hardware synchronization primitives, when operating between
two processors not in an SMP relationship.
The features that HSP supported are shared mailboxes, shared semaphores,
arbitrated semaphores and doorbells.
Required properties:
- name : Should be hsp
- compatible
Array of strings.
one of:
- "nvidia,tegra186-hsp"
- reg : Offset and length of the register set for the device.
- interrupt-names
Array of strings.
Contains a list of names for the interrupts described by the interrupt
property. May contain the following entries, in any order:
- "doorbell"
Users of this binding MUST look up entries in the interrupt property
by name, using this interrupt-names property to do so.
- interrupts
Array of interrupt specifiers.
Must contain one entry per entry in the interrupt-names property,
in a matching order.
- #mbox-cells : Should be 2.
The mbox specifier of the "mboxes" property in the client node should
contain two data. The first one should be the HSP type and the second
one should be the ID that the client is going to use. Those information
can be found in the following file.
- <dt-bindings/mailbox/tegra186-hsp.h>.
Example:
hsp_top0: hsp@3c00000 {
compatible = "nvidia,tegra186-hsp";
reg = <0x0 0x03c00000 0x0 0xa0000>;
interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "doorbell";
#mbox-cells = <2>;
};
client {
...
mboxes = <&hsp_top0 HSP_MBOX_TYPE_DB HSP_DB_MASTER_XXX>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/memory-controller/k3-j721e-ddrss.txt
+2241
View File
File diff suppressed because it is too large Load Diff
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/memory-controllers/k3-am654-ddrss.txt
+46
View File
@@ -0,0 +1,46 @@
Texas Instruments' K3 AM654 DDRSS
=================================
K3 based AM654 devices has DDR memory subsystem that comprises
Synopys DDR controller, Synopsis DDR phy and wrapper logic to
integrate these blocks into the device. This DDR subsystem
provides an interface to external SDRAM devices. This DDRSS driver
adds support for the initialization of the external SDRAM devices by
configuring the DDRSS registers and using the buitin PHY
initialization routines.
DDRSS device node:
==================
Required properties:
--------------------
- compatible: Shall be: "ti,am654-ddrss"
- reg-names ss - Map the sub system wrapper logic region
ctl - Map the controller region
phy - Map the PHY region
- reg: Contains the register map per reg-names.
- power-domains: Should contain a phandle to a PM domain provider node
and an args specifier containing the DDRSS device id
value. This property is as per the binding,
doc/device-tree-bindings/power/ti,sci-pm-domain.txt
- clocks: Must contain an entry for enabling DDR clock. Should
be defined as per the appropriate clock bindings consumer
usage in doc/device-tree-bindings/clock/ti,sci-clk.txt
Optional Properties:
--------------------
- clock-frequency: Frequency at which DDR pll should be locked.
If not provided, default frequency will be used.
Example (AM65x):
================
memory-controller: memory-controller@298e000 {
compatible = "ti,am654-ddrss";
reg = <0x0298e000 0x200>,
<0x02980000 0x4000>,
<0x02988000 0x2000>;
reg-names = "ss", "ctl", "phy";
clocks = <&k3_clks 20 0>;
power-domains = <&k3_pds 20>;
u-boot,dm-spl;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/memory-controllers/st,stm32-fmc.txt
+58
View File
@@ -0,0 +1,58 @@
ST, stm32 flexible memory controller Drive
Required properties:
- compatible : "st,stm32-fmc"
- reg : fmc controller base address
- clocks : fmc controller clock
u-boot,dm-pre-reloc: flag to initialize memory before relocation.
on-board sdram memory attributes:
- st,sdram-control : parameters for sdram configuration, in this order:
number of columns
number of rows
memory width
number of intenal banks in memory
cas latency
read burst enable or disable
read pipe delay
- st,sdram-timing: timings for sdram, in this order:
tmrd
txsr
tras
trc
trp
trcd
There is device tree include file at :
include/dt-bindings/memory/stm32-sdram.h to define sdram control and timing
parameters as MACROS.
Example:
fmc: fmc@A0000000 {
compatible = "st,stm32-fmc";
reg = <0xA0000000 0x1000>;
clocks = <&rcc 0 64>;
u-boot,dm-pre-reloc;
};
&fmc {
pinctrl-0 = <&fmc_pins>;
pinctrl-names = "default";
status = "okay";
/* sdram memory configuration from sdram datasheet */
bank1: bank@0 {
st,sdram-control = /bits/ 8 <NO_COL_8 NO_ROW_12 MWIDTH_16 BANKS_2
CAS_3 RD_BURST_EN RD_PIPE_DL_0>;
st,sdram-timing = /bits/ 8 <TMRD_1 TXSR_60 TRAS_42 TRC_60 TRP_18
TRCD_18>;
};
/* sdram memory configuration from sdram datasheet */
bank2: bank@1 {
st,sdram-control = /bits/ 8 <NO_COL_8 NO_ROW_12 MWIDTH_16 BANKS_2
CAS_3 RD_BURST_EN RD_PIPE_DL_0>;
st,sdram-timing = /bits/ 8 <TMRD_1 TXSR_60 TRAS_42 TRC_60 TRP_18
TRCD_18>;
};
}
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/memory-controllers/st,stm32mp1-ddr.txt
+299
View File
@@ -0,0 +1,299 @@
ST,stm32mp1 DDR3/LPDDR2/LPDDR3 Controller (DDRCTRL and DDRPHYC)
--------------------
Required properties:
--------------------
- compatible : Should be "st,stm32mp1-ddr"
- reg : controleur (DDRCTRL) and phy (DDRPHYC) base address
- clocks : controller clocks handle
- clock-names : associated controller clock names
the "ddrphyc" clock is used to check the DDR frequency
at phy level according the expected value in "mem-speed" field
the next attributes are DDR parameters, they are generated by DDR tools
included in STM32 Cube tool
info attributes:
----------------
- st,mem-name : name for DDR configuration, simple string for information
- st,mem-speed : DDR expected speed for the setting in kHz
- st,mem-size : DDR mem size in byte
controlleur attributes:
-----------------------
- st,ctl-reg : controleur values depending of the DDR type
(DDR3/LPDDR2/LPDDR3)
for STM32MP15x: 25 values are requested in this order
MSTR
MRCTRL0
MRCTRL1
DERATEEN
DERATEINT
PWRCTL
PWRTMG
HWLPCTL
RFSHCTL0
RFSHCTL3
CRCPARCTL0
ZQCTL0
DFITMG0
DFITMG1
DFILPCFG0
DFIUPD0
DFIUPD1
DFIUPD2
DFIPHYMSTR
ODTMAP
DBG0
DBG1
DBGCMD
POISONCFG
PCCFG
- st,ctl-timing : controleur values depending of frequency and timing parameter
of DDR
for STM32MP15x: 12 values are requested in this order
RFSHTMG
DRAMTMG0
DRAMTMG1
DRAMTMG2
DRAMTMG3
DRAMTMG4
DRAMTMG5
DRAMTMG6
DRAMTMG7
DRAMTMG8
DRAMTMG14
ODTCFG
- st,ctl-map : controleur values depending of address mapping
for STM32MP15x: 9 values are requested in this order
ADDRMAP1
ADDRMAP2
ADDRMAP3
ADDRMAP4
ADDRMAP5
ADDRMAP6
ADDRMAP9
ADDRMAP10
ADDRMAP11
- st,ctl-perf : controleur values depending of performance and scheduling
for STM32MP15x: 17 values are requested in this order
SCHED
SCHED1
PERFHPR1
PERFLPR1
PERFWR1
PCFGR_0
PCFGW_0
PCFGQOS0_0
PCFGQOS1_0
PCFGWQOS0_0
PCFGWQOS1_0
PCFGR_1
PCFGW_1
PCFGQOS0_1
PCFGQOS1_1
PCFGWQOS0_1
PCFGWQOS1_1
phyc attributes:
----------------
- st,phy-reg : phy values depending of the DDR type (DDR3/LPDDR2/LPDDR3)
for STM32MP15x: 11 values are requested in this order
PGCR
ACIOCR
DXCCR
DSGCR
DCR
ODTCR
ZQ0CR1
DX0GCR
DX1GCR
DX2GCR
DX3GCR
- st,phy-timing : phy values depending of frequency and timing parameter of DDR
for STM32MP15x: 10 values are requested in this order
PTR0
PTR1
PTR2
DTPR0
DTPR1
DTPR2
MR0
MR1
MR2
MR3
- st,phy-cal : phy cal depending of calibration or tuning of DDR
for STM32MP15x: 12 values are requested in this order
DX0DLLCR
DX0DQTR
DX0DQSTR
DX1DLLCR
DX1DQTR
DX1DQSTR
DX2DLLCR
DX2DQTR
DX2DQSTR
DX3DLLCR
DX3DQTR
DX3DQSTR
Example:
/ {
soc {
u-boot,dm-spl;
ddr: ddr@0x5A003000{
u-boot,dm-spl;
u-boot,dm-pre-reloc;
compatible = "st,stm32mp1-ddr";
reg = <0x5A003000 0x550
0x5A004000 0x234>;
clocks = <&rcc_clk AXIDCG>,
<&rcc_clk DDRC1>,
<&rcc_clk DDRC2>,
<&rcc_clk DDRPHYC>,
<&rcc_clk DDRCAPB>,
<&rcc_clk DDRPHYCAPB>;
clock-names = "axidcg",
"ddrc1",
"ddrc2",
"ddrphyc",
"ddrcapb",
"ddrphycapb";
st,mem-name = "DDR3 2x4Gb 533MHz";
st,mem-speed = <533000>;
st,mem-size = <0x40000000>;
st,ctl-reg = <
0x00040401 /*MSTR*/
0x00000010 /*MRCTRL0*/
0x00000000 /*MRCTRL1*/
0x00000000 /*DERATEEN*/
0x00800000 /*DERATEINT*/
0x00000000 /*PWRCTL*/
0x00400010 /*PWRTMG*/
0x00000000 /*HWLPCTL*/
0x00210000 /*RFSHCTL0*/
0x00000000 /*RFSHCTL3*/
0x00000000 /*CRCPARCTL0*/
0xC2000040 /*ZQCTL0*/
0x02050105 /*DFITMG0*/
0x00000202 /*DFITMG1*/
0x07000000 /*DFILPCFG0*/
0xC0400003 /*DFIUPD0*/
0x00000000 /*DFIUPD1*/
0x00000000 /*DFIUPD2*/
0x00000000 /*DFIPHYMSTR*/
0x00000001 /*ODTMAP*/
0x00000000 /*DBG0*/
0x00000000 /*DBG1*/
0x00000000 /*DBGCMD*/
0x00000000 /*POISONCFG*/
0x00000010 /*PCCFG*/
>;
st,ctl-timing = <
0x0080008A /*RFSHTMG*/
0x121B2414 /*DRAMTMG0*/
0x000D041B /*DRAMTMG1*/
0x0607080E /*DRAMTMG2*/
0x0050400C /*DRAMTMG3*/
0x07040407 /*DRAMTMG4*/
0x06060303 /*DRAMTMG5*/
0x02020002 /*DRAMTMG6*/
0x00000202 /*DRAMTMG7*/
0x00001005 /*DRAMTMG8*/
0x000D041B /*DRAMTMG1*/4
0x06000600 /*ODTCFG*/
>;
st,ctl-map = <
0x00080808 /*ADDRMAP1*/
0x00000000 /*ADDRMAP2*/
0x00000000 /*ADDRMAP3*/
0x00001F1F /*ADDRMAP4*/
0x07070707 /*ADDRMAP5*/
0x0F070707 /*ADDRMAP6*/
0x00000000 /*ADDRMAP9*/
0x00000000 /*ADDRMAP10*/
0x00000000 /*ADDRMAP11*/
>;
st,ctl-perf = <
0x00001201 /*SCHED*/
0x00001201 /*SCHED*/1
0x01000001 /*PERFHPR1*/
0x08000200 /*PERFLPR1*/
0x08000400 /*PERFWR1*/
0x00010000 /*PCFGR_0*/
0x00000000 /*PCFGW_0*/
0x02100B03 /*PCFGQOS0_0*/
0x00800100 /*PCFGQOS1_0*/
0x01100B03 /*PCFGWQOS0_0*/
0x01000200 /*PCFGWQOS1_0*/
0x00010000 /*PCFGR_1*/
0x00000000 /*PCFGW_1*/
0x02100B03 /*PCFGQOS0_1*/
0x00800000 /*PCFGQOS1_1*/
0x01100B03 /*PCFGWQOS0_1*/
0x01000200 /*PCFGWQOS1_1*/
>;
st,phy-reg = <
0x01442E02 /*PGCR*/
0x10400812 /*ACIOCR*/
0x00000C40 /*DXCCR*/
0xF200001F /*DSGCR*/
0x0000000B /*DCR*/
0x00010000 /*ODTCR*/
0x0000007B /*ZQ0CR1*/
0x0000CE81 /*DX0GCR*/
0x0000CE81 /*DX1GCR*/
0x0000CE81 /*DX2GCR*/
0x0000CE81 /*DX3GCR*/
>;
st,phy-timing = <
0x0022A41B /*PTR0*/
0x047C0740 /*PTR1*/
0x042D9C80 /*PTR2*/
0x369477D0 /*DTPR0*/
0x098A00D8 /*DTPR1*/
0x10023600 /*DTPR2*/
0x00000830 /*MR0*/
0x00000000 /*MR1*/
0x00000208 /*MR2*/
0x00000000 /*MR3*/
>;
st,phy-cal = <
0x40000000 /*DX0DLLCR*/
0xFFFFFFFF /*DX0DQTR*/
0x3DB02000 /*DX0DQSTR*/
0x40000000 /*DX1DLLCR*/
0xFFFFFFFF /*DX1DQTR*/
0x3DB02000 /*DX1DQSTR*/
0x40000000 /*DX2DLLCR*/
0xFFFFFFFF /*DX2DQTR*/
0x3DB02000 /*DX2DQSTR*/
0x40000000 /*DX3DLLCR*/
0xFFFFFFFF /*DX3DQTR*/
0x3DB02000 /*DX3DQSTR*/
>;
status = "okay";
};
};
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/memory/memory.txt
+67
View File
@@ -0,0 +1,67 @@
* Memory binding
The memory binding for U-Boot is as in the ePAPR with the following additions:
Optional subnodes can be used defining the memory layout for different board
ID masks. To match a set of board ids, a board-id node may define match-mask
and match-value ints to define a mask to apply to the board id, and the value
that the result should have for the match to be considered valid. The mask
defaults to -1, meaning that the value must fully match the board id.
If subnodes are present, then the /memory node must define these properties:
- #address-cells: should be 1.
- #size-cells: should be 0.
Each subnode must define
reg - board ID or mask for this subnode
memory-banks - list of memory banks in the same format as normal
Each subnode may optionally define:
match-mask - A mask to apply to the board id. This must be accompanied by
match-value.
match-value - The required resulting value of the board id mask for the given
node to be considered a match.
auto-size - Indicates that the value given for a bank is the maximum size,
each bank is probed to determine its actual size, which may be
smaller
The board id determination is up to the vendor and is not defined by this
binding.
Example:
memory {
#address-cells = <1>;
#size-cells = <1>;
reg = <0x20000000 0x20000000
0x40000000 0x20000000
0x60000000 0x20000000
0x80000000 0x20000000>;
auto-size;
board-id@0 {
match-value = <17>;
reg = <0x20000000 0x20000000
0x40000000 0x20000000>;
};
board-id@1 {
match-mask = <2>;
match-value = <2>;
reg = <0x20000000 0x20000000
0x40000000 0x20000000
0x60000000 0x20000000
0x80000000 0x20000000
0xa0000000 0x20000000
0xc0000000 0x20000000
0xe0000000 0x20000000>;
};
};
This shows a system with the following properties:
* Default of 2GB of memory, auto-sized, so could be smaller
* 3.5GB of memory (with no auto-size) if (board id & 2) is 2
* 1GB of memory (with no auto-size) if board id is 17.
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/misc/altera_sysid.txt
+4
View File
@@ -0,0 +1,4 @@
Altera sysid
Required properties:
- compatible : should be "altr,sysid-1.0"
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/misc/cros-ec.txt
+38
View File
@@ -0,0 +1,38 @@
Chrome OS CROS_EC Binding
======================
The device tree node which describes the operation of the CROS_EC interface
is as follows:
Required properties :
- compatible = "google,cros-ec"
Optional properties :
- spi-max-frequency : Sets the maximum frequency (in Hz) for SPI bus
operation
- i2c-max-frequency : Sets the maximum frequency (in Hz) for I2C bus
operation
- ec-interrupt : Selects the EC interrupt, defined as a GPIO according
to the platform
- optimise-flash-write : Boolean property - if present then flash blocks
containing all 0xff will not be written, since we assume that the EC
uses that pattern for erased blocks
The CROS_EC node should appear as a subnode of the interrupt that connects it
to the EC (e.g. i2c, spi, lpc). The reg property (as usual) will indicate
the unit address on that bus.
Example
=======
spi@131b0000 {
cros-ec@0 {
reg = <0>;
compatible = "google,cros-ec";
spi-max-frequency = <5000000>;
ec-interrupt = <&gpio 174 1>;
optimise-flash-write;
status = "disabled";
};
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/misc/fs_loader.txt
+48
View File
@@ -0,0 +1,48 @@
* File system firmware loader
Required properties:
--------------------
- compatible: should contain "u-boot,fs-loader"
- phandlepart: which block storage device and partition the image loading from,
this property is required for mmc, usb and sata. This is unsigned
32-bit array. For example phandlepart=<&mmc_0 1>, meaning use
that MMC0 node pointer, partition 1.
- mdtpart: which partition of ubi the image loading from, this property is
required for ubi and mounting.
- ubivol: which volume of ubi the image loading from, this property is required
for ubi and mounting.
Example of storage device and partition search set for mmc, usb, sata and
ubi in device tree source as shown in below:
Example of storage type and device partition search set for mmc, usb,
sata and ubi as shown in below:
Example for mmc:
fs_loader0: fs-loader@0 {
u-boot,dm-pre-reloc;
compatible = "u-boot,fs-loader";
phandlepart = <&mmc_0 1>;
};
Example for usb:
fs_loader1: fs-loader@1 {
u-boot,dm-pre-reloc;
compatible = "u-boot,fs-loader";
phandlepart = <&usb0 1>;
};
Example for sata:
fs_loader2: fs-loader@2 {
u-boot,dm-pre-reloc;
compatible = "u-boot,fs-loader";
phandlepart = <&sata0 1>;
};
Example for ubi:
fs_loader3: fs-loader@3 {
u-boot,dm-pre-reloc;
compatible = "u-boot,fs-loader";
mtdpart = "UBI",
ubivol = "ubi0";
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/misc/intel,baytrail-fsp.txt
+155
View File
@@ -0,0 +1,155 @@
Intel Bay Trail FSP UPD Binding
===============================
The device tree node which describes the overriding of the Intel Bay Trail FSP
UPD data for configuring the SoC.
All properties can be found within the `upd-region` struct in
arch/x86/include/asm/arch-baytrail/fsp/fsp_vpd.h, under the same names, and in
Intel's FSP Binary Configuration Tool for Bay Trail. This list of properties
is matched up to Intel's E3800 FSPv4 release.
# Boolean properties:
- fsp,enable-sdio
- fsp,enable-sdcard
- fsp,enable-hsuart0
- fsp,enable-hsuart1
- fsp,enable-spi
- fsp,enable-sata
- fsp,enable-azalia
- fsp,enable-xhci
- fsp,enable-dma0
- fsp,enable-dma1
- fsp,enable-i2-c0
- fsp,enable-i2-c1
- fsp,enable-i2-c2
- fsp,enable-i2-c3
- fsp,enable-i2-c4
- fsp,enable-i2-c5
- fsp,enable-i2-c6
- fsp,enable-pwm0
- fsp,enable-pwm1
- fsp,enable-hsi
- fsp,mrc-debug-msg
- fsp,isp-enable
- fsp,igd-render-standby
- fsp,txe-uma-enable
- fsp,emmc45-ddr50-enabled
- fsp,emmc45-hs200-enabled
- fsp,enable-igd
- fsp,enable-memory-down
If you set "fsp,enable-memory-down" you are strongly encouraged to provide an
"fsp,memory-down-params{};" to specify how your memory is configured. If you
do not set "fsp,enable-memory-down", then the DIMM SPD information will be
discovered by the FSP and used to setup main memory.
# Integer properties:
- fsp,mrc-init-tseg-size
- fsp,mrc-init-mmio-size
- fsp,mrc-init-spd-addr1
- fsp,mrc-init-spd-addr2
- fsp,emmc-boot-mode
- fsp,sata-mode
- fsp,lpe-mode
- fsp,lpss-sio-mode
- fsp,igd-dvmt50-pre-alloc
- fsp,aperture-size
- fsp,gtt-size
- fsp,scc-mode
- fsp,os-selection
- fsp,emmc45-retune-timer-value
- fsp,memory-down-params {
# Boolean properties:
- fsp,dimm-0-enable
- fsp,dimm-1-enable
# Integer properties:
- fsp,dram-speed
- fsp,dram-type
- fsp,dimm-width
- fsp,dimm-density
- fsp,dimm-bus-width
- fsp,dimm-sides
- fsp,dimm-tcl
- fsp,dimm-trpt-rcd
- fsp,dimm-twr
- fsp,dimm-twtr
- fsp,dimm-trrd
- fsp,dimm-trtp
- fsp,dimm-tfaw
};
For all integer properties, available options are listed in fsp_configs.h in
arch/x86/include/asm/arch-baytrail/fsp directory (eg: MRC_INIT_TSEG_SIZE_1MB).
Example (from MinnowMax Dual Core):
-----------------------------------
/ {
...
fsp {
compatible = "intel,baytrail-fsp";
fsp,mrc-init-tseg-size = <MRC_INIT_TSEG_SIZE_1MB>;
fsp,mrc-init-mmio-size = <MRC_INIT_MMIO_SIZE_2048MB>;
fsp,mrc-init-spd-addr1 = <0xa0>;
fsp,mrc-init-spd-addr2 = <0xa2>;
fsp,emmc-boot-mode = <EMMC_BOOT_MODE_AUTO>;
fsp,enable-sdio;
fsp,enable-sdcard;
fsp,enable-hsuart1;
fsp,enable-spi;
fsp,enable-sata;
fsp,sata-mode = <SATA_MODE_AHCI>;
fsp,lpe-mode = <LPE_MODE_PCI>;
fsp,lpss-sio-mode = <LPSS_SIO_MODE_PCI>;
fsp,enable-dma0;
fsp,enable-dma1;
fsp,enable-i2c0;
fsp,enable-i2c1;
fsp,enable-i2c2;
fsp,enable-i2c3;
fsp,enable-i2c4;
fsp,enable-i2c5;
fsp,enable-i2c6;
fsp,enable-pwm0;
fsp,enable-pwm1;
fsp,igd-dvmt50-pre-alloc = <IGD_DVMT50_PRE_ALLOC_64MB>;
fsp,aperture-size = <APERTURE_SIZE_256MB>;
fsp,gtt-size = <GTT_SIZE_2MB>;
fsp,scc-mode = <SCC_MODE_PCI>;
fsp,os-selection = <OS_SELECTION_LINUX>;
fsp,emmc45-ddr50-enabled;
fsp,emmc45-retune-timer-value = <8>;
fsp,enable-igd;
fsp,enable-memory-down;
fsp,memory-down-params {
compatible = "intel,baytrail-fsp-mdp";
fsp,dram-speed = <DRAM_SPEED_1066MTS>;
fsp,dram-type = <DRAM_TYPE_DDR3L>;
fsp,dimm-0-enable;
fsp,dimm-width = <DIMM_WIDTH_X16>;
fsp,dimm-density = <DIMM_DENSITY_4GBIT>;
fsp,dimm-bus-width = <DIMM_BUS_WIDTH_64BITS>;
fsp,dimm-sides = <DIMM_SIDES_1RANKS>;
fsp,dimm-tcl = <0xb>;
fsp,dimm-trpt-rcd = <0xb>;
fsp,dimm-twr = <0xc>;
fsp,dimm-twtr = <6>;
fsp,dimm-trrd = <6>;
fsp,dimm-trtp = <6>;
fsp,dimm-tfaw = <0x14>;
};
};
...
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/misc/intel,irq-router.txt
+61
View File
@@ -0,0 +1,61 @@
Intel Interrupt Router Device Binding
=====================================
The device tree node which describes the operation of the Intel Interrupt Router
device is as follows:
Required properties :
- reg : Specifies the interrupt router's PCI configuration space address as
defined by the Open Firmware spec.
- compatible = "intel,irq-router"
- intel,pirq-config : Specifies the IRQ routing register programming mechanism.
Valid values are:
"pci": IRQ routing is controlled by PCI configuration registers
"ibase": IRQ routing is in the memory-mapped IBASE register block
- intel,ibase-offset : IBASE register offset in the interrupt router's PCI
configuration space, required only if intel,pirq-config = "ibase".
- intel,actl-8bit : If ACTL (ACPI control) register width is 8-bit, this must
be specified. The 8-bit ACTL register is seen on ICH series chipset, like
ICH9/Panther Point/etc. On Atom chipset it is a 32-bit register.
- intel,actl-addr : ACTL (ACPI control) register offset. ACTL can be either
in the interrupt router's PCI configuration space, or IBASE.
- intel,pirq-link : Specifies the PIRQ link information with two cells. The
first cell is the register offset that controls the first PIRQ link routing.
The second cell is the total number of PIRQ links the router supports.
- intel,pirq-regmap : Specifies PIRQ routing register offset of all PIRQ links,
encoded as 2 cells a group for each link. The first cell is the PIRQ link
number (0 for PIRQA, 1 for PIRQB, etc). The second cell is the PIRQ routing
register offset from the interrupt router's base address. If this property
is omitted, it indicates a consecutive register offset from the first PIRQ
link, as specified by the first cell of intel,pirq-link.
- intel,pirq-mask : Specifies the IRQ mask representing the 16 IRQs in the
8259 PIC. Bit N is 1 means IRQ N is available to be routed.
- intel,pirq-routing : Specifies all PCI devices' IRQ routing information,
encoded as 3 cells a group for a device. The first cell is the device's PCI
bus number, device number and function number encoding with PCI_BDF() macro.
The second cell is the PCI interrupt pin used by this device. The last cell
is which PIRQ line the PCI interrupt pin is routed to.
Example
-------
#include <dt-bindings/interrupt-router/intel-irq.h>
irq-router@1f,0 {
reg = <0x0000f800 0 0 0 0>;
compatible = "intel,irq-router";
intel,pirq-config = "pci";
intel,pirq-link = <0x60 8>;
intel,pirq-mask = <0xdef8>;
intel,pirq-routing = <
PCI_BDF(0, 2, 0) INTA PIRQA
PCI_BDF(0, 3, 0) INTA PIRQB
PCI_BDF(0, 8, 0) INTA PIRQC
PCI_BDF(0, 8, 1) INTB PIRQD
PCI_BDF(1, 6, 0) INTA PIRQE
PCI_BDF(1, 6, 1) INTB PIRQF
PCI_BDF(1, 6, 2) INTC PIRQG
PCI_BDF(1, 6, 3) INTD PIRQH
>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/misc/intel-lpc.txt
+64
View File
@@ -0,0 +1,64 @@
Intel LPC Device Binding
========================
The device tree node which describes the operation of the Intel Low Pin
Count device is as follows:
Required properties :
- compatible = "intel,lpc"
- intel,alt-gp-smi-enable : Enable SMI sources. This cell is written to the
ALT_GP_SMI_EN register
- intel,gen-dec : Specifies the values for the gen-dec registers. Up to four
cell pairs can be provided - the first of each pair is the base address and
the second is the size. These are written into the GENx_DEC registers of
the LPC device
- intel,gpi-routing : Specifies the GPI routing. There are 16 cells, valid
values are:
0 No effect (default)
1 SMI# (if corresponding ALT_GPI_SMI_EN bit is also set)
2 SCI (if corresponding GPIO_EN bit is also set)
- intel,pirq-routing : Speciffies the routing IRQ number for each of PIRQA-H,
one cell for each.
0x00 - 0000 = Reserved
0x01 - 0001 = Reserved
0x02 - 0010 = Reserved
0x03 - 0011 = IRQ3
0x04 - 0100 = IRQ4
0x05 - 0101 = IRQ5
0x06 - 0110 = IRQ6
0x07 - 0111 = IRQ7
0x08 - 1000 = Reserved
0x09 - 1001 = IRQ9
0x0A - 1010 = IRQ10
0x0B - 1011 = IRQ11
0x0C - 1100 = IRQ12
0x0D - 1101 = Reserved
0x0E - 1110 = IRQ14
0x0F - 1111 = IRQ15
PIRQ[n]_ROUT[7] - PIRQ Routing Control
0x80 - The PIRQ is not routed.
Example
-------
lpc {
compatible = "intel,lpc";
#address-cells = <1>;
#size-cells = <1>;
intel,gen-dec = <0x800 0xfc 0x900 0xfc>;
intel,pirq-routing = <0x8b 0x8a 0x8b 0x8b
0x80 0x80 0x80 0x80>;
/*
* GPI routing
* 0 No effect (default)
* 1 SMI# (if corresponding ALT_GPI_SMI_EN bit is
* also set)
* 2 SCI (if corresponding GPIO_EN bit is also set)
*/
intel,gpi-routing = <0 0 0 0 0 0 0 2
1 0 0 0 0 0 0 0>;
/* Enable EC SMI source */
intel,alt-gp-smi-enable = <0x0100>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/misc/misc/fsl,mpc83xx-serdes.txt
+24
View File
@@ -0,0 +1,24 @@
MPC83xx SerDes controller devices
MPC83xx SoCs contain a built-in SerDes controller that determines which
protocols (SATA, PCI Express, SGMII, ...) are used on the system's serdes lines
and how the lines are configured.
Required properties:
- compatible: must be "fsl,mpc83xx-serdes"
- reg: must point to the serdes controller's register map
- proto: selects for which protocol the serdes lines are configured. One of
"sata", "pex", "pex-x2", "sgmii"
- serdes-clk: determines the frequency the serdes lines are configured for. One
of 100, 125, 150.
- vdd: determines whether 1.0V core VDD is used or not
Example:
SERDES: serdes@e3000 {
reg = <0xe3000 0x200>;
compatible = "fsl,mpc83xx-serdes";
proto = "pex";
serdes-clk = <100>;
vdd;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/misc/misc/gdsys,io-endpoint.txt
+20
View File
@@ -0,0 +1,20 @@
gdsys IO endpoint of IHS FPGA devices
The IO endpoint of IHS FPGA devices is a packet-based transmission interface
that allows interconnected gdsys devices to send and receive data over the
FPGA's main ethernet connection.
Required properties:
- compatible: must be "gdsys,io-endpoint"
- reg: describes the address and length of the endpoint's register map (within
the FPGA's register space)
Example:
fpga0_ep0 {
compatible = "gdsys,io-endpoint";
reg = <0x020 0x10
0x320 0x10
0x340 0x10
0x360 0x10>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/misc/misc/gdsys,iocon_fpga.txt
+19
View File
@@ -0,0 +1,19 @@
gdsys IHS FPGA for CON devices
The gdsys IHS FPGA is the main FPGA on gdsys CON devices. This driver provides
support for enabling and starting the FPGA, as well as verifying working bus
communication.
Required properties:
- compatible: must be "gdsys,iocon_fpga"
- reset-gpios: List of GPIOs controlling the FPGA's reset
- done-gpios: List of GPIOs notifying whether the FPGA's reconfiguration is
done
Example:
FPGA0 {
compatible = "gdsys,iocon_fpga";
reset-gpios = <&PPCPCA 26 0>;
done-gpios = <&GPIO_VB0 19 0>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/misc/misc/gdsys,iocpu_fpga.txt
+19
View File
@@ -0,0 +1,19 @@
gdsys IHS FPGA for CPU devices
The gdsys IHS FPGA is the main FPGA on gdsys CPU devices. This driver provides
support for enabling and starting the FPGA, as well as verifying working bus
communication.
Required properties:
- compatible: must be "gdsys,iocpu_fpga"
- reset-gpios: List of GPIOs controlling the FPGA's reset
- done-gpios: List of GPIOs notifying whether the FPGA's reconfiguration is
done
Example:
FPGA0 {
compatible = "gdsys,iocpu_fpga";
reset-gpios = <&PPCPCA 26 0>;
done-gpios = <&GPIO_VB0 19 0>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/misc/misc/gdsys,soc.txt
+16
View File
@@ -0,0 +1,16 @@
gdsys soc bus driver
This driver provides a simple interface for the busses associated with gdsys
IHS FPGAs. The bus itself contains devices whose register maps are contained
within the FPGA's register space.
Required properties:
- fpga: A phandle to the controlling IHS FPGA
Example:
FPGA0BUS: fpga0bus {
compatible = "gdsys,soc";
ranges = <0x0 0xe0600000 0x00004000>;
fpga = <&FPGA0>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/mmc/msm_sdhci.txt
+25
View File
@@ -0,0 +1,25 @@
Qualcomm Snapdragon SDHCI controller
Required properties:
- compatible : "qcom,sdhci-msm-v4"
- reg: Base address and length of registers:
- Host controller registers (SDHCI)
- SD Core registers
- clock: interface clock (must accept SD bus clock as a frequency)
Optional properties:
- index: If there is more than one controller - controller index (required
by generic SDHCI code).
- bus_width: Width of SD/eMMC bus (default 4)
- clock-frequency: Frequency of SD/eMMC bus (default 400 kHz)
Example:
sdhci@07864000 {
compatible = "qcom,sdhci-msm-v4";
reg = <0x7864900 0x11c 0x7864000 0x800>;
index = <0x1>;
bus-width = <0x4>;
clock = <&clkc 1>;
clock-frequency = <200000000>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/mmc/snps,dw-mmc.txt
+33
View File
@@ -0,0 +1,33 @@
Synopsys Designware Mobile Storage Host Controller extensions
used in Synopsys ARC devboards
Required Properties:
* compatible: should be - "snps,dw-mshc".
* bus-width: number of data lines connected to the controller.
* clocks: from common clock binding: handle to biu and ciu clocks for the
bus interface unit clock and the card interface unit clock.
* clock-names: from common clock binding: Shall be "biu" and "ciu".
Optional properties:
* fifo-depth: The maximum size of the tx/rx fifo's. If this property is not
specified, the default value of the fifo size is determined from the
controller registers.
* fifo-mode: Don't use DMA.
* max-frequency: Maximum operating clock frequency, driver uses 'ciu' clock
frequency if it is not set.
Example:
mmc0@f000a000 {
compatible = "snps,dw-mshc";
reg = <0xf000a000 0x400>;
bus-width = <4>;
fifo-depth = <256>;
clocks = <&mmcclk_biu>, <&mmcclk_ciu>;
clock-names = "biu", "ciu";
max-frequency = <25000000>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/mtd/altera_qspi.txt
+35
View File
@@ -0,0 +1,35 @@
Altera QUADSPI driver
Required properties:
- compatible: Should be "altr,quadspi-1.0"
- reg: Address and length of the register set for the device. It contains
the information of registers in the same order as described by reg-names
- reg-names: Should contain the reg names
"avl_csr": Should contain the register configuration base address
"avl_mem": Should contain the data base address
- #address-cells: Must be <1>.
- #size-cells: Must be <0>.
- flash device tree subnode, there must be a node with the following fields:
- compatible: Should contain the flash name:
1. EPCS: epcs16, epcs64, epcs128
2. EPCQ: epcq16, epcq32, epcq64, epcq128, epcq256, epcq512, epcq1024
3. EPCQ-L: epcql256, epcql512, epcql1024
- #address-cells: please refer to /mtd/partition.txt
- #size-cells: please refer to /mtd/partition.txt
For partitions inside each flash, please refer to /mtd/partition.txt
Example:
quadspi_controller_0: quadspi@0x180014a0 {
compatible = "altr,quadspi-1.0";
reg = <0x180014a0 0x00000020>,
<0x14000000 0x04000000>;
reg-names = "avl_csr", "avl_mem";
#address-cells = <1>;
#size-cells = <0>;
flash0: epcq512@0 {
compatible = "altr,epcq512";
#address-cells = <1>;
#size-cells = <1>;
};
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/mtd/mtd-physmap.txt
+88
View File
@@ -0,0 +1,88 @@
CFI or JEDEC memory-mapped NOR flash, MTD-RAM (NVRAM...)
Flash chips (Memory Technology Devices) are often used for solid state
file systems on embedded devices.
- compatible : should contain the specific model of mtd chip(s)
used, if known, followed by either "cfi-flash", "jedec-flash",
"mtd-ram" or "mtd-rom".
- reg : Address range(s) of the mtd chip(s)
It's possible to (optionally) define multiple "reg" tuples so that
non-identical chips can be described in one node.
- bank-width : Width (in bytes) of the bank. Equal to the
device width times the number of interleaved chips.
- device-width : (optional) Width of a single mtd chip. If
omitted, assumed to be equal to 'bank-width'.
- #address-cells, #size-cells : Must be present if the device has
sub-nodes representing partitions (see below). In this case
both #address-cells and #size-cells must be equal to 1.
- no-unaligned-direct-access: boolean to disable the default direct
mapping of the flash.
On some platforms (e.g. MPC5200) a direct 1:1 mapping may cause
problems with JFFS2 usage, as the local bus (LPB) doesn't support
unaligned accesses as implemented in the JFFS2 code via memcpy().
By defining "no-unaligned-direct-access", the flash will not be
exposed directly to the MTD users (e.g. JFFS2) any more.
- linux,mtd-name: allow to specify the mtd name for retro capability with
physmap-flash drivers as boot loader pass the mtd partition via the old
device name physmap-flash.
- use-advanced-sector-protection: boolean to enable support for the
advanced sector protection (Spansion: PPB - Persistent Protection
Bits) locking.
For JEDEC compatible devices, the following additional properties
are defined:
- vendor-id : Contains the flash chip's vendor id (1 byte).
- device-id : Contains the flash chip's device id (1 byte).
For ROM compatible devices (and ROM fallback from cfi-flash), the following
additional (optional) property is defined:
- erase-size : The chip's physical erase block size in bytes.
The device tree may optionally contain sub-nodes describing partitions of the
address space. See partition.txt for more detail.
Example:
flash@ff000000 {
compatible = "amd,am29lv128ml", "cfi-flash";
reg = <ff000000 01000000>;
bank-width = <4>;
device-width = <1>;
#address-cells = <1>;
#size-cells = <1>;
fs@0 {
label = "fs";
reg = <0 f80000>;
};
firmware@f80000 {
label ="firmware";
reg = <f80000 80000>;
read-only;
};
};
Here an example with multiple "reg" tuples:
flash@f0000000,0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "intel,pc48f4400p0vb", "cfi-flash";
reg = <0 0x00000000 0x02000000
0 0x02000000 0x02000000>;
bank-width = <2>;
partition@0 {
label = "test-part1";
reg = <0 0x04000000>;
};
};
An example using SRAM:
sram@2,0 {
compatible = "samsung,k6f1616u6a", "mtd-ram";
reg = <2 0 0x00200000>;
bank-width = <2>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/mtd/spi-nand.txt
+5
View File
@@ -0,0 +1,5 @@
SPI NAND flash
Required properties:
- compatible: should be "spi-nand"
- reg: should encode the chip-select line used to access the NAND chip
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/mtd/spi/spi-flash.txt
+25
View File
@@ -0,0 +1,25 @@
* MTD SPI driver for serial flash chips
Required properties:
- #address-cells, #size-cells : Must be present if the device has sub-nodes
representing partitions.
- compatible : Should be the manufacturer and the name of the chip. Bear in
mind that the DT binding is not U-Boot-only, but in case of
U-Boot, see spi_flash_params_table table in
drivers/mtd/spi/spi_flash_ids.c for the list of supported chips.
- reg : Chip-Select number
- spi-max-frequency : Maximum frequency of the SPI bus the chip can operate at
Optional properties:
- memory-map : Address and size of the flash, if memory mapped. This may
apply to Intel chipsets, which tend to memory-map flash.
Example:
flash: m25p80@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "spansion,m25p80";
reg = <0>;
spi-max-frequency = <40000000>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/mtd/stm32-fmc2-nand.txt
+59
View File
@@ -0,0 +1,59 @@
STMicroelectronics Flexible Memory Controller 2 (FMC2)
NAND Interface
Required properties:
- compatible: Should be one of:
* st,stm32mp15-fmc2
- reg: NAND flash controller memory areas.
First region contains the register location.
Regions 2 to 4 respectively contain the data, command,
and address space for CS0.
Regions 5 to 7 contain the same areas for CS1.
- interrupts: The interrupt number
- pinctrl-0: Standard Pinctrl phandle (see: pinctrl/pinctrl-bindings.txt)
- clocks: The clock needed by the NAND flash controller
Optional properties:
- resets: Reference to a reset controller asserting the FMC controller
- dmas: DMA specifiers (see: dma/stm32-mdma.txt)
- dma-names: Must be "tx", "rx" and "ecc"
Optional children nodes:
Children nodes represent the available NAND chips.
Optional properties:
- nand-on-flash-bbt: see nand.txt
- nand-ecc-strength: see nand.txt
- nand-ecc-step-size: see nand.txt
The following ECC strength and step size are currently supported:
- nand-ecc-strength = <1>, nand-ecc-step-size = <512> (Hamming)
- nand-ecc-strength = <4>, nand-ecc-step-size = <512> (BCH4)
- nand-ecc-strength = <8>, nand-ecc-step-size = <512> (BCH8) (default)
Example:
fmc: nand-controller@58002000 {
compatible = "st,stm32mp15-fmc2";
reg = <0x58002000 0x1000>,
<0x80000000 0x1000>,
<0x88010000 0x1000>,
<0x88020000 0x1000>,
<0x81000000 0x1000>,
<0x89010000 0x1000>,
<0x89020000 0x1000>;
interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&rcc FMC_K>;
resets = <&rcc FMC_R>;
pinctrl-names = "default";
pinctrl-0 = <&fmc_pins_a>;
#address-cells = <1>;
#size-cells = <0>;
nand@0 {
reg = <0>;
nand-on-flash-bbt;
#address-cells = <1>;
#size-cells = <1>;
};
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/nand/nvidia,tegra20-nand.txt
+53
View File
@@ -0,0 +1,53 @@
NAND Flash
----------
(there isn't yet a generic binding in Linux, so this describes what is in
U-Boot. There should not be Linux-specific or U-Boot specific binding, just
a binding that describes this hardware. But agreeing a binding in Linux in
the absence of a driver may be beyond my powers.)
The device node for a NAND flash device is as follows:
Required properties :
- compatible : Should be "manufacturer,device", "nand-flash"
This node should sit inside its controller.
Nvidia NAND Controller
----------------------
The device node for a NAND flash controller is as follows:
Optional properties:
nvidia,wp-gpios : GPIO of write-protect line, three cells in the format:
phandle, parameter, flags
nvidia,nand-width : bus width of the NAND device in bits
- nvidia,nand-timing : Timing parameters for the NAND. Each is in ns.
Order is: MAX_TRP_TREA, TWB, Max(tCS, tCH, tALS, tALH),
TWHR, Max(tCS, tCH, tALS, tALH), TWH, TWP, TRH, TADL
MAX_TRP_TREA is:
non-EDO mode: Max(tRP, tREA) + 6ns
EDO mode: tRP timing
The 'reg' property should provide the chip select used by the flash chip.
Example
-------
nand-controller@0x70008000 {
compatible = "nvidia,tegra20-nand";
#address-cells = <1>;
#size-cells = <0>;
nvidia,wp-gpios = <&gpio 59 0>; /* PH3 */
nvidia,nand-width = <8>;
nvidia,timing = <26 100 20 80 20 10 12 10 70>;
nand@0 {
reg = <0>;
compatible = "hynix,hy27uf4g2b", "nand-flash";
};
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/net/allwinner,sun4i-emac.txt
+19
View File
@@ -0,0 +1,19 @@
* Allwinner EMAC ethernet controller
Required properties:
- compatible: should be "allwinner,sun4i-a10-emac" (Deprecated:
"allwinner,sun4i-emac")
- reg: address and length of the register set for the device.
- interrupts: interrupt for the device
- phy: see ethernet.txt file in the same directory.
- clocks: A phandle to the reference clock for this device
Example:
emac: ethernet@01c0b000 {
compatible = "allwinner,sun4i-a10-emac";
reg = <0x01c0b000 0x1000>;
interrupts = <55>;
clocks = <&ahb_gates 17>;
phy = <&phy0>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/net/allwinner,sun4i-mdio.txt
+27
View File
@@ -0,0 +1,27 @@
* Allwinner A10 MDIO Ethernet Controller interface
Required properties:
- compatible: should be "allwinner,sun4i-a10-mdio"
(Deprecated: "allwinner,sun4i-mdio").
- reg: address and length of the register set for the device.
Optional properties:
- phy-supply: phandle to a regulator if the PHY needs one
Example at the SoC level:
mdio@01c0b080 {
compatible = "allwinner,sun4i-a10-mdio";
reg = <0x01c0b080 0x14>;
#address-cells = <1>;
#size-cells = <0>;
};
And at the board level:
mdio@01c0b080 {
phy-supply = <&reg_emac_3v3>;
phy0: ethernet-phy@0 {
reg = <0>;
};
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/net/allwinner,sun7i-a20-gmac.txt
+27
View File
@@ -0,0 +1,27 @@
* Allwinner GMAC ethernet controller
This device is a platform glue layer for stmmac.
Please see stmmac.txt for the other unchanged properties.
Required properties:
- compatible: Should be "allwinner,sun7i-a20-gmac"
- clocks: Should contain the GMAC main clock, and tx clock
The tx clock type should be "allwinner,sun7i-a20-gmac-clk"
- clock-names: Should contain the clock names "stmmaceth",
and "allwinner_gmac_tx"
Optional properties:
- phy-supply: phandle to a regulator if the PHY needs one
Examples:
gmac: ethernet@01c50000 {
compatible = "allwinner,sun7i-a20-gmac";
reg = <0x01c50000 0x10000>,
<0x01c20164 0x4>;
interrupts = <0 85 1>;
interrupt-names = "macirq";
clocks = <&ahb_gates 49>, <&gmac_tx>;
clock-names = "stmmaceth", "allwinner_gmac_tx";
phy-mode = "mii";
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/net/altera_tse.txt
+112
View File
@@ -0,0 +1,112 @@
* Altera Triple-Speed Ethernet MAC driver (TSE)
Required properties:
- compatible: Should be "altr,tse-1.0" for legacy SGDMA based TSE, and should
be "altr,tse-msgdma-1.0" for the preferred MSGDMA based TSE.
- reg: Address and length of the register set for the device. It contains
the information of registers in the same order as described by reg-names
- reg-names: Should contain the reg names
"control_port": MAC configuration space region
"tx_csr": xDMA Tx dispatcher control and status space region
"tx_desc": MSGDMA Tx dispatcher descriptor space region
"rx_csr" : xDMA Rx dispatcher control and status space region
"rx_desc": MSGDMA Rx dispatcher descriptor space region
"rx_resp": MSGDMA Rx dispatcher response space region
"s1": SGDMA descriptor memory
- interrupts: Should contain the TSE interrupts and it's mode.
- interrupt-names: Should contain the interrupt names
"rx_irq": xDMA Rx dispatcher interrupt
"tx_irq": xDMA Tx dispatcher interrupt
- rx-fifo-depth: MAC receive FIFO buffer depth in bytes
- tx-fifo-depth: MAC transmit FIFO buffer depth in bytes
- phy-mode: See ethernet.txt in the same directory.
- phy-handle: See ethernet.txt in the same directory.
- phy-addr: See ethernet.txt in the same directory. A configuration should
include phy-handle or phy-addr.
- altr,has-supplementary-unicast:
If present, TSE supports additional unicast addresses.
Otherwise additional unicast addresses are not supported.
- altr,has-hash-multicast-filter:
If present, TSE supports a hash based multicast filter.
Otherwise, hash-based multicast filtering is not supported.
- mdio device tree subnode: When the TSE has a phy connected to its local
mdio, there must be device tree subnode with the following
required properties:
- compatible: Must be "altr,tse-mdio".
- #address-cells: Must be <1>.
- #size-cells: Must be <0>.
For each phy on the mdio bus, there must be a node with the following
fields:
- reg: phy id used to communicate to phy.
- device_type: Must be "ethernet-phy".
Optional properties:
- local-mac-address: See ethernet.txt in the same directory.
- max-frame-size: See ethernet.txt in the same directory.
Example:
tse_sub_0_eth_tse_0: ethernet@0x1,00000000 {
compatible = "altr,tse-msgdma-1.0";
reg = <0x00000001 0x00000000 0x00000400>,
<0x00000001 0x00000460 0x00000020>,
<0x00000001 0x00000480 0x00000020>,
<0x00000001 0x000004A0 0x00000008>,
<0x00000001 0x00000400 0x00000020>,
<0x00000001 0x00000420 0x00000020>;
reg-names = "control_port", "rx_csr", "rx_desc", "rx_resp", "tx_csr", "tx_desc";
interrupt-parent = <&hps_0_arm_gic_0>;
interrupts = <0 41 4>, <0 40 4>;
interrupt-names = "rx_irq", "tx_irq";
rx-fifo-depth = <2048>;
tx-fifo-depth = <2048>;
address-bits = <48>;
max-frame-size = <1500>;
local-mac-address = [ 00 00 00 00 00 00 ];
phy-mode = "gmii";
altr,has-supplementary-unicast;
altr,has-hash-multicast-filter;
phy-handle = <&phy0>;
mdio {
compatible = "altr,tse-mdio";
#address-cells = <1>;
#size-cells = <0>;
phy0: ethernet-phy@0 {
reg = <0x0>;
device_type = "ethernet-phy";
};
phy1: ethernet-phy@1 {
reg = <0x1>;
device_type = "ethernet-phy";
};
};
};
tse_sub_1_eth_tse_0: ethernet@0x1,00001000 {
compatible = "altr,tse-msgdma-1.0";
reg = <0x00000001 0x00001000 0x00000400>,
<0x00000001 0x00001460 0x00000020>,
<0x00000001 0x00001480 0x00000020>,
<0x00000001 0x000014A0 0x00000008>,
<0x00000001 0x00001400 0x00000020>,
<0x00000001 0x00001420 0x00000020>;
reg-names = "control_port", "rx_csr", "rx_desc", "rx_resp", "tx_csr", "tx_desc";
interrupt-parent = <&hps_0_arm_gic_0>;
interrupts = <0 43 4>, <0 42 4>;
interrupt-names = "rx_irq", "tx_irq";
rx-fifo-depth = <2048>;
tx-fifo-depth = <2048>;
address-bits = <48>;
max-frame-size = <1500>;
local-mac-address = [ 00 00 00 00 00 00 ];
phy-mode = "gmii";
altr,has-supplementary-unicast;
altr,has-hash-multicast-filter;
phy-handle = <&phy1>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/net/aquantia-phy.txt
+25
View File
@@ -0,0 +1,25 @@
PHY nodes for Aquantia devices.
This text describes properties that are applicable to Aquantia PHY nodes in
addition to the bindings in phy.txt.
Aquantia PHYs allow some flexibility in the way they are wired in a system,
they allow MDI pins to be reversed, LEDs linked up in different weays, have an
I2C slave interface that can be used for debug. Normally the configuration
corresponding to these is driven by the PHY firmware with the downside that
a custom firmware is needed for each integration of a PHY.
Several optional bindings are defined that allow these configuration points to
be driven by the PHY driver and reduce dependency on specific FW versions.
Optional properties:
mdi-reversal: 0 or 1 indicating that reversal must be disabled/enabled.
Firmware default is used if the property is missing.
smb-addr: I2C/SMBus address to use, firmware default is used if the property
is missing.
Example node:
phy@00 {
reg = <0x00>;
mdi-reversal = <1>;
smb-addr = <0x25>;
};
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/net/ethernet.txt
+66
View File
@@ -0,0 +1,66 @@
The following properties are common to the Ethernet controllers:
NOTE: All 'phy*' properties documented below are Ethernet specific. For the
generic PHY 'phys' property, see
Documentation/devicetree/bindings/phy/phy-bindings.txt.
- local-mac-address: array of 6 bytes, specifies the MAC address that was
assigned to the network device;
- mac-address: array of 6 bytes, specifies the MAC address that was last used by
the boot program; should be used in cases where the MAC address assigned to
the device by the boot program is different from the "local-mac-address"
property;
- nvmem-cells: phandle, reference to an nvmem node for the MAC address;
- nvmem-cell-names: string, should be "mac-address" if nvmem is to be used;
- max-speed: number, specifies maximum speed in Mbit/s supported by the device;
- max-frame-size: number, maximum transfer unit (IEEE defined MTU), rather than
the maximum frame size (there's contradiction in the Devicetree
Specification).
- phy-mode: string, operation mode of the PHY interface. This is now a de-facto
standard property; supported values are:
* "internal"
* "mii"
* "gmii"
* "sgmii"
* "qsgmii"
* "tbi"
* "rev-mii"
* "rmii"
* "rgmii" (RX and TX delays are added by the MAC when required)
* "rgmii-id" (RGMII with internal RX and TX delays provided by the PHY, the
MAC should not add the RX or TX delays in this case)
* "rgmii-rxid" (RGMII with internal RX delay provided by the PHY, the MAC
should not add an RX delay in this case)
* "rgmii-txid" (RGMII with internal TX delay provided by the PHY, the MAC
should not add an TX delay in this case)
* "rtbi"
* "smii"
* "xgmii"
* "trgmii"
* "2000base-x",
* "2500base-x",
* "rxaui"
* "xaui"
* "10gbase-kr" (10GBASE-KR, XFI, SFI)
- phy-connection-type: the same as "phy-mode" property but described in the
Devicetree Specification;
- phy-handle: phandle, specifies a reference to a node representing a PHY
device; this property is described in the Devicetree Specification and so
preferred;
- phy: the same as "phy-handle" property, not recommended for new bindings.
- phy-device: the same as "phy-handle" property, not recommended for new
bindings.
- rx-fifo-depth: the size of the controller's receive fifo in bytes. This
is used for components that can have configurable receive fifo sizes,
and is useful for determining certain configuration settings such as
flow control thresholds.
- tx-fifo-depth: the size of the controller's transmit fifo in bytes. This
is used for components that can have configurable fifo sizes.
- managed: string, specifies the PHY management type. Supported values are:
"auto", "in-band-status". "auto" is the default, it usess MDIO for
management if fixed-link is not specified.
Child nodes of the Ethernet controller are typically the individual PHY devices
connected via the MDIO bus (sometimes the MDIO bus controller is separate).
They are described in the phy.txt file in this same directory.
For non-MDIO PHY management see fixed-link.txt.
source/bootloader/u-boot-2020.01/doc/device-tree-bindings/net/fixed-link.txt
+30
View File
@@ -0,0 +1,30 @@
Fixed link Device Tree binding
------------------------------
Some Ethernet MACs have a "fixed link", and are not connected to a
normal MDIO-managed PHY device. For those situations, a Device Tree
binding allows to describe a "fixed link".
Such a fixed link situation is described by creating a 'fixed-link'
sub-node of the Ethernet MAC device node, with the following
properties:
* 'speed' (integer, mandatory), to indicate the link speed. Accepted
values are 10, 100 and 1000
* 'full-duplex' (boolean, optional), to indicate that full duplex is
used. When absent, half duplex is assumed.
* 'pause' (boolean, optional), to indicate that pause should be
enabled.
* 'asym-pause' (boolean, optional), to indicate that asym_pause should
be enabled.
Examples:
ethernet@0 {
...
fixed-link {
speed = <1000>;
full-duplex;
};
...
};

Some files were not shown because too many files have changed in this diff Show More