summaryrefslogtreecommitdiff
path: root/Documentation/devicetree/bindings/mtd/partition.txt
blob: 36f3b769a62675cccac1a23ec8287e08bd91653e (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
Flash partitions in device tree
===============================

Flash devices can be partitioned into one or more functional ranges (e.g. "boot
code", "nvram", "kernel").

Different devices may be partitioned in a different ways. Some may use a fixed
flash layout set at production time. Some may use on-flash table that describes
the geometry and naming/purpose of each functional region. It is also possible
to see these methods mixed.

To assist system software in locating partitions, we allow describing which
method is used for a given flash device. To describe the method there should be
a subnode of the flash device that is named 'partitions'. It must have a
'compatible' property, which is used to identify the method to use.

We currently only document a binding for fixed layouts.


Fixed Partitions
================

Partitions can be represented by sub-nodes of a flash device. This can be used
on platforms which have strong conventions about which portions of a flash are
used for what purposes, but which don't use an on-flash partition table such
as RedBoot.

The partition table should be a subnode of the flash node and should be named
'partitions'. This node should have the following property:
- compatible : (required) must be "fixed-partitions"
Partitions are then defined in subnodes of the partitions node.

For backwards compatibility partitions as direct subnodes of the flash device are
supported. This use is discouraged.
NOTE: also for backwards compatibility, direct subnodes that have a compatible
string are not considered partitions, as they may be used for other bindings.

#address-cells & #size-cells must both be present in the partitions subnode of the
flash device. There are two valid values for both:
<1>: for partitions that require a single 32-bit cell to represent their
     size/address (aka the value is below 4 GiB)
<2>: for partitions that require two 32-bit cells to represent their
     size/address (aka the value is 4 GiB or greater).

Required properties:
- reg : The partition's offset and size within the flash

Optional properties:
- label : The label / name for this partition.  If omitted, the label is taken
  from the node name (excluding the unit address).
- read-only : This parameter, if present, is a hint to Linux that this
  partition should only be mounted read-only. This is usually used for flash
  partitions containing early-boot firmware images or data which should not be
  clobbered.
- lock : Do not unlock the partition at initialization time (not supported on
  all devices)

Examples:


flash@0 {
	partitions {
		compatible = "fixed-partitions";
		#address-cells = <1>;
		#size-cells = <1>;

		partition@0 {
			label = "u-boot";
			reg = <0x0000000 0x100000>;
			read-only;
		};

		uimage@100000 {
			reg = <0x0100000 0x200000>;
		};
	};
};

flash@1 {
	partitions {
		compatible = "fixed-partitions";
		#address-cells = <1>;
		#size-cells = <2>;

		/* a 4 GiB partition */
		partition@0 {
			label = "filesystem";
			reg = <0x00000000 0x1 0x00000000>;
		};
	};
};

flash@2 {
	partitions {
		compatible = "fixed-partitions";
		#address-cells = <2>;
		#size-cells = <2>;

		/* an 8 GiB partition */
		partition@0 {
			label = "filesystem #1";
			reg = <0x0 0x00000000 0x2 0x00000000>;
		};

		/* a 4 GiB partition */
		partition@200000000 {
			label = "filesystem #2";
			reg = <0x2 0x00000000 0x1 0x00000000>;
		};
	};
};