Mugunthan V N | 6f89d04 | 2016-01-16 21:33:58 +0530 | [diff] [blame] | 1 | The chosen node |
| 2 | --------------- |
| 3 | The chosen node does not represent a real device, but serves as a place |
| 4 | for passing data like which serial device to used to print the logs etc |
| 5 | |
| 6 | |
| 7 | stdout-path property |
| 8 | -------------------- |
| 9 | Device trees may specify the device to be used for boot console output |
| 10 | with a stdout-path property under /chosen. |
| 11 | |
| 12 | Example |
| 13 | ------- |
| 14 | / { |
| 15 | chosen { |
| 16 | stdout-path = "/serial@f00:115200"; |
| 17 | }; |
| 18 | |
| 19 | serial@f00 { |
| 20 | compatible = "vendor,some-uart"; |
| 21 | reg = <0xf00 0x10>; |
| 22 | }; |
| 23 | }; |
| 24 | |
| 25 | tick-timer property |
| 26 | ------------------- |
| 27 | In a system there are multiple timers, specify which timer to be used |
| 28 | as the tick-timer. Earlier it was hardcoded in the timer driver now |
| 29 | since device tree has all the timer nodes. Specify which timer to be |
| 30 | used as tick timer. |
| 31 | |
| 32 | Example |
| 33 | ------- |
| 34 | / { |
| 35 | chosen { |
| 36 | tick-timer = "/timer2@f00"; |
| 37 | }; |
| 38 | |
| 39 | timer2@f00 { |
| 40 | compatible = "vendor,some-timer"; |
| 41 | reg = <0xf00 0x10>; |
| 42 | }; |
| 43 | }; |
Philipp Tomsich | 4f21299 | 2017-03-28 11:03:00 +0200 | [diff] [blame] | 44 | |
Philipp Tomsich | ce86031 | 2018-11-27 23:00:18 +0100 | [diff] [blame] | 45 | u-boot,bootcount-device property |
| 46 | -------------------------------- |
| 47 | |
| 48 | In a DM-based system, the bootcount may be stored in a device known to |
| 49 | the DM framework (e.g. in a battery-backed SRAM area within a RTC |
| 50 | device) managed by a device conforming to UCLASS_BOOTCOUNT. If |
| 51 | multiple such devices are present in a system concurrently, then the |
| 52 | u-boot,bootcount-device property can select the preferred target. |
| 53 | |
| 54 | Example |
| 55 | ------- |
| 56 | / { |
| 57 | chosen { |
| 58 | u-boot,bootcount-device = &bootcount-rv3029; |
| 59 | }; |
| 60 | |
| 61 | bootcount-rv3029: bootcount@0 { |
| 62 | compatible = "u-boot,bootcount-rtc"; |
| 63 | rtc = &rv3029; |
| 64 | offset = <0x38>; |
| 65 | }; |
| 66 | |
| 67 | i2c2 { |
| 68 | rv3029: rtc@56 { |
| 69 | compatible = "mc,rv3029"; |
| 70 | reg = <0x56>; |
| 71 | }; |
| 72 | }; |
| 73 | }; |
| 74 | |
Philipp Tomsich | 4f21299 | 2017-03-28 11:03:00 +0200 | [diff] [blame] | 75 | u-boot,spl-boot-order property |
| 76 | ------------------------------ |
| 77 | |
| 78 | In a system using an SPL stage and having multiple boot sources |
| 79 | (e.g. SPI NOR flash, on-board eMMC and a removable SD-card), the boot |
| 80 | device may be probed by reading the image and verifying an image |
| 81 | signature. |
| 82 | |
| 83 | If the SPL is configured through the device-tree, the boot-order can |
| 84 | be configured with the spl-boot-order property under the /chosen node. |
| 85 | Each list element of the property should specify a device to be probed |
| 86 | in the order they are listed: references (i.e. implicit paths), a full |
| 87 | path or an alias is expected for each entry. |
| 88 | |
Philipp Tomsich | ec83ff5 | 2017-09-29 19:27:57 +0200 | [diff] [blame] | 89 | A special specifier "same-as-spl" can be used at any position in the |
| 90 | boot-order to direct U-Boot to insert the device the SPL was booted |
| 91 | from there. Whether this is indeed inserted or silently ignored (if |
| 92 | it is not supported on any given SoC/board or if the boot-device is |
| 93 | not available to continue booting from) is implementation-defined. |
| 94 | Note that if "same-as-spl" expands to an actual node for a given |
| 95 | board, the corresponding node may appear multiple times in the |
| 96 | boot-order (as there currently exists no mechanism to suppress |
| 97 | duplicates from the list). |
| 98 | |
Philipp Tomsich | 4f21299 | 2017-03-28 11:03:00 +0200 | [diff] [blame] | 99 | Example |
| 100 | ------- |
| 101 | / { |
| 102 | chosen { |
Philipp Tomsich | ec83ff5 | 2017-09-29 19:27:57 +0200 | [diff] [blame] | 103 | u-boot,spl-boot-order = "same-as-spl", &sdmmc, "/sdhci@fe330000"; |
Philipp Tomsich | 4f21299 | 2017-03-28 11:03:00 +0200 | [diff] [blame] | 104 | }; |
| 105 | }; |
Philipp Tomsich | 4a577e5 | 2018-05-24 17:15:51 +0200 | [diff] [blame] | 106 | |
| 107 | u-boot,spl-boot-device property |
| 108 | ------------------------------- |
| 109 | |
| 110 | This property is a companion-property to the u-boot,spl-boot-order and |
| 111 | will be injected automatically by the SPL stage to notify a later stage |
| 112 | of where said later stage was booted from. |
| 113 | |
| 114 | You should not define this property yourself in the device-tree, as it |
| 115 | may be overwritten without warning. |
Tien Fong Chee | f53998b | 2018-07-06 16:27:35 +0800 | [diff] [blame] | 116 | |
| 117 | firmware-loader property |
| 118 | ------------------------ |
| 119 | Multiple file system firmware loader nodes could be defined in device trees for |
| 120 | multiple storage type and their default partition, then a property |
| 121 | "firmware-loader" can be used to pass default firmware loader |
| 122 | node(default storage type) to the firmware loader driver. |
| 123 | |
| 124 | Example |
| 125 | ------- |
| 126 | / { |
| 127 | chosen { |
| 128 | firmware-loader = &fs_loader0; |
| 129 | }; |
| 130 | |
| 131 | fs_loader0: fs-loader@0 { |
| 132 | u-boot,dm-pre-reloc; |
| 133 | compatible = "u-boot,fs-loader"; |
| 134 | phandlepart = <&mmc 1>; |
| 135 | }; |
| 136 | }; |
Simon Glass | 3c601b1 | 2020-07-07 13:12:06 -0600 | [diff] [blame] | 137 | |
| 138 | u-boot,acpi-ssdt-order |
| 139 | ---------------------- |
| 140 | |
| 141 | This provides the ordering to use when writing device data to the ACPI SSDT |
| 142 | (Secondary System Descriptor Table). Each cell is a phandle pointer to a device |
| 143 | node to add. The ACPI information is written in this order. |
| 144 | |
| 145 | If the ordering does not include all nodes, an error is generated. |