1 Flash partitions in device tree
2 ===============================
4 Flash devices can be partitioned into one or more functional ranges (e.g. "boot
5 code", "nvram", "kernel").
7 Different devices may be partitioned in a different ways. Some may use a fixed
8 flash layout set at production time. Some may use on-flash table that describes
9 the geometry and naming/purpose of each functional region. It is also possible
10 to see these methods mixed.
12 To assist system software in locating partitions, we allow describing which
13 method is used for a given flash device. To describe the method there should be
14 a subnode of the flash device that is named 'partitions'. It must have a
15 'compatible' property, which is used to identify the method to use.
17 When a single partition is represented with a DT node (it depends on a used
18 format) it may also be described using above rules ('compatible' and optionally
19 some extra properties / subnodes). It allows describing more complex,
20 hierarchical (multi-level) layouts and should be used if there is some
21 significant relation between partitions or some partition internally uses
22 another partitioning method.
24 Available bindings are listed in the "partitions" subdirectory.
30 Partitions can be represented by sub-nodes of a flash device. This can be used
31 on platforms which have strong conventions about which portions of a flash are
32 used for what purposes, but which don't use an on-flash partition table such
35 The partition table should be a subnode of the flash node and should be named
36 'partitions'. This node should have the following property:
37 - compatible : (required) must be "fixed-partitions"
38 Partitions are then defined in subnodes of the partitions node.
40 For backwards compatibility partitions as direct subnodes of the flash device are
41 supported. This use is discouraged.
42 NOTE: also for backwards compatibility, direct subnodes that have a compatible
43 string are not considered partitions, as they may be used for other bindings.
45 #address-cells & #size-cells must both be present in the partitions subnode of the
46 flash device. There are two valid values for both:
47 <1>: for partitions that require a single 32-bit cell to represent their
48 size/address (aka the value is below 4 GiB)
49 <2>: for partitions that require two 32-bit cells to represent their
50 size/address (aka the value is 4 GiB or greater).
53 - reg : The partition's offset and size within the flash
56 - label : The label / name for this partition. If omitted, the label is taken
57 from the node name (excluding the unit address).
58 - read-only : This parameter, if present, is a hint to Linux that this
59 partition should only be mounted read-only. This is usually used for flash
60 partitions containing early-boot firmware images or data which should not be
62 - lock : Do not unlock the partition at initialization time (not supported on
70 compatible = "fixed-partitions";
76 reg = <0x0000000 0x100000>;
81 reg = <0x0100000 0x200000>;
88 compatible = "fixed-partitions";
92 /* a 4 GiB partition */
95 reg = <0x00000000 0x1 0x00000000>;
102 compatible = "fixed-partitions";
103 #address-cells = <2>;
106 /* an 8 GiB partition */
108 label = "filesystem #1";
109 reg = <0x0 0x00000000 0x2 0x00000000>;
112 /* a 4 GiB partition */
113 partition@200000000 {
114 label = "filesystem #2";
115 reg = <0x2 0x00000000 0x1 0x00000000>;
122 compatible = "fixed-partitions";
123 #address-cells = <1>;
127 label = "bootloader";
128 reg = <0x000000 0x100000>;
134 reg = <0x100000 0xe00000>;
135 compatible = "brcm,trx";
139 label = "calibration";
140 reg = <0xf00000 0x100000>;
141 compatible = "fixed-partitions";
142 ranges = <0 0xf00000 0x100000>;
143 #address-cells = <1>;
148 reg = <0x000000 0x080000>;
153 reg = <0x080000 0x080000>;