[RFC PATCH 0/7] mtd: partitions: add of_match_table support

[Brian Norris]

Hi,

There have been several discussions [1] about adding a device tree binding for
associating flash devices with the partition parser(s) that are used on the
flash. There are a few reasons:

(1) drivers shouldn't have to be encoding platform knowledge by listing what
parsers might be used on a given system (this is the currently all that's
supported)
(2) we can't just scan for all supported parsers (like the block system does), since
there is a wide diversity of "formats" (no standardization), and it is not
always safe or efficient to attempt to do so, particularly since many of
them allow their data structures to be placed anywhere on the flash, and
so require scanning the entire flash device to find them.

So instead, let's support a new binding so that a device tree can specify what
partition formats might be used. This seems like a reasonable choice (even
though it's not strictly a hardware description) because the flash layout /
partitioning is often very closely tied with the bootloader/firmware, at
production time.

Also, as an example first-use of this mechanism, I support Google's FMAP flash
structure, used on Chrome OS devices.

Note that this is an RFC, mainly for the reason noted in patch 6 ("RFC: mtd:
partitions: enable of_match_table matching"): the of_match_table support won't
yet autoload a partition parser that is built as a module. I'm not quite sure
if there's a lot of value in supporting MTD parsers as modules (block partition
support can't be), but that is supported for "by-name" parser lookups in MTD
already, so I don't feel like dropping that feature yet. Tips or thoughts are
particularly welcome on this aspect!

Also note that there's an existing undocumented binding for a
"linux,part-probe" property, but it is only usable on the physmap_of.c driver
at the moment, and it is IMO not a good binding. I posted my thoughts on that
previously here [2], and since no one else cared to make a better one...I did
it myself.

I'd love it if we could kill the unreviewed binding off in favor of something
more like this...

Currently based on v2 of "mtd: partitions: support cleanup callback for
parsers":

http://lkml.kernel.org/g/1449271518-118900-1-git-se...@gmail.com

and this series
("mtd: ofpart: don't complain about missing 'partitions' node too loudly" and
"doc: dt: mtd: partitions: add compatible property to "partitions" node"):

http://lkml.kernel.org/g/1449194529-145705-1-git-se...@gmail.com

Both of which should hopefully be merged soon.

The current total of this work is stashed here for now:

git fetch git://git.infradead.org/users/norris/linux-mtd.git partition-of-match

I may rewrite this branch if I post future revisions of these patch sets, FYI.

I look forward to your reviews.

Regards,
Brian

[1] Trying to extend "linux,part-probe":
http://patchwork.ozlabs.org/patch/475988/
For bcm47xxpart:
http://patchwork.ozlabs.org/patch/475986/
For AFS:
http://patchwork.ozlabs.org/patch/537827/

[2] "mtd: document linux-specific partition parser DT binding"
http://lists.infradead.org/pipermail/linux-mtd/2015-October/062773.html

Brian Norris (7):
mtd: move partition parsers to drivers/mtd/partitions/
mtd: move partition parsers' Kconfig under a sub-menu
doc: dt: mtd: partition: add on-flash format binding
mtd: add of_match_mtd_parser() and of_mtd_match_mtd_parser() helpers
mtd: partitions: factor out "match by name" handling
RFC: mtd: partitions: enable of_match_table matching
mtd: partitions: add Google's FMAP partition parser

.../devicetree/bindings/mtd/partition.txt | 75 ++++++-
drivers/mtd/Kconfig | 134 +-----------
drivers/mtd/Makefile | 8 +-
drivers/mtd/mtdpart.c | 99 +++++++--
drivers/mtd/partitions/Kconfig | 138 +++++++++++++
drivers/mtd/partitions/Makefile | 8 +
drivers/mtd/{ => partitions}/afs.c | 0
drivers/mtd/{ => partitions}/ar7part.c | 0
drivers/mtd/{ => partitions}/bcm47xxpart.c | 0
drivers/mtd/{ => partitions}/bcm63xxpart.c | 0
drivers/mtd/{ => partitions}/cmdlinepart.c | 0
drivers/mtd/partitions/google_fmap.c | 226 +++++++++++++++++++++
drivers/mtd/{ => partitions}/ofpart.c | 0
drivers/mtd/{ => partitions}/redboot.c | 0
drivers/of/of_mtd.c | 33 +++
include/linux/mtd/partitions.h | 2 +
include/linux/of_mtd.h | 13 ++
17 files changed, 577 insertions(+), 159 deletions(-)
create mode 100644 drivers/mtd/partitions/Kconfig
create mode 100644 drivers/mtd/partitions/Makefile
rename drivers/mtd/{ => partitions}/afs.c (100%)
rename drivers/mtd/{ => partitions}/ar7part.c (100%)
rename drivers/mtd/{ => partitions}/bcm47xxpart.c (100%)
rename drivers/mtd/{ => partitions}/bcm63xxpart.c (100%)
rename drivers/mtd/{ => partitions}/cmdlinepart.c (100%)
create mode 100644 drivers/mtd/partitions/google_fmap.c
rename drivers/mtd/{ => partitions}/ofpart.c (100%)
rename drivers/mtd/{ => partitions}/redboot.c (100%)

--
2.6.0.rc2.230.g3dd15c0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Brian Norris]

For better organization.

Signed-off-by: Brian Norris <computer...@gmail.com>
---
drivers/mtd/Kconfig | 134 +----------------------------------------
drivers/mtd/partitions/Kconfig | 131 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 134 insertions(+), 131 deletions(-)
create mode 100644 drivers/mtd/partitions/Kconfig

diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index 42cc953309f1..a06e80d24499 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -23,137 +23,9 @@ config MTD_TESTS
WARNING: some of the tests will ERASE entire MTD device which they
test. Do not use these tests unless you really know what you do.

-config MTD_REDBOOT_PARTS
- tristate "RedBoot partition table parsing"
- ---help---
- RedBoot is a ROM monitor and bootloader which deals with multiple
- 'images' in flash devices by putting a table one of the erase
- blocks on the device, similar to a partition table, which gives
- the offsets, lengths and names of all the images stored in the
- flash.
-
- If you need code which can detect and parse this table, and register
- MTD 'partitions' corresponding to each image in the table, enable
- this option.
-
- You will still need the parsing functions to be called by the driver
- for your particular device. It won't happen automatically. The
- SA1100 map driver (CONFIG_MTD_SA1100) has an option for this, for
- example.
-
-if MTD_REDBOOT_PARTS
-
-config MTD_REDBOOT_DIRECTORY_BLOCK
- int "Location of RedBoot partition table"
- default "-1"
- ---help---
- This option is the Linux counterpart to the
- CYGNUM_REDBOOT_FIS_DIRECTORY_BLOCK RedBoot compile time
- option.
-
- The option specifies which Flash sectors holds the RedBoot
- partition table. A zero or positive value gives an absolute
- erase block number. A negative value specifies a number of
- sectors before the end of the device.
-
- For example "2" means block number 2, "-1" means the last
- block and "-2" means the penultimate block.
-
-config MTD_REDBOOT_PARTS_UNALLOCATED
- bool "Include unallocated flash regions"
- help
- If you need to register each unallocated flash region as a MTD
- 'partition', enable this option.
-
-config MTD_REDBOOT_PARTS_READONLY
- bool "Force read-only for RedBoot system images"
- help
- If you need to force read-only for 'RedBoot', 'RedBoot Config' and
- 'FIS directory' images, enable this option.
-
-endif # MTD_REDBOOT_PARTS
-
-config MTD_CMDLINE_PARTS
- tristate "Command line partition table parsing"
- depends on MTD
- ---help---
- Allow generic configuration of the MTD partition tables via the kernel
- command line. Multiple flash resources are supported for hardware where
- different kinds of flash memory are available.
-
- You will still need the parsing functions to be called by the driver
- for your particular device. It won't happen automatically. The
- SA1100 map driver (CONFIG_MTD_SA1100) has an option for this, for
- example.
-
- The format for the command line is as follows:
-
- mtdparts=<mtddef>[;<mtddef]
- <mtddef> := <mtd-id>:<partdef>[,<partdef>]
- <partdef> := <size>[@offset][<name>][ro]
- <mtd-id> := unique id used in mapping driver/device
- <size> := standard linux memsize OR "-" to denote all
- remaining space
- <name> := (NAME)
-
- Due to the way Linux handles the command line, no spaces are
- allowed in the partition definition, including mtd id's and partition
- names.
-
- Examples:
-
- 1 flash resource (mtd-id "sa1100"), with 1 single writable partition:
- mtdparts=sa1100:-
-
- Same flash, but 2 named partitions, the first one being read-only:
- mtdparts=sa1100:256k(ARMboot)ro,-(root)
-
- If unsure, say 'N'.
-
-config MTD_AFS_PARTS
- tristate "ARM Firmware Suite partition parsing"
- depends on (ARM || ARM64)
- ---help---
- The ARM Firmware Suite allows the user to divide flash devices into
- multiple 'images'. Each such image has a header containing its name
- and offset/size etc.
-
- If you need code which can detect and parse these tables, and
- register MTD 'partitions' corresponding to each image detected,
- enable this option.
-
- You will still need the parsing functions to be called by the driver
- for your particular device. It won't happen automatically. The
- 'physmap' map driver (CONFIG_MTD_PHYSMAP) does this, for example.
-
-config MTD_OF_PARTS
- tristate "OpenFirmware partitioning information support"
- default y
- depends on OF
- help
- This provides a partition parsing function which derives
- the partition map from the children of the flash node,
- as described in Documentation/devicetree/bindings/mtd/partition.txt.
-
-config MTD_AR7_PARTS
- tristate "TI AR7 partitioning support"
- ---help---
- TI AR7 partitioning support
-
-config MTD_BCM63XX_PARTS
- tristate "BCM63XX CFE partitioning support"
- depends on BCM63XX
- select CRC32
- help
- This provides partions parsing for BCM63xx devices with CFE
- bootloaders.
-
-config MTD_BCM47XX_PARTS
- tristate "BCM47XX partitioning support"
- depends on BCM47XX || ARCH_BCM_5301X
- help
- This provides partitions parser for devices based on BCM47xx
- boards.
+menu "Partition Parsers"
+source "drivers/mtd/partitions/Kconfig"
+endmenu

comment "User Modules And Translation Layers"

diff --git a/drivers/mtd/partitions/Kconfig b/drivers/mtd/partitions/Kconfig
new file mode 100644
index 000000000000..0827d7a8be4e
--- /dev/null
+++ b/drivers/mtd/partitions/Kconfig
@@ -0,0 +1,131 @@
+config MTD_REDBOOT_PARTS
+ tristate "RedBoot partition table parsing"
+ ---help---
+ RedBoot is a ROM monitor and bootloader which deals with multiple
+ 'images' in flash devices by putting a table one of the erase
+ blocks on the device, similar to a partition table, which gives
+ the offsets, lengths and names of all the images stored in the
+ flash.
+
+ If you need code which can detect and parse this table, and register
+ MTD 'partitions' corresponding to each image in the table, enable
+ this option.
+
+ You will still need the parsing functions to be called by the driver
+ for your particular device. It won't happen automatically. The
+ SA1100 map driver (CONFIG_MTD_SA1100) has an option for this, for
+ example.
+
+if MTD_REDBOOT_PARTS
+
+config MTD_REDBOOT_DIRECTORY_BLOCK
+ int "Location of RedBoot partition table"
+ default "-1"
+ ---help---
+ This option is the Linux counterpart to the
+ CYGNUM_REDBOOT_FIS_DIRECTORY_BLOCK RedBoot compile time
+ option.
+
+ The option specifies which Flash sectors holds the RedBoot
+ partition table. A zero or positive value gives an absolute
+ erase block number. A negative value specifies a number of
+ sectors before the end of the device.
+
+ For example "2" means block number 2, "-1" means the last
+ block and "-2" means the penultimate block.
+
+config MTD_REDBOOT_PARTS_UNALLOCATED
+ bool "Include unallocated flash regions"
+ help
+ If you need to register each unallocated flash region as a MTD
+ 'partition', enable this option.
+
+config MTD_REDBOOT_PARTS_READONLY
+ bool "Force read-only for RedBoot system images"
+ help
+ If you need to force read-only for 'RedBoot', 'RedBoot Config' and
+ 'FIS directory' images, enable this option.
+
+endif # MTD_REDBOOT_PARTS
+
+config MTD_CMDLINE_PARTS
+ tristate "Command line partition table parsing"
+ depends on MTD
+ ---help---
+ Allow generic configuration of the MTD partition tables via the kernel
+ command line. Multiple flash resources are supported for hardware where
+ different kinds of flash memory are available.
+
+ You will still need the parsing functions to be called by the driver
+ for your particular device. It won't happen automatically. The
+ SA1100 map driver (CONFIG_MTD_SA1100) has an option for this, for
+ example.
+
+ The format for the command line is as follows:
+
+ mtdparts=<mtddef>[;<mtddef]
+ <mtddef> := <mtd-id>:<partdef>[,<partdef>]
+ <partdef> := <size>[@offset][<name>][ro]
+ <mtd-id> := unique id used in mapping driver/device
+ <size> := standard linux memsize OR "-" to denote all
+ remaining space
+ <name> := (NAME)
+
+ Due to the way Linux handles the command line, no spaces are
+ allowed in the partition definition, including mtd id's and partition
+ names.
+
+ Examples:
+
+ 1 flash resource (mtd-id "sa1100"), with 1 single writable partition:
+ mtdparts=sa1100:-
+
+ Same flash, but 2 named partitions, the first one being read-only:
+ mtdparts=sa1100:256k(ARMboot)ro,-(root)
+
+ If unsure, say 'N'.
+
+config MTD_AFS_PARTS
+ tristate "ARM Firmware Suite partition parsing"
+ depends on (ARM || ARM64)
+ ---help---
+ The ARM Firmware Suite allows the user to divide flash devices into
+ multiple 'images'. Each such image has a header containing its name
+ and offset/size etc.
+
+ If you need code which can detect and parse these tables, and
+ register MTD 'partitions' corresponding to each image detected,
+ enable this option.
+
+ You will still need the parsing functions to be called by the driver
+ for your particular device. It won't happen automatically. The
+ 'physmap' map driver (CONFIG_MTD_PHYSMAP) does this, for example.
+
+config MTD_OF_PARTS
+ tristate "OpenFirmware partitioning information support"
+ default y
+ depends on OF
+ help
+ This provides a partition parsing function which derives
+ the partition map from the children of the flash node,
+ as described in Documentation/devicetree/bindings/mtd/partition.txt.
+
+config MTD_AR7_PARTS
+ tristate "TI AR7 partitioning support"
+ ---help---
+ TI AR7 partitioning support
+
+config MTD_BCM63XX_PARTS
+ tristate "BCM63XX CFE partitioning support"
+ depends on BCM63XX
+ select CRC32
+ help
+ This provides partions parsing for BCM63xx devices with CFE
+ bootloaders.
+
+config MTD_BCM47XX_PARTS
+ tristate "BCM47XX partitioning support"
+ depends on BCM47XX || ARCH_BCM_5301X
+ help
+ This provides partitions parser for devices based on BCM47xx
+ boards.

[Geert Uytterhoeven]

On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
<computer...@gmail.com> wrote:
> There have been several discussions [1] about adding a device tree binding for
> associating flash devices with the partition parser(s) that are used on the
> flash. There are a few reasons:
>
> (1) drivers shouldn't have to be encoding platform knowledge by listing what
> parsers might be used on a given system (this is the currently all that's
> supported)
> (2) we can't just scan for all supported parsers (like the block system does), since
> there is a wide diversity of "formats" (no standardization), and it is not
> always safe or efficient to attempt to do so, particularly since many of
> them allow their data structures to be placed anywhere on the flash, and
> so require scanning the entire flash device to find them.

I read the second reason, but would it be useful to (partially) merge
block/partitions/ and drivers/mtd/partitions/, so I can use e.g. msdos
partitions
on an mtd device??

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[Jonas Gorski]

Hi,

On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
<computer...@gmail.com> wrote:

> Hi,
>
> There have been several discussions [1] about adding a device tree binding for
> associating flash devices with the partition parser(s) that are used on the
> flash. There are a few reasons:
>
> (1) drivers shouldn't have to be encoding platform knowledge by listing what
> parsers might be used on a given system (this is the currently all that's
> supported)
> (2) we can't just scan for all supported parsers (like the block system does), since
> there is a wide diversity of "formats" (no standardization), and it is not
> always safe or efficient to attempt to do so, particularly since many of
> them allow their data structures to be placed anywhere on the flash, and
> so require scanning the entire flash device to find them.
>
> So instead, let's support a new binding so that a device tree can specify what
> partition formats might be used. This seems like a reasonable choice (even
> though it's not strictly a hardware description) because the flash layout /
> partitioning is often very closely tied with the bootloader/firmware, at
> production time.

On a first glance this looks good to me, and looks easily extensible
for application of non-complete partition parsers.

E.g. for the "brcm,bcm6345-imagetag" we would want to actually do something like

partitions {
....

partition@0 {
reg = <0x0 0x10000>;
label = "cfe";
read-only;
};

partition@10000 {
reg = <0x10000 0x3d0000>;
label = "firmware";
compatible = "brcm,bcm6345-imagetag";
};

partition@3e0000 {
reg = <0x3e0000 0x10000>;
label = "art";
read-only;
};

partition@3f0000 {
reg = <0x3f0000 0x10000>;
label = "nvram";
read-only;
};
};

as the image tag can only specify the offsets and sizes of the rootfs
and kernel parts, but not of any other parts.

>
> Also, as an example first-use of this mechanism, I support Google's FMAP flash
> structure, used on Chrome OS devices.
>
> Note that this is an RFC, mainly for the reason noted in patch 6 ("RFC: mtd:
> partitions: enable of_match_table matching"): the of_match_table support won't
> yet autoload a partition parser that is built as a module. I'm not quite sure
> if there's a lot of value in supporting MTD parsers as modules (block partition
> support can't be), but that is supported for "by-name" parser lookups in MTD
> already, so I don't feel like dropping that feature yet. Tips or thoughts are
> particularly welcome on this aspect!

I would assume a lot of the cases these would be a chicken-egg
problem, you need the parser to be able to find and mount the rootfs,
but you you need mount the rootfs to load the parser.

> Also note that there's an existing undocumented binding for a
> "linux,part-probe" property, but it is only usable on the physmap_of.c driver
> at the moment, and it is IMO not a good binding. I posted my thoughts on that
> previously here [2], and since no one else cared to make a better one...I did
> it myself.
>
> I'd love it if we could kill the unreviewed binding off in favor of something
> more like this...

I agree fully that this is a bad binding, as it exposes internal names
that aren't supposed to be fixed.


Jonas

[Michal Suchanek]

On 5 December 2015 at 11:15, Geert Uytterhoeven <ge...@linux-m68k.org> wrote:
> On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
> <computer...@gmail.com> wrote:
>> There have been several discussions [1] about adding a device tree binding for
>> associating flash devices with the partition parser(s) that are used on the
>> flash. There are a few reasons:
>>
>> (1) drivers shouldn't have to be encoding platform knowledge by listing what
>> parsers might be used on a given system (this is the currently all that's
>> supported)
>> (2) we can't just scan for all supported parsers (like the block system does), since
>> there is a wide diversity of "formats" (no standardization), and it is not
>> always safe or efficient to attempt to do so, particularly since many of
>> them allow their data structures to be placed anywhere on the flash, and
>> so require scanning the entire flash device to find them.
>
> I read the second reason, but would it be useful to (partially) merge
> block/partitions/ and drivers/mtd/partitions/, so I can use e.g. msdos
> partitions
> on an mtd device??
>

Using msdos partition on a MTD device does not sound terribly useful.
On what kind of non-block device would you expect to find one?

On the other hand, using FMAP on a block device might work an even
might have some uses.

Thanks

Michal

[Brian Norris]

On Sat, Dec 05, 2015 at 11:15:54AM +0100, Geert Uytterhoeven wrote:
> On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
> <computer...@gmail.com> wrote:
> > There have been several discussions [1] about adding a device tree binding for
> > associating flash devices with the partition parser(s) that are used on the
> > flash. There are a few reasons:
> >
> > (1) drivers shouldn't have to be encoding platform knowledge by listing what
> > parsers might be used on a given system (this is the currently all that's
> > supported)
> > (2) we can't just scan for all supported parsers (like the block system does), since
> > there is a wide diversity of "formats" (no standardization), and it is not
> > always safe or efficient to attempt to do so, particularly since many of
> > them allow their data structures to be placed anywhere on the flash, and
> > so require scanning the entire flash device to find them.
>
> I read the second reason, but would it be useful to (partially) merge
> block/partitions/ and drivers/mtd/partitions/, so I can use e.g. msdos
> partitions
> on an mtd device??

I kinda agree with Michal: is there a good use case?

Really, MTD partitioning is not a highly-scalable design. Particularly,
it's not typically that well-suited to large (read: unreliable) NAND
flash, where fixing partitions at the raw flash level mostly serves to
restrict UBI's ability to wear-level across the device. For that sort of
case, it's best if people are using UBI volumes on a (mostly?)
unpartitioned MTD, instead of using MTD partitions as the main
separation mechanism. Also, most partition designs (either MTD or block)
aren't very robust against bitflips, read disturb, etc.

IOW, I wouldn't expect MBR or GPT to work well on large raw NAND flash,
and so I don't plan to do that sort of work myself. If you can provide
some better argument for it, and some nice maintainable code to go with
it, then of course it could be considered :)

Regards,
Brian

[Brian Norris]

I had your (and others') prior attempts and suggestions in mind when
planning this, and I agree that the binding looks extendible to cases
like that. I haven't yet worked out what a good MTD infrastructure for
that would look like, so I stuck with defining and implementing only
what I know use :)

> > Also, as an example first-use of this mechanism, I support Google's FMAP flash
> > structure, used on Chrome OS devices.
> >
> > Note that this is an RFC, mainly for the reason noted in patch 6 ("RFC: mtd:
> > partitions: enable of_match_table matching"): the of_match_table support won't
> > yet autoload a partition parser that is built as a module. I'm not quite sure
> > if there's a lot of value in supporting MTD parsers as modules (block partition
> > support can't be), but that is supported for "by-name" parser lookups in MTD
> > already, so I don't feel like dropping that feature yet. Tips or thoughts are
> > particularly welcome on this aspect!
>
> I would assume a lot of the cases these would be a chicken-egg
> problem, you need the parser to be able to find and mount the rootfs,
> but you you need mount the rootfs to load the parser.

Not necessarily. One of my current use cases has a boot SPI NOR flash +
an eMMC rootfs. Modules can be loaded from eMMC.

BTW, I'm realizing that if partition parsers are forced to built-in
only, then we'd have to do the same for the MTD core (or at least, the
MTD core that handles partitioning). Not sure if that's a desirable
trade-off. (Again, block support is 'bool' in Kconfig, if we're trying
to compare.)

Brian

[Geert Uytterhoeven]

Hi Brian,

On Thu, Dec 10, 2015 at 9:54 PM, Brian Norris
<computer...@gmail.com> wrote:
> On Sat, Dec 05, 2015 at 11:15:54AM +0100, Geert Uytterhoeven wrote:
>> On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
>> <computer...@gmail.com> wrote:
>> > There have been several discussions [1] about adding a device tree binding for
>> > associating flash devices with the partition parser(s) that are used on the
>> > flash. There are a few reasons:
>> >
>> > (1) drivers shouldn't have to be encoding platform knowledge by listing what
>> > parsers might be used on a given system (this is the currently all that's
>> > supported)
>> > (2) we can't just scan for all supported parsers (like the block system does), since
>> > there is a wide diversity of "formats" (no standardization), and it is not
>> > always safe or efficient to attempt to do so, particularly since many of
>> > them allow their data structures to be placed anywhere on the flash, and
>> > so require scanning the entire flash device to find them.
>>
>> I read the second reason, but would it be useful to (partially) merge
>> block/partitions/ and drivers/mtd/partitions/, so I can use e.g. msdos
>> partitions
>> on an mtd device??
>
> I kinda agree with Michal: is there a good use case?

I don't have an immediate use case.
Just looking at it from a high-level viewpoint.

> Really, MTD partitioning is not a highly-scalable design. Particularly,
> it's not typically that well-suited to large (read: unreliable) NAND
> flash, where fixing partitions at the raw flash level mostly serves to
> restrict UBI's ability to wear-level across the device. For that sort of
> case, it's best if people are using UBI volumes on a (mostly?)
> unpartitioned MTD, instead of using MTD partitions as the main
> separation mechanism. Also, most partition designs (either MTD or block)
> aren't very robust against bitflips, read disturb, etc.
>
> IOW, I wouldn't expect MBR or GPT to work well on large raw NAND flash,
> and so I don't plan to do that sort of work myself. If you can provide
> some better argument for it, and some nice maintainable code to go with
> it, then of course it could be considered :)

There's also NOR FLASH (e.g. SPI-NOR), which is what most boards I'm
working on have.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[Michal Suchanek]

Yes, you can dump the content of a NOR flash to a file, attach a loop
device to it, and if block devices had the ability to use flash
partitioning access the different partitions.

Maybe it would be more useful to use some kind of mtdloop, though.
There might even be one already. I never needed it.

Thanks

Michal

[Geert Uytterhoeven]

Hi Michal,

That's the inverse, which looks like a solid use case to me ;-)
E.g. for investigation or virtualization.

You can do this already in userspace with kpartx, though.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[Michal Suchanek]

What kind of partitioning does kpartx support? I do not see that
documented anywhere.

Anyway, it seems there is no mtdblock so in case of non-ecc (or
hidden-ecc) flashes you could use losetup -P and block2mtd on each
partition to look at the dumped flash content or even prepare flash
images. So long as the kernel supports the partitioning scheme used on
the flash.

Thanks

Michal

[Brian Norris]

On Fri, Dec 11, 2015 at 09:44:37AM +0100, Geert Uytterhoeven wrote:
> On Thu, Dec 10, 2015 at 9:54 PM, Brian Norris
> <computer...@gmail.com> wrote:
> > IOW, I wouldn't expect MBR or GPT to work well on large raw NAND flash,
> > and so I don't plan to do that sort of work myself. If you can provide
> > some better argument for it, and some nice maintainable code to go with
> > it, then of course it could be considered :)
>
> There's also NOR FLASH (e.g. SPI-NOR), which is what most boards I'm
> working on have.

OK. But these flash are often used for the boot firmware, no? And then,
does the boot code have to be provided at one end of the flash (e.g.,
bottom)? If so, then something like MBR or GPT will likely not apply,
since they reserve the first (and sometimes last) blocks of the medium.

Brian

[Geert Uytterhoeven]

Hi Brian,

On Sat, Dec 12, 2015 at 2:33 AM, Brian Norris
<computer...@gmail.com> wrote:
> On Fri, Dec 11, 2015 at 09:44:37AM +0100, Geert Uytterhoeven wrote:
>> On Thu, Dec 10, 2015 at 9:54 PM, Brian Norris
>> <computer...@gmail.com> wrote:
>> > IOW, I wouldn't expect MBR or GPT to work well on large raw NAND flash,
>> > and so I don't plan to do that sort of work myself. If you can provide
>> > some better argument for it, and some nice maintainable code to go with
>> > it, then of course it could be considered :)
>>
>> There's also NOR FLASH (e.g. SPI-NOR), which is what most boards I'm
>> working on have.
>
> OK. But these flash are often used for the boot firmware, no? And then,
> does the boot code have to be provided at one end of the flash (e.g.,
> bottom)? If so, then something like MBR or GPT will likely not apply,
> since they reserve the first (and sometimes last) blocks of the medium.

If the boot firmware is in the first few blocks, Amiga RDB or BSD disklabel
come to the rescue...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds