summaryrefslogtreecommitdiff
path: root/doc/device-tree-bindings/chosen.txt
blob: e5ba6720ce137df25a47bcb7abb8bdfe4037a4d8 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
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>;
	};
};

u-boot,acpi-ssdt-order
----------------------

This provides the ordering to use when writing device data to the ACPI SSDT
(Secondary System Descriptor Table). Each cell is a phandle pointer to a device
node to add. The ACPI information is written in this order.

If the ordering does not include all nodes, an error is generated.

e820-entries
------------

This provides a way to add entries to the e820 table which tells the OS about
the memory map. The property contains three sets of 64-bit values:

   address   - Start address of region
   size      - Size of region
   flags     - Flags (E820_...)

Example:

chosen {
	e820-entries = /bits/ 64 <
		IOMAP_P2SB_BAR IOMAP P2SB_SIZE E820_RESERVED
		MCH_BASE_ADDRESS     MCH_SIZE  E820_RESERVED>;
};