e488ca9f8d
As noted here [1], there are potentially future conflicts if we try to
use MTD's "partitions" subnode to describe anything besides just the
fixed-in-the-device-tree partitions currently described in this
document. Particularly, there was a proposal to use this node for the
AFS parser too.
It can pose a (small) problem to try to differentiate the following
nodes:
// using binding as currently specified
partitions {
#address-cells = <x>;
#size-cells = <y>;
partition@0 {
...;
};
};
and
// proposed future binding
partitions {
compatible = "arm,arm-flash-structure";
};
It's especially difficult if other uses of this node start having
subnodes.
So, since the "partitions" node is new in v4.4, let's fixup the binding
before release so that it requires a compatible property, so it's much
clearer to distinguish. e.g.:
// proposed
partitions {
compatible = "fixed-partitions";
#address-cells = <x>;
#size-cells = <y>;
partition@0 {
...;
};
};
[1] Subject: "mtd: create a partition type device tree binding"
http://lkml.kernel.org/g/20151113220039.GA74382@google.com
http://lists.infradead.org/pipermail/linux-mtd/2015-November/063355.html
http://lists.infradead.org/pipermail/linux-mtd/2015-November/063364.html
Cc: Michal Suchanek <hramrach@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
90 lines
2.5 KiB
Plaintext
90 lines
2.5 KiB
Plaintext
Representing flash partitions in devicetree
|
|
|
|
Partitions can be represented by sub-nodes of an mtd 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 mtd 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 mtd 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
|
|
mtd 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 mtd bank.
|
|
|
|
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.
|
|
|
|
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>;
|
|
};
|
|
};
|
|
};
|