linux/Documentation/devicetree/bindings/mtd/partition.txt
Rafał Miłecki 5178b99cd3 dt-bindings: mtd: document Broadcom's BCM47xx partitions
Broadcom based home router devices use partitions which have to be
discovered in a specific way. They are not fixed and there is not any
standard partition table. This commit adds and describes a new custom
binding for such devices.

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
2018-05-23 10:08:44 +02:00

112 lines
3.3 KiB
Plaintext

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.
Available bindings are listed in the "partitions" subdirectory.
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>;
};
};
};