phy: atheros: ar8035: Fix clock output calculation

[oweals/u-boot.git] / doc / device-tree-bindings / chosen.txt

diff --git a/doc/device-tree-bindings/chosen.txt b/doc/device-tree-bindings/chosen.txt
index bf9a30a8f97cdb0211dd4eb2a6189d3d460ac7dd..395c9501e3bdafd01ffac650e7cab7b3c0f8c3f9 100644 (file)
--- a/doc/device-tree-bindings/chosen.txt
+++ b/doc/device-tree-bindings/chosen.txt
@@ -41,3 +41,96 @@ Example
                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>;
+       };
+};