LinuxLists.cc - [PATCH v5 0/9] mtd: sharpslpart partition parser

[permalink] [raw]

Subject: [PATCH v5 2/9] mtd: nand: sharpsl: Add partition parsers platform data

2017-08-14 20:48:57

[permalink] [raw]

Subject: [PATCH v5 3/9] mfd: tmio: Add partition parsers platform data

2017-08-14 20:49:07

[permalink] [raw]

Subject: [PATCH v5 8/9] ARM: pxa/spitz: Remove hardcoded partitioning, use sharpslpart parser

With the introduction of sharpslpart partition parser we can now read the
offsets from NAND: we specify the list of the parsers as platform data, with
cmdlinepart and ofpart parsers first allowing to override the part. table
written in NAND. This is done here in the board file.

Signed-off-by: Andrea Adami <[email protected]>
---
arch/arm/mach-pxa/spitz.c | 34 +++++++++-------------------------
1 file changed, 9 insertions(+), 25 deletions(-)

diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c
index 67d66c7..defefa3 100644
--- a/arch/arm/mach-pxa/spitz.c
+++ b/arch/arm/mach-pxa/spitz.c
@@ -739,21 +739,6 @@ static inline void spitz_lcd_init(void) {}
* NAND Flash
******************************************************************************/
#if defined(CONFIG_MTD_NAND_SHARPSL) || defined(CONFIG_MTD_NAND_SHARPSL_MODULE)
-static struct mtd_partition spitz_nand_partitions[] = {
- {
- .name = "System Area",
- .offset = 0,
- .size = 7 * 1024 * 1024,
- }, {
- .name = "Root Filesystem",
- .offset = 7 * 1024 * 1024,
- }, {
- .name = "Home Filesystem",
- .offset = MTDPART_OFS_APPEND,
- .size = MTDPART_SIZ_FULL,
- },
-};
-
static uint8_t scan_ff_pattern[] = { 0xff, 0xff };

static struct nand_bbt_descr spitz_nand_bbt = {
@@ -808,10 +793,16 @@ static const struct mtd_ooblayout_ops akita_ooblayout_ops = {
.free = akita_ooblayout_free,
};

+static const char * const probes[] = {
+ "cmdlinepart",
+ "ofpart",
+ "sharpslpart",
+ NULL,
+};
+
static struct sharpsl_nand_platform_data spitz_nand_pdata = {
.badblock_pattern = &spitz_nand_bbt,
- .partitions = spitz_nand_partitions,
- .nr_partitions = ARRAY_SIZE(spitz_nand_partitions),
+ .part_parsers = probes,
};

static struct resource spitz_nand_resources[] = {
@@ -834,14 +825,7 @@ static struct platform_device spitz_nand_device = {

static void __init spitz_nand_init(void)
{
- if (machine_is_spitz()) {
- spitz_nand_partitions[1].size = 5 * 1024 * 1024;
- } else if (machine_is_akita()) {
- spitz_nand_partitions[1].size = 58 * 1024 * 1024;
- spitz_nand_bbt.len = 1;
- spitz_nand_pdata.ecc_layout = &akita_ooblayout_ops;
- } else if (machine_is_borzoi()) {
- spitz_nand_partitions[1].size = 32 * 1024 * 1024;
+ if (machine_is_akita() || machine_is_borzoi()) {
spitz_nand_bbt.len = 1;
spitz_nand_pdata.ecc_layout = &akita_ooblayout_ops;
}
--
2.7.4

2017-08-14 20:49:05

[permalink] [raw]

Subject: [PATCH v5 9/9] ARM: pxa/poodle: Remove hardcoded partitioning, use sharpslpart parser

With the introduction of sharpslpart partition parser we can now read the
offsets from NAND: we specify the list of the parsers as platform data, with
cmdlinepart and ofpart parsers first allowing to override the part. table
written in NAND. This is done here in the board file.

Signed-off-by: Andrea Adami <[email protected]>
---
arch/arm/mach-pxa/poodle.c | 28 ++++++++--------------------
1 file changed, 8 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-pxa/poodle.c b/arch/arm/mach-pxa/poodle.c
index 62a1191..fd01d6b 100644
--- a/arch/arm/mach-pxa/poodle.c
+++ b/arch/arm/mach-pxa/poodle.c
@@ -333,24 +333,6 @@ static struct pxafb_mach_info poodle_fb_info = {
.lcd_conn = LCD_COLOR_TFT_16BPP,
};

-static struct mtd_partition sharpsl_nand_partitions[] = {
- {
- .name = "System Area",
- .offset = 0,
- .size = 7 * 1024 * 1024,
- },
- {
- .name = "Root Filesystem",
- .offset = 7 * 1024 * 1024,
- .size = 22 * 1024 * 1024,
- },
- {
- .name = "Home Filesystem",
- .offset = MTDPART_OFS_APPEND,
- .size = MTDPART_SIZ_FULL,
- },
-};
-
static uint8_t scan_ff_pattern[] = { 0xff, 0xff };

static struct nand_bbt_descr sharpsl_bbt = {
@@ -360,10 +342,16 @@ static struct nand_bbt_descr sharpsl_bbt = {
.pattern = scan_ff_pattern
};

+static const char * const probes[] = {
+ "cmdlinepart",
+ "ofpart",
+ "sharpslpart",
+ NULL,
+};
+
static struct sharpsl_nand_platform_data sharpsl_nand_platform_data = {
.badblock_pattern = &sharpsl_bbt,
- .partitions = sharpsl_nand_partitions,
- .nr_partitions = ARRAY_SIZE(sharpsl_nand_partitions),
+ .part_parsers = probes,
};

static struct resource sharpsl_nand_resources[] = {
--
2.7.4

2017-08-14 20:49:39

[permalink] [raw]

Subject: [PATCH v5 7/9] ARM: pxa/tosa: Remove hardcoded partitioning, use sharpslpart parser

2017-08-14 20:49:56

[permalink] [raw]

Subject: [PATCH v5 6/9] ARM: pxa/corgi: Remove hardcoded partitioning, use sharpslpart parser

With the introduction of sharpslpart partition parser we can now read the
offsets from NAND: we specify the list of the parsers as platform data, with
cmdlinepart and ofpart parsers first allowing to override the part. table
written in NAND. This is done here in the board file.

Signed-off-by: Andrea Adami <[email protected]>
---
arch/arm/mach-pxa/corgi.c | 31 ++++++++-----------------------
1 file changed, 8 insertions(+), 23 deletions(-)

diff --git a/arch/arm/mach-pxa/corgi.c b/arch/arm/mach-pxa/corgi.c
index 7270f0d..9546452 100644
--- a/arch/arm/mach-pxa/corgi.c
+++ b/arch/arm/mach-pxa/corgi.c
@@ -606,24 +606,6 @@ static void __init corgi_init_spi(void)
static inline void corgi_init_spi(void) {}
#endif

-static struct mtd_partition sharpsl_nand_partitions[] = {
- {
- .name = "System Area",
- .offset = 0,
- .size = 7 * 1024 * 1024,
- },
- {
- .name = "Root Filesystem",
- .offset = 7 * 1024 * 1024,
- .size = 25 * 1024 * 1024,
- },
- {
- .name = "Home Filesystem",
- .offset = MTDPART_OFS_APPEND,
- .size = MTDPART_SIZ_FULL,
- },
-};
-
static uint8_t scan_ff_pattern[] = { 0xff, 0xff };

static struct nand_bbt_descr sharpsl_bbt = {
@@ -633,10 +615,16 @@ static struct nand_bbt_descr sharpsl_bbt = {
.pattern = scan_ff_pattern
};

+static const char * const probes[] = {
+ "cmdlinepart",
+ "ofpart",
+ "sharpslpart",
+ NULL,
+};
+
static struct sharpsl_nand_platform_data sharpsl_nand_platform_data = {
.badblock_pattern = &sharpsl_bbt,
- .partitions = sharpsl_nand_partitions,
- .nr_partitions = ARRAY_SIZE(sharpsl_nand_partitions),
+ .part_parsers = probes,
};

static struct resource sharpsl_nand_resources[] = {
@@ -750,9 +738,6 @@ static void __init corgi_init(void)

platform_scoop_config = &corgi_pcmcia_config;

- if (machine_is_husky())
- sharpsl_nand_partitions[1].size = 53 * 1024 * 1024;
-
platform_add_devices(devices, ARRAY_SIZE(devices));

regulator_has_full_constraints();
--
2.7.4

2017-08-14 20:50:18

[permalink] [raw]

Subject: [PATCH v5 5/9] mtd: nand: tmio: Register partitions using the parsers

2017-08-14 20:48:53

[permalink] [raw]

Subject: [PATCH v5 1/9] mtd: sharpslpart: Add sharpslpart partition parser

The Sharp SL Series (Zaurus) PXA handhelds have 16/64/128M of NAND flash
and share the same layout of the first 7M partition, managed by Sharp FTL.

The purpose of this self-contained patch is to add a common parser and
remove the hardcoded sizes in the board files (these devices are not yet
converted to devicetree).
Users will have benefits because the mtdparts= tag will not be necessary
anymore and they will be free to repartition the little sized flash.

The obsolete bootloader can not pass the partitioning info to modern
kernels anymore so it has to be read from flash at known logical addresses.
(see http://www.h5.dion.ne.jp/~rimemoon/zaurus/memo_006.htm )

In kernel, under arch/arm/mach-pxa we have already 8 machines:
MACH_POODLE, MACH_CORGI, MACH_SHEPERD, MACH_HUSKY, MACH_AKITA, MACH_SPITZ,
MACH_BORZOI, MACH_TOSA.
Lost after the 2.4 vendor kernel are MACH_BOXER and MACH_TERRIER.

Almost every model has different factory partitioning: add to this the
units can be repartitioned by users with userspace tools (nandlogical)
and installers for popular (back then) linux distributions.

The Parameter Area in the first (boot) partition extends from 0x00040000 to
0x0007bfff (176k) and contains two copies of the partition table:
...
0x00060000: Partition Info1 16k
0x00064000: Partition Info2 16k
0x00668000: Model 16k
...

The first 7M partition is managed by the Sharp FTL reserving 5% + 1 blocks
for wear-leveling: some blocks are remapped and one layer of translation
(logical to physical) is necessary.

There isn't much documentation about this FTL in the 2.4 sources, just the
MTD methods for reading and writing using logical addresses and the block
management (wear-leveling, use counter).
For the purpose of the MTD parser only the read part of the code was taken.

The NAND drivers that can use this parser are sharpsl.c and tmio_nand.c.

Signed-off-by: Andrea Adami <[email protected]>
---
drivers/mtd/parsers/Kconfig | 8 +
drivers/mtd/parsers/Makefile | 1 +
drivers/mtd/parsers/sharpslpart.c | 376 ++++++++++++++++++++++++++++++++++++++
3 files changed, 385 insertions(+)
create mode 100644 drivers/mtd/parsers/sharpslpart.c

diff --git a/drivers/mtd/parsers/Kconfig b/drivers/mtd/parsers/Kconfig
index d206b3c..ee5ab99 100644
--- a/drivers/mtd/parsers/Kconfig
+++ b/drivers/mtd/parsers/Kconfig
@@ -6,3 +6,11 @@ config MTD_PARSER_TRX
may contain up to 3/4 partitions (depending on the version).
This driver will parse TRX header and report at least two partitions:
kernel and rootfs.
+
+config MTD_SHARPSL_PARTS
+ tristate "Sharp SL Series NAND flash partition parser"
+ depends on MTD_NAND_SHARPSL || MTD_NAND_TMIO || COMPILE_TEST
+ help
+ This provides the read-only FTL logic necessary to read the partition
+ table from the NAND flash of Sharp SL Series (Zaurus) and the MTD
+ partition parser using this code.
diff --git a/drivers/mtd/parsers/Makefile b/drivers/mtd/parsers/Makefile
index 4d9024e..5b1bcc3 100644
--- a/drivers/mtd/parsers/Makefile
+++ b/drivers/mtd/parsers/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_MTD_PARSER_TRX) += parser_trx.o
+obj-$(CONFIG_MTD_SHARPSL_PARTS) += sharpslpart.o
diff --git a/drivers/mtd/parsers/sharpslpart.c b/drivers/mtd/parsers/sharpslpart.c
new file mode 100644
index 0000000..2511059
--- /dev/null
+++ b/drivers/mtd/parsers/sharpslpart.c
@@ -0,0 +1,376 @@
+/*
+ * sharpslpart.c - MTD partition parser for NAND flash using the SHARP FTL
+ * for logical addressing, as used on the PXA models of the SHARP SL Series.
+ *
+ * Copyright (C) 2017 Andrea Adami <[email protected]>
+ *
+ * Based on 2.4 sources:
+ * drivers/mtd/nand/sharp_sl_logical.c
+ * linux/include/asm-arm/sharp_nand_logical.h
+ *
+ * Copyright (C) 2002 SHARP
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/partitions.h>
+
+/* oob structure */
+#define NAND_NOOB_LOGADDR_00 8
+#define NAND_NOOB_LOGADDR_01 9
+#define NAND_NOOB_LOGADDR_10 10
+#define NAND_NOOB_LOGADDR_11 11
+#define NAND_NOOB_LOGADDR_20 12
+#define NAND_NOOB_LOGADDR_21 13
+
+#define BLOCK_IS_RESERVED 0xffff
+#define BLOCK_UNMASK 0x07fe
+#define BLOCK_UNMASK_COMPLEMENT 1
+
+/* factory defaults */
+#define SHARPSL_NAND_PARTS 3
+#define SHARPSL_FTL_PARTITION_SIZE (7 * 1024 * 1024)
+#define PARAM_BLOCK_PARTITIONINFO1 0x00060000
+#define PARAM_BLOCK_PARTITIONINFO2 0x00064000
+
+#define BOOT_MAGIC 0x424f4f54 /* BOOT */
+#define FSRO_MAGIC 0x4653524f /* FSRO */
+#define FSRW_MAGIC 0x46535257 /* FSRW */
+
+/* Logical Table */
+struct mtd_logical {
+ u32 size; /* size of the handled partition */
+ int index; /* mtd->index */
+ u_int phymax; /* physical blocks */
+ u_int logmax; /* logical blocks */
+ u_int *log2phy; /* the logical-to-physical table */
+};
+
+/*
+ * SHARP SL FTL ancillary functions
+ *
+ */
+
+static int sharpsl_nand_read_oob(struct mtd_info *mtd, loff_t offs, size_t len,
+ uint8_t *buf)
+{
+ loff_t mask = mtd->writesize - 1;
+ struct mtd_oob_ops ops;
+ int ret;
+
+ ops.mode = MTD_OPS_PLACE_OOB;
+ ops.ooboffs = offs & mask;
+ ops.ooblen = len;
+ ops.oobbuf = buf;
+ ops.datbuf = NULL;
+
+ ret = mtd_read_oob(mtd, offs & ~mask, &ops);
+ if (ret != 0 || len != ops.oobretlen)
+ return -1;
+
+ return 0;
+}
+
+/*
+ * The logical block number assigned to a physical block is stored in the OOB
+ * of the first page, in 3 16-bit copies with the following layout:
+ *
+ * 01234567 89abcdef
+ * -------- --------
+ * ECC BB xyxyxy
+ *
+ * When reading we check that the first two copies agree.
+ * In case of error, matching is tried using the following pairs.
+ * Reserved values 0xffff mean the block is kept for wear leveling.
+ *
+ * 01234567 89abcdef
+ * -------- --------
+ * ECC BB xyxy oob[8]==oob[10] && oob[9]==oob[11] -> byte0=8 byte1=9
+ * ECC BB xyxy oob[10]==oob[12] && oob[11]==oob[13] -> byte0=10 byte1=11
+ * ECC BB xy xy oob[12]==oob[8] && oob[13]==oob[9] -> byte0=12 byte1=13
+ *
+ */
+
+static u_int sharpsl_nand_get_logical_num(u_char *oob)
+{
+ u16 us;
+ int good0, good1;
+
+ if (oob[NAND_NOOB_LOGADDR_00] == oob[NAND_NOOB_LOGADDR_10] &&
+ oob[NAND_NOOB_LOGADDR_01] == oob[NAND_NOOB_LOGADDR_11]) {
+ good0 = NAND_NOOB_LOGADDR_00;
+ good1 = NAND_NOOB_LOGADDR_01;
+ } else if (oob[NAND_NOOB_LOGADDR_10] == oob[NAND_NOOB_LOGADDR_20] &&
+ oob[NAND_NOOB_LOGADDR_11] == oob[NAND_NOOB_LOGADDR_21]) {
+ good0 = NAND_NOOB_LOGADDR_10;
+ good1 = NAND_NOOB_LOGADDR_11;
+ } else if (oob[NAND_NOOB_LOGADDR_20] == oob[NAND_NOOB_LOGADDR_00] &&
+ oob[NAND_NOOB_LOGADDR_21] == oob[NAND_NOOB_LOGADDR_01]) {
+ good0 = NAND_NOOB_LOGADDR_20;
+ good1 = NAND_NOOB_LOGADDR_21;
+ } else {
+ /* wrong oob fingerprint, maybe here by mistake? */
+ return UINT_MAX;
+ }
+
+ us = oob[good0] | oob[good1] << 8;
+
+ /* parity check */
+ if (hweight16(us) & BLOCK_UNMASK_COMPLEMENT)
+ return (UINT_MAX - 1);
+
+ /* reserved */
+ if (us == BLOCK_IS_RESERVED)
+ return BLOCK_IS_RESERVED;
+ else
+ return (us & BLOCK_UNMASK) >> 1;
+}
+
+static int sharpsl_nand_init_logical(struct mtd_info *mtd, u32 partition_size,
+ struct mtd_logical **sharpsl_mtd_logical)
+{
+ struct mtd_logical *logical;
+ u_int block_num, log_num;
+ loff_t block_adr;
+ u_char *oob;
+ int i, ret;
+
+ logical = kzalloc(sizeof(*logical), GFP_KERNEL);
+ if (!logical)
+ return -ENOMEM;
+
+ oob = kzalloc(mtd->oobsize, GFP_KERNEL);
+ if (!oob) {
+ kfree(logical);
+ return -ENOMEM;
+ }
+
+ /* initialize management structure */
+ logical->size = partition_size;
+ logical->index = mtd->index;
+ logical->phymax = (partition_size / mtd->erasesize);
+
+ /* FTL reserves 5% of the blocks + 1 spare */
+ logical->logmax = ((logical->phymax * 95) / 100) - 1;
+
+ logical->log2phy = kmalloc_array(logical->logmax, sizeof(u_int),
+ GFP_KERNEL);
+ if (!logical->log2phy) {
+ kfree(logical);
+ kfree(oob);
+ return -ENOMEM;
+ }
+
+ /* initialize logical->log2phy */
+ for (i = 0; i < logical->logmax; i++)
+ logical->log2phy[i] = UINT_MAX;
+
+ /* create physical-logical table */
+ for (block_num = 0; block_num < logical->phymax; block_num++) {
+ block_adr = block_num * mtd->erasesize;
+
+ if (mtd_block_isbad(mtd, block_adr))
+ continue;
+
+ if (sharpsl_nand_read_oob(mtd, block_adr, mtd->oobsize, oob))
+ continue;
+
+ /* get logical block */
+ log_num = sharpsl_nand_get_logical_num(oob);
+
+ /* FTL is not used? Exit here if the oob fingerprint is wrong */
+ if (log_num == UINT_MAX) {
+ pr_info("sharpslpart: Sharp SL FTL not found. Quit parser.\n");
+ ret = -EINVAL;
+ goto exit;
+ }
+
+ /* skip out of range and not unique values */
+ if (log_num < logical->logmax) {
+ if (logical->log2phy[log_num] == UINT_MAX)
+ logical->log2phy[log_num] = block_num;
+ }
+ }
+ pr_info("Sharp SL FTL: %d blocks used (%d logical, %d reserved)\n",
+ logical->phymax, logical->logmax,
+ logical->phymax - logical->logmax);
+
+ *sharpsl_mtd_logical = logical;
+ ret = 0;
+exit:
+ kfree(logical->log2phy);
+ kfree(logical);
+ kfree(oob);
+ return ret;
+}
+
+static int sharpsl_nand_read_laddr(struct mtd_info *mtd,
+ loff_t from,
+ size_t len,
+ u_char *buf,
+ struct mtd_logical *sharpsl_mtd_logical)
+{
+ u_int log_num, log_new;
+ u_int block_num;
+ loff_t block_adr;
+ loff_t block_ofs;
+ size_t retlen;
+ int err;
+
+ log_num = (u32)from / mtd->erasesize;
+ log_new = ((u32)from + len - 1) / mtd->erasesize;
+
+ if (len <= 0 || log_num >= sharpsl_mtd_logical->logmax ||
+ log_new > log_num)
+ return -EINVAL;
+
+ block_num = sharpsl_mtd_logical->log2phy[log_num];
+ block_adr = block_num * mtd->erasesize;
+ block_ofs = (u32)from % mtd->erasesize;
+
+ err = mtd_read(mtd, block_adr + block_ofs, len, &retlen, buf);
+ /* Ignore corrected ECC errors */
+ if (mtd_is_bitflip(err))
+ err = 0;
+ if (!err && retlen != len)
+ err = -EIO;
+ if (err)
+ pr_err("sharpslpart: error, read failed at %#llx\n",
+ block_adr + block_ofs);
+
+ return err;
+}
+
+/*
+ * MTD Partition Parser
+ *
+ */
+
+struct sharpsl_nand_partitioninfo {
+ __le32 start;
+ __le32 end;
+ __be32 magic;
+ u32 reserved;
+};
+
+/*
+ * Sample values read from SL-C860
+ *
+ * # cat /proc/mtd
+ * dev: size erasesize name
+ * mtd0: 006d0000 00020000 "Filesystem"
+ * mtd1: 00700000 00004000 "smf"
+ * mtd2: 03500000 00004000 "root"
+ * mtd3: 04400000 00004000 "home"
+ *
+ * PARTITIONINFO1
+ * 0x00060000: 00 00 00 00 00 00 70 00 42 4f 4f 54 00 00 00 00 ......p.BOOT....
+ * 0x00060010: 00 00 70 00 00 00 c0 03 46 53 52 4f 00 00 00 00 ..p.....FSRO....
+ * 0x00060020: 00 00 c0 03 00 00 00 04 46 53 52 57 00 00 00 00 ........FSRW....
+ * 0x00060030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
+ *
+ */
+
+static int sharpsl_parse_mtd_partitions(struct mtd_info *master,
+ const struct mtd_partition **pparts,
+ struct mtd_part_parser_data *data)
+{
+ struct mtd_logical *sharpsl_mtd_logical;
+ struct sharpsl_nand_partitioninfo buf1[SHARPSL_NAND_PARTS];
+ struct sharpsl_nand_partitioninfo buf2[SHARPSL_NAND_PARTS];
+ struct mtd_partition *sharpsl_nand_parts;
+ int err;
+
+ /* init logical mgmt (FTL) */
+ err = sharpsl_nand_init_logical(master, SHARPSL_FTL_PARTITION_SIZE,
+ &sharpsl_mtd_logical);
+ if (err)
+ return err;
+
+ /* read the two partition tables */
+ err = sharpsl_nand_read_laddr(master,
+ PARAM_BLOCK_PARTITIONINFO1,
+ sizeof(buf1), (u_char *)&buf1,
+ sharpsl_mtd_logical) ||
+ sharpsl_nand_read_laddr(master,
+ PARAM_BLOCK_PARTITIONINFO2,
+ sizeof(buf2), (u_char *)&buf2,
+ sharpsl_mtd_logical);
+ if (err)
+ return err;
+
+ /* compare the two buffers */
+ if (memcmp(&buf1, &buf2, sizeof(buf1))) {
+ pr_err("sharpslpart: PARTITIONINFO 1,2 differ. Quit parser.\n");
+ return -EINVAL;
+ }
+
+ /* check for magics (just in the first) */
+ if (be32_to_cpu(buf1[0].magic) != BOOT_MAGIC ||
+ be32_to_cpu(buf1[1].magic) != FSRO_MAGIC ||
+ be32_to_cpu(buf1[2].magic) != FSRW_MAGIC) {
+ pr_err("sharpslpart: magic values mismatch. Quit parser.\n");
+ return -EINVAL;
+ }
+
+ /* fixup for hardcoded value 64 MiB (for older models) */
+ buf1[2].end = cpu_to_le32(master->size);
+
+ /* extra sanity check */
+ if (le32_to_cpu(buf1[0].end) <= le32_to_cpu(buf1[0].start) ||
+ le32_to_cpu(buf1[1].start) < le32_to_cpu(buf1[0].end) ||
+ le32_to_cpu(buf1[1].end) <= le32_to_cpu(buf1[1].start) ||
+ le32_to_cpu(buf1[2].start) < le32_to_cpu(buf1[1].end) ||
+ le32_to_cpu(buf1[2].end) <= le32_to_cpu(buf1[2].start)) {
+ pr_err("sharpslpart: partition sizes mismatch. Quit parser.\n");
+ return -EINVAL;
+ }
+
+ sharpsl_nand_parts = kzalloc(sizeof(*sharpsl_nand_parts) *
+ SHARPSL_NAND_PARTS, GFP_KERNEL);
+ if (!sharpsl_nand_parts)
+ return -ENOMEM;
+
+ /* original names */
+ sharpsl_nand_parts[0].name = "smf";
+ sharpsl_nand_parts[0].offset = le32_to_cpu(buf1[0].start);
+ sharpsl_nand_parts[0].size = le32_to_cpu(buf1[0].end) -
+ le32_to_cpu(buf1[0].start);
+
+ sharpsl_nand_parts[1].name = "root";
+ sharpsl_nand_parts[1].offset = le32_to_cpu(buf1[1].start);
+ sharpsl_nand_parts[1].size = le32_to_cpu(buf1[1].end) -
+ le32_to_cpu(buf1[1].start);
+
+ sharpsl_nand_parts[2].name = "home";
+ sharpsl_nand_parts[2].offset = le32_to_cpu(buf1[2].start);
+ sharpsl_nand_parts[2].size = le32_to_cpu(buf1[2].end) -
+ le32_to_cpu(buf1[2].start);
+
+ *pparts = sharpsl_nand_parts;
+ return SHARPSL_NAND_PARTS;
+}
+
+static struct mtd_part_parser sharpsl_mtd_parser = {
+ .parse_fn = sharpsl_parse_mtd_partitions,
+ .name = "sharpslpart",
+};
+module_mtd_part_parser(sharpsl_mtd_parser);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Andrea Adami <[email protected]>");
+MODULE_DESCRIPTION("MTD partitioning for NAND flash on Sharp SL Series");
--
2.7.4

2017-08-14 20:50:44

[permalink] [raw]

Subject: [PATCH v5 4/9] mtd: nand: sharpsl: Register partitions using the parsers

2017-08-15 06:58:41

by Lee Jones

[permalink] [raw]

Subject: Re: [PATCH v5 3/9] mfd: tmio: Add partition parsers platform data

On Mon, 14 Aug 2017, Andrea Adami wrote:

> With the introduction of sharpslpart partition parser we can now read the
> offsets from NAND: we specify the list of the parsers as platform data, with
> cmdlinepart and ofpart parsers first allowing to override the part. table
> written in NAND. This is done in the board files using this driver.
>
> Thus, we need to extend tmio_nand_data to consider the partition parsers.
>
> Signed-off-by: Andrea Adami <[email protected]>
> ---
> include/linux/mfd/tmio.h | 1 +
> 1 file changed, 1 insertion(+)

Acked-by: Lee Jones <[email protected]>

--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

2017-08-17 08:10:49

[permalink] [raw]

Subject: Re: [PATCH v5 1/9] mtd: sharpslpart: Add sharpslpart partition parser

Le Mon, 14 Aug 2017 22:48:32 +0200,
Andrea Adami <[email protected]> a écrit :

> The Sharp SL Series (Zaurus) PXA handhelds have 16/64/128M of NAND flash
> and share the same layout of the first 7M partition, managed by Sharp FTL.
>
> The purpose of this self-contained patch is to add a common parser and
> remove the hardcoded sizes in the board files (these devices are not yet
> converted to devicetree).
> Users will have benefits because the mtdparts= tag will not be necessary
> anymore and they will be free to repartition the little sized flash.
>
> The obsolete bootloader can not pass the partitioning info to modern
> kernels anymore so it has to be read from flash at known logical addresses.
> (see http://www.h5.dion.ne.jp/~rimemoon/zaurus/memo_006.htm )
>
> In kernel, under arch/arm/mach-pxa we have already 8 machines:
> MACH_POODLE, MACH_CORGI, MACH_SHEPERD, MACH_HUSKY, MACH_AKITA, MACH_SPITZ,
> MACH_BORZOI, MACH_TOSA.
> Lost after the 2.4 vendor kernel are MACH_BOXER and MACH_TERRIER.
>
> Almost every model has different factory partitioning: add to this the
> units can be repartitioned by users with userspace tools (nandlogical)
> and installers for popular (back then) linux distributions.
>
> The Parameter Area in the first (boot) partition extends from 0x00040000 to
> 0x0007bfff (176k) and contains two copies of the partition table:
> ...
> 0x00060000: Partition Info1 16k
> 0x00064000: Partition Info2 16k
> 0x00668000: Model 16k
> ...
>
> The first 7M partition is managed by the Sharp FTL reserving 5% + 1 blocks
> for wear-leveling: some blocks are remapped and one layer of translation
> (logical to physical) is necessary.
>
> There isn't much documentation about this FTL in the 2.4 sources, just the
> MTD methods for reading and writing using logical addresses and the block
> management (wear-leveling, use counter).
> For the purpose of the MTD parser only the read part of the code was taken.
>
> The NAND drivers that can use this parser are sharpsl.c and tmio_nand.c.
>
> Signed-off-by: Andrea Adami <[email protected]>
> ---
> drivers/mtd/parsers/Kconfig | 8 +
> drivers/mtd/parsers/Makefile | 1 +
> drivers/mtd/parsers/sharpslpart.c | 376 ++++++++++++++++++++++++++++++++++++++
> 3 files changed, 385 insertions(+)
> create mode 100644 drivers/mtd/parsers/sharpslpart.c
>
> diff --git a/drivers/mtd/parsers/Kconfig b/drivers/mtd/parsers/Kconfig
> index d206b3c..ee5ab99 100644
> --- a/drivers/mtd/parsers/Kconfig
> +++ b/drivers/mtd/parsers/Kconfig
> @@ -6,3 +6,11 @@ config MTD_PARSER_TRX
> may contain up to 3/4 partitions (depending on the version).
> This driver will parse TRX header and report at least two partitions:
> kernel and rootfs.
> +
> +config MTD_SHARPSL_PARTS
> + tristate "Sharp SL Series NAND flash partition parser"
> + depends on MTD_NAND_SHARPSL || MTD_NAND_TMIO || COMPILE_TEST
> + help
> + This provides the read-only FTL logic necessary to read the partition
> + table from the NAND flash of Sharp SL Series (Zaurus) and the MTD
> + partition parser using this code.
> diff --git a/drivers/mtd/parsers/Makefile b/drivers/mtd/parsers/Makefile
> index 4d9024e..5b1bcc3 100644
> --- a/drivers/mtd/parsers/Makefile
> +++ b/drivers/mtd/parsers/Makefile
> @@ -1 +1,2 @@
> obj-$(CONFIG_MTD_PARSER_TRX) += parser_trx.o
> +obj-$(CONFIG_MTD_SHARPSL_PARTS) += sharpslpart.o
> diff --git a/drivers/mtd/parsers/sharpslpart.c b/drivers/mtd/parsers/sharpslpart.c
> new file mode 100644
> index 0000000..2511059
> --- /dev/null
> +++ b/drivers/mtd/parsers/sharpslpart.c
> @@ -0,0 +1,376 @@
> +/*
> + * sharpslpart.c - MTD partition parser for NAND flash using the SHARP FTL
> + * for logical addressing, as used on the PXA models of the SHARP SL Series.
> + *
> + * Copyright (C) 2017 Andrea Adami <[email protected]>
> + *
> + * Based on 2.4 sources:
> + * drivers/mtd/nand/sharp_sl_logical.c
> + * linux/include/asm-arm/sharp_nand_logical.h
> + *
> + * Copyright (C) 2002 SHARP
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/slab.h>
> +#include <linux/module.h>
> +#include <linux/types.h>
> +#include <linux/mtd/mtd.h>
> +#include <linux/mtd/partitions.h>
> +
> +/* oob structure */
> +#define NAND_NOOB_LOGADDR_00 8
> +#define NAND_NOOB_LOGADDR_01 9
> +#define NAND_NOOB_LOGADDR_10 10
> +#define NAND_NOOB_LOGADDR_11 11
> +#define NAND_NOOB_LOGADDR_20 12
> +#define NAND_NOOB_LOGADDR_21 13
> +
> +#define BLOCK_IS_RESERVED 0xffff
> +#define BLOCK_UNMASK 0x07fe
> +#define BLOCK_UNMASK_COMPLEMENT 1
> +
> +/* factory defaults */
> +#define SHARPSL_NAND_PARTS 3
> +#define SHARPSL_FTL_PARTITION_SIZE (7 * 1024 * 1024)
> +#define PARAM_BLOCK_PARTITIONINFO1 0x00060000
> +#define PARAM_BLOCK_PARTITIONINFO2 0x00064000
> +
> +#define BOOT_MAGIC 0x424f4f54 /* BOOT */
> +#define FSRO_MAGIC 0x4653524f /* FSRO */
> +#define FSRW_MAGIC 0x46535257 /* FSRW */
> +
> +/* Logical Table */

Please use kerneldoc headers instead of putting doc in the struct def:

/**
* struct mtd_logical - SharpFTL Logical Table
* @size: size of the handled partition
* @index: mtd->index
* ...
*
* <Short description here>
*/
> +struct mtd_logical {
> + u32 size; /* size of the handled partition */
> + int index; /* mtd->index */

index and size are not used in the code, you can drop them.

> + u_int phymax; /* physical blocks */

I'm pretty sure you don't need phymax in this struct. Just declare a
local phymax variable in sharpsl_nand_init_logical().

> + u_int logmax; /* logical blocks */
> + u_int *log2phy; /* the logical-to-physical table */
> +};
> +
> +/*
> + * SHARP SL FTL ancillary functions
> + *
> + */
> +

Unneeded blank line here (that's not the only place in the code).

> +static int sharpsl_nand_read_oob(struct mtd_info *mtd, loff_t offs, size_t len,
> + uint8_t *buf)
> +{
> + loff_t mask = mtd->writesize - 1;
> + struct mtd_oob_ops ops;
> + int ret;
> +
> + ops.mode = MTD_OPS_PLACE_OOB;
> + ops.ooboffs = offs & mask;
> + ops.ooblen = len;
> + ops.oobbuf = buf;
> + ops.datbuf = NULL;
> +
> + ret = mtd_read_oob(mtd, offs & ~mask, &ops);
> + if (ret != 0 || len != ops.oobretlen)
> + return -1;
> +
> + return 0;
> +}
> +
> +/*
> + * The logical block number assigned to a physical block is stored in the OOB
> + * of the first page, in 3 16-bit copies with the following layout:
> + *
> + * 01234567 89abcdef
> + * -------- --------
> + * ECC BB xyxyxy
> + *
> + * When reading we check that the first two copies agree.
> + * In case of error, matching is tried using the following pairs.
> + * Reserved values 0xffff mean the block is kept for wear leveling.
> + *
> + * 01234567 89abcdef
> + * -------- --------
> + * ECC BB xyxy oob[8]==oob[10] && oob[9]==oob[11] -> byte0=8 byte1=9
> + * ECC BB xyxy oob[10]==oob[12] && oob[11]==oob[13] -> byte0=10 byte1=11
> + * ECC BB xy xy oob[12]==oob[8] && oob[13]==oob[9] -> byte0=12 byte1=13
> + *
> + */
> +
> +static u_int sharpsl_nand_get_logical_num(u_char *oob)
> +{
> + u16 us;
> + int good0, good1;
> +
> + if (oob[NAND_NOOB_LOGADDR_00] == oob[NAND_NOOB_LOGADDR_10] &&
> + oob[NAND_NOOB_LOGADDR_01] == oob[NAND_NOOB_LOGADDR_11]) {
> + good0 = NAND_NOOB_LOGADDR_00;
> + good1 = NAND_NOOB_LOGADDR_01;
> + } else if (oob[NAND_NOOB_LOGADDR_10] == oob[NAND_NOOB_LOGADDR_20] &&
> + oob[NAND_NOOB_LOGADDR_11] == oob[NAND_NOOB_LOGADDR_21]) {
> + good0 = NAND_NOOB_LOGADDR_10;
> + good1 = NAND_NOOB_LOGADDR_11;
> + } else if (oob[NAND_NOOB_LOGADDR_20] == oob[NAND_NOOB_LOGADDR_00] &&
> + oob[NAND_NOOB_LOGADDR_21] == oob[NAND_NOOB_LOGADDR_01]) {
> + good0 = NAND_NOOB_LOGADDR_20;
> + good1 = NAND_NOOB_LOGADDR_21;
> + } else {
> + /* wrong oob fingerprint, maybe here by mistake? */
> + return UINT_MAX;
> + }
> +
> + us = oob[good0] | oob[good1] << 8;
> +
> + /* parity check */
> + if (hweight16(us) & BLOCK_UNMASK_COMPLEMENT)
> + return (UINT_MAX - 1);
> +
> + /* reserved */
> + if (us == BLOCK_IS_RESERVED)
> + return BLOCK_IS_RESERVED;
> + else
> + return (us & BLOCK_UNMASK) >> 1;
> +}
> +
> +static int sharpsl_nand_init_logical(struct mtd_info *mtd, u32 partition_size,
> + struct mtd_logical **sharpsl_mtd_logical)
> +{
> + struct mtd_logical *logical;
> + u_int block_num, log_num;
> + loff_t block_adr;
> + u_char *oob;
> + int i, ret;
> +
> + logical = kzalloc(sizeof(*logical), GFP_KERNEL);
> + if (!logical)
> + return -ENOMEM;

Just pass a simple pointer to a struct mtd_logical, this way you don't
have to allocate it here.

> +
> + oob = kzalloc(mtd->oobsize, GFP_KERNEL);
> + if (!oob) {
> + kfree(logical);
> + return -ENOMEM;
> + }
> +
> + /* initialize management structure */
> + logical->size = partition_size;
> + logical->index = mtd->index;
> + logical->phymax = (partition_size / mtd->erasesize);
> +
> + /* FTL reserves 5% of the blocks + 1 spare */
> + logical->logmax = ((logical->phymax * 95) / 100) - 1;
> +
> + logical->log2phy = kmalloc_array(logical->logmax, sizeof(u_int),
> + GFP_KERNEL);
> + if (!logical->log2phy) {
> + kfree(logical);
> + kfree(oob);
> + return -ENOMEM;
> + }
> +
> + /* initialize logical->log2phy */
> + for (i = 0; i < logical->logmax; i++)
> + logical->log2phy[i] = UINT_MAX;
> +
> + /* create physical-logical table */
> + for (block_num = 0; block_num < logical->phymax; block_num++) {
> + block_adr = block_num * mtd->erasesize;
> +
> + if (mtd_block_isbad(mtd, block_adr))
> + continue;
> +
> + if (sharpsl_nand_read_oob(mtd, block_adr, mtd->oobsize, oob))
> + continue;
> +
> + /* get logical block */
> + log_num = sharpsl_nand_get_logical_num(oob);
> +
> + /* FTL is not used? Exit here if the oob fingerprint is wrong */
> + if (log_num == UINT_MAX) {
> + pr_info("sharpslpart: Sharp SL FTL not found. Quit parser.\n");
> + ret = -EINVAL;
> + goto exit;
> + }
> +
> + /* skip out of range and not unique values */
> + if (log_num < logical->logmax) {
> + if (logical->log2phy[log_num] == UINT_MAX)
> + logical->log2phy[log_num] = block_num;
> + }
> + }

Add a blank line here.

> + pr_info("Sharp SL FTL: %d blocks used (%d logical, %d reserved)\n",
> + logical->phymax, logical->logmax,
> + logical->phymax - logical->logmax);
> +
> + *sharpsl_mtd_logical = logical;
> + ret = 0;
> +exit:
> + kfree(logical->log2phy);
> + kfree(logical);
> + kfree(oob);
> + return ret;
> +}
> +
> +static int sharpsl_nand_read_laddr(struct mtd_info *mtd,
> + loff_t from,
> + size_t len,
> + u_char *buf,
> + struct mtd_logical *sharpsl_mtd_logical)

I think Brian already suggested to use a shorter name here.

> +{
> + u_int log_num, log_new;
> + u_int block_num;
> + loff_t block_adr;
> + loff_t block_ofs;
> + size_t retlen;
> + int err;
> +
> + log_num = (u32)from / mtd->erasesize;
> + log_new = ((u32)from + len - 1) / mtd->erasesize;
> +
> + if (len <= 0 || log_num >= sharpsl_mtd_logical->logmax ||
> + log_new > log_num)
> + return -EINVAL;
> +
> + block_num = sharpsl_mtd_logical->log2phy[log_num];
> + block_adr = block_num * mtd->erasesize;
> + block_ofs = (u32)from % mtd->erasesize;
> +
> + err = mtd_read(mtd, block_adr + block_ofs, len, &retlen, buf);
> + /* Ignore corrected ECC errors */
> + if (mtd_is_bitflip(err))
> + err = 0;
> + if (!err && retlen != len)
> + err = -EIO;
> + if (err)
> + pr_err("sharpslpart: error, read failed at %#llx\n",
> + block_adr + block_ofs);
> +
> + return err;
> +}
> +
> +/*
> + * MTD Partition Parser
> + *
> + */
> +
> +struct sharpsl_nand_partitioninfo {
> + __le32 start;
> + __le32 end;
> + __be32 magic;
> + u32 reserved;
> +};
> +
> +/*
> + * Sample values read from SL-C860
> + *
> + * # cat /proc/mtd
> + * dev: size erasesize name
> + * mtd0: 006d0000 00020000 "Filesystem"
> + * mtd1: 00700000 00004000 "smf"
> + * mtd2: 03500000 00004000 "root"
> + * mtd3: 04400000 00004000 "home"
> + *
> + * PARTITIONINFO1
> + * 0x00060000: 00 00 00 00 00 00 70 00 42 4f 4f 54 00 00 00 00 ......p.BOOT....
> + * 0x00060010: 00 00 70 00 00 00 c0 03 46 53 52 4f 00 00 00 00 ..p.....FSRO....
> + * 0x00060020: 00 00 c0 03 00 00 00 04 46 53 52 57 00 00 00 00 ........FSRW....
> + * 0x00060030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
> + *
> + */
> +
> +static int sharpsl_parse_mtd_partitions(struct mtd_info *master,
> + const struct mtd_partition **pparts,
> + struct mtd_part_parser_data *data)
> +{
> + struct mtd_logical *sharpsl_mtd_logical;
> + struct sharpsl_nand_partitioninfo buf1[SHARPSL_NAND_PARTS];
> + struct sharpsl_nand_partitioninfo buf2[SHARPSL_NAND_PARTS];
> + struct mtd_partition *sharpsl_nand_parts;
> + int err;
> +
> + /* init logical mgmt (FTL) */
> + err = sharpsl_nand_init_logical(master, SHARPSL_FTL_PARTITION_SIZE,
> + &sharpsl_mtd_logical);
> + if (err)
> + return err;
> +
> + /* read the two partition tables */
> + err = sharpsl_nand_read_laddr(master,
> + PARAM_BLOCK_PARTITIONINFO1,
> + sizeof(buf1), (u_char *)&buf1,
> + sharpsl_mtd_logical) ||
> + sharpsl_nand_read_laddr(master,
> + PARAM_BLOCK_PARTITIONINFO2,
> + sizeof(buf2), (u_char *)&buf2,
> + sharpsl_mtd_logical);

Duh, this is unreadable. I thought you were not checking the 2nd return
value before realizing there was an '||' operator between those 2 calls.

Please split like that:

err = sharpsl_nand_read_laddr(master,
PARAM_BLOCK_PARTITIONINFO1,
sizeof(buf1), (u_char *)&buf1,
sharpsl_mtd_logical);
if (err)
...

err = sharpsl_nand_read_laddr(master,
PARAM_BLOCK_PARTITIONINFO2,
sizeof(buf2), (u_char *)&buf2,
sharpsl_mtd_logical);
if (err)
...

> + if (err)
> + return err;
> +
> + /* compare the two buffers */
> + if (memcmp(&buf1, &buf2, sizeof(buf1))) {
> + pr_err("sharpslpart: PARTITIONINFO 1,2 differ. Quit parser.\n");
> + return -EINVAL;
> + }

Hm, so if there's a powercut during the part-table update you can't
boot anymore? I thought having 2 partition tables was here to handle
this case.

> +
> + /* check for magics (just in the first) */
> + if (be32_to_cpu(buf1[0].magic) != BOOT_MAGIC ||
> + be32_to_cpu(buf1[1].magic) != FSRO_MAGIC ||
> + be32_to_cpu(buf1[2].magic) != FSRW_MAGIC) {
> + pr_err("sharpslpart: magic values mismatch. Quit parser.\n");
> + return -EINVAL;
> + }
> +
> + /* fixup for hardcoded value 64 MiB (for older models) */
> + buf1[2].end = cpu_to_le32(master->size);
> +
> + /* extra sanity check */
> + if (le32_to_cpu(buf1[0].end) <= le32_to_cpu(buf1[0].start) ||
> + le32_to_cpu(buf1[1].start) < le32_to_cpu(buf1[0].end) ||
> + le32_to_cpu(buf1[1].end) <= le32_to_cpu(buf1[1].start) ||
> + le32_to_cpu(buf1[2].start) < le32_to_cpu(buf1[1].end) ||
> + le32_to_cpu(buf1[2].end) <= le32_to_cpu(buf1[2].start)) {
> + pr_err("sharpslpart: partition sizes mismatch. Quit parser.\n");
> + return -EINVAL;
> + }
> +
> + sharpsl_nand_parts = kzalloc(sizeof(*sharpsl_nand_parts) *
> + SHARPSL_NAND_PARTS, GFP_KERNEL);
> + if (!sharpsl_nand_parts)
> + return -ENOMEM;
> +
> + /* original names */
> + sharpsl_nand_parts[0].name = "smf";
> + sharpsl_nand_parts[0].offset = le32_to_cpu(buf1[0].start);
> + sharpsl_nand_parts[0].size = le32_to_cpu(buf1[0].end) -
> + le32_to_cpu(buf1[0].start);
> +
> + sharpsl_nand_parts[1].name = "root";
> + sharpsl_nand_parts[1].offset = le32_to_cpu(buf1[1].start);
> + sharpsl_nand_parts[1].size = le32_to_cpu(buf1[1].end) -
> + le32_to_cpu(buf1[1].start);
> +
> + sharpsl_nand_parts[2].name = "home";
> + sharpsl_nand_parts[2].offset = le32_to_cpu(buf1[2].start);
> + sharpsl_nand_parts[2].size = le32_to_cpu(buf1[2].end) -
> + le32_to_cpu(buf1[2].start);
> +
> + *pparts = sharpsl_nand_parts;
> + return SHARPSL_NAND_PARTS;

You seem to leak sharpsl_mtd_logical here (the object is not freed
before leaving the function).

> +}
> +
> +static struct mtd_part_parser sharpsl_mtd_parser = {
> + .parse_fn = sharpsl_parse_mtd_partitions,
> + .name = "sharpslpart",
> +};
> +module_mtd_part_parser(sharpsl_mtd_parser);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Andrea Adami <[email protected]>");
> +MODULE_DESCRIPTION("MTD partitioning for NAND flash on Sharp SL Series");

2017-08-19 07:26:09

[permalink] [raw]

Subject: Re: [PATCH v5 3/9] mfd: tmio: Add partition parsers platform data

Hi Lee,

Le Tue, 15 Aug 2017 07:58:35 +0100,
Lee Jones <[email protected]> a écrit :

> On Mon, 14 Aug 2017, Andrea Adami wrote:
>
> > With the introduction of sharpslpart partition parser we can now read the
> > offsets from NAND: we specify the list of the parsers as platform data, with
> > cmdlinepart and ofpart parsers first allowing to override the part. table
> > written in NAND. This is done in the board files using this driver.
> >
> > Thus, we need to extend tmio_nand_data to consider the partition parsers.
> >
> > Signed-off-by: Andrea Adami <[email protected]>
> > ---
> > include/linux/mfd/tmio.h | 1 +
> > 1 file changed, 1 insertion(+)
>
> Acked-by: Lee Jones <[email protected]>
>

I'm about to apply patches 1 to 5 of this series to the nand/next
branch. Do you want me to create an immutable branch with this patch?

Regards,

Boris

2017-08-19 08:22:43

by Wolfram Sang

[permalink] [raw]

Subject: Re: [PATCH v5 5/9] mtd: nand: tmio: Register partitions using the parsers

On Mon, Aug 14, 2017 at 10:48:36PM +0200, Andrea Adami wrote:
> With the introduction of sharpslpart partition parser we can now read the
> offsets from NAND: we specify the list of the parsers as platform data, with
> cmdlinepart and ofpart parsers first allowing to override the part. table
> written in NAND. This is done in the board files using this driver.
>
> Use now these parsers.
>
> Signed-off-by: Andrea Adami <[email protected]>

Acked-by: Wolfram Sang <[email protected]>

Attachments:

(No filename) (509.00 B)
signature.asc (833.00 B)
Download all attachments

2017-08-19 08:23:12

by Wolfram Sang

[permalink] [raw]

Subject: Re: [PATCH v5 3/9] mfd: tmio: Add partition parsers platform data

On Mon, Aug 14, 2017 at 10:48:34PM +0200, Andrea Adami wrote:
> With the introduction of sharpslpart partition parser we can now read the
> offsets from NAND: we specify the list of the parsers as platform data, with
> cmdlinepart and ofpart parsers first allowing to override the part. table
> written in NAND. This is done in the board files using this driver.
>
> Thus, we need to extend tmio_nand_data to consider the partition parsers.
>
> Signed-off-by: Andrea Adami <[email protected]>

Acked-by: Wolfram Sang <[email protected]>

Attachments:

(No filename) (560.00 B)
signature.asc (833.00 B)
Download all attachments

2017-08-19 09:21:34

[permalink] [raw]

Subject: Re: [PATCH v5 3/9] mfd: tmio: Add partition parsers platform data

Le Sat, 19 Aug 2017 09:26:03 +0200,
Boris Brezillon <[email protected]> a écrit :

> Hi Lee,
>
> Le Tue, 15 Aug 2017 07:58:35 +0100,
> Lee Jones <[email protected]> a écrit :
>
> > On Mon, 14 Aug 2017, Andrea Adami wrote:
> >
> > > With the introduction of sharpslpart partition parser we can now read the
> > > offsets from NAND: we specify the list of the parsers as platform data, with
> > > cmdlinepart and ofpart parsers first allowing to override the part. table
> > > written in NAND. This is done in the board files using this driver.
> > >
> > > Thus, we need to extend tmio_nand_data to consider the partition parsers.
> > >
> > > Signed-off-by: Andrea Adami <[email protected]>
> > > ---
> > > include/linux/mfd/tmio.h | 1 +
> > > 1 file changed, 1 insertion(+)
> >
> > Acked-by: Lee Jones <[email protected]>
> >
>
> I'm about to apply patches 1 to 5 of this series to the nand/next

I meant patches 2 to 5, patch 1 still requires a few adjustments.

> branch. Do you want me to create an immutable branch with this patch?
>
> Regards,
>
> Boris

2017-08-21 07:27:10

by Lee Jones

[permalink] [raw]

Subject: Re: [PATCH v5 3/9] mfd: tmio: Add partition parsers platform data

On Sat, 19 Aug 2017, Boris Brezillon wrote:

> Hi Lee,
>
> Le Tue, 15 Aug 2017 07:58:35 +0100,
> Lee Jones <[email protected]> a écrit :
>
> > On Mon, 14 Aug 2017, Andrea Adami wrote:
> >
> > > With the introduction of sharpslpart partition parser we can now read the
> > > offsets from NAND: we specify the list of the parsers as platform data, with
> > > cmdlinepart and ofpart parsers first allowing to override the part. table
> > > written in NAND. This is done in the board files using this driver.
> > >
> > > Thus, we need to extend tmio_nand_data to consider the partition parsers.
> > >
> > > Signed-off-by: Andrea Adami <[email protected]>
> > > ---
> > > include/linux/mfd/tmio.h | 1 +
> > > 1 file changed, 1 insertion(+)
> >
> > Acked-by: Lee Jones <[email protected]>
> >
>
> I'm about to apply patches 1 to 5 of this series to the nand/next
> branch. Do you want me to create an immutable branch with this patch?

No, not for a single line change. Git should figure that out.

Thanks for asking though.

--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

2017-08-21 20:13:53

[permalink] [raw]

Subject: Re: [PATCH v5 0/9] mtd: sharpslpart partition parser

Le Mon, 14 Aug 2017 22:48:31 +0200,
Andrea Adami <[email protected]> a écrit :

> This patchset introduces a simple partition parser for the Sharp SL
> Series PXA handhelds. More details in the commit text.
>
> I have set in cc the ARM PXA maintainers because this is the MTD part of
> a planned wider patchset cleaning the Zaurus board files. The MFD maintainers
> are also in cc (tmio.h change).
>
> Changelog:
> v1 firt version, initial import of 2.4 sources
> v2 refactor applying many suggested fixes
> v3 put the partition parser types in the platform data
> v4 refactor after ML review
> v5 fix commit messages and subject texts, remove global, fixes after v4 review
>
> GPL sources: http://support.ezaurus.com/developer/source/source_dl.asp
>
> Andrea Adami (9):
> mtd: sharpslpart: Add sharpslpart partition parser
> mtd: nand: sharpsl: Add partition parsers platform data
> mfd: tmio: Add partition parsers platform data
> mtd: nand: sharpsl: Register partitions using the parsers
> mtd: nand: tmio: Register partitions using the parsers

Applied patches 2, to 5 to nand/next.

Thanks,

Boris

> ARM: pxa/corgi: Remove hardcoded partitioning, use sharpslpart parser
> ARM: pxa/tosa: Remove hardcoded partitioning, use sharpslpart parser
> ARM: pxa/spitz: Remove hardcoded partitioning, use sharpslpart parser
> ARM: pxa/poodle: Remove hardcoded partitioning, use sharpslpart parser
>
> arch/arm/mach-pxa/corgi.c | 31 +---
> arch/arm/mach-pxa/poodle.c | 28 +--
> arch/arm/mach-pxa/spitz.c | 34 +---
> arch/arm/mach-pxa/tosa.c | 28 +--
> drivers/mtd/nand/sharpsl.c | 2 +-
> drivers/mtd/nand/tmio_nand.c | 4 +-
> drivers/mtd/parsers/Kconfig | 8 +
> drivers/mtd/parsers/Makefile | 1 +
> drivers/mtd/parsers/sharpslpart.c | 376 ++++++++++++++++++++++++++++++++++++++
> include/linux/mfd/tmio.h | 1 +
> include/linux/mtd/sharpsl.h | 1 +
> 11 files changed, 424 insertions(+), 90 deletions(-)
> create mode 100644 drivers/mtd/parsers/sharpslpart.c
>

2017-08-23 19:33:50

[permalink] [raw]

Subject: Re: [PATCH v5 0/9] mtd: sharpslpart partition parser

Boris Brezillon <[email protected]> writes:

> Le Mon, 14 Aug 2017 22:48:31 +0200,
>> Andrea Adami (9):
>> mtd: sharpslpart: Add sharpslpart partition parser
>> mtd: nand: sharpsl: Add partition parsers platform data
>> mfd: tmio: Add partition parsers platform data
>> mtd: nand: sharpsl: Register partitions using the parsers
>> mtd: nand: tmio: Register partitions using the parsers
>
> Applied patches 2, to 5 to nand/next.
>> ARM: pxa/corgi: Remove hardcoded partitioning, use sharpslpart parser
>> ARM: pxa/tosa: Remove hardcoded partitioning, use sharpslpart parser
>> ARM: pxa/spitz: Remove hardcoded partitioning, use sharpslpart parser
>> ARM: pxa/poodle: Remove hardcoded partitioning, use sharpslpart parser

I'm quite happy with patches 6 to 9 except for the subject title length.

Andrea, if you give me an idea of change, I'll modify the titles myself before
applying, no need to resend a serie.

For example, you could propose :
ARM: pxa: corgi: use sharpslpart parser instead of hardcoded one

Then I'll take them into pxa/for-next if there are no objections.

Cheers.

--
Robert

2017-08-24 09:33:09

[permalink] [raw]

Subject: Re: [PATCH v5 0/9] mtd: sharpslpart partition parser

On Wed, Aug 23, 2017 at 9:33 PM, Robert Jarzmik <[email protected]> wrote:
> Boris Brezillon <[email protected]> writes:
>
>> Le Mon, 14 Aug 2017 22:48:31 +0200,
>>> Andrea Adami (9):
>>> mtd: sharpslpart: Add sharpslpart partition parser
>>> mtd: nand: sharpsl: Add partition parsers platform data
>>> mfd: tmio: Add partition parsers platform data
>>> mtd: nand: sharpsl: Register partitions using the parsers
>>> mtd: nand: tmio: Register partitions using the parsers
>>
>> Applied patches 2, to 5 to nand/next.
>>> ARM: pxa/corgi: Remove hardcoded partitioning, use sharpslpart parser
>>> ARM: pxa/tosa: Remove hardcoded partitioning, use sharpslpart parser
>>> ARM: pxa/spitz: Remove hardcoded partitioning, use sharpslpart parser
>>> ARM: pxa/poodle: Remove hardcoded partitioning, use sharpslpart parser
>
> I'm quite happy with patches 6 to 9 except for the subject title length.
>

Argh, this time I got it totally wrong with the titles of the patches!
Sorry for the eye-sore.

> Andrea, if you give me an idea of change, I'll modify the titles myself before
> applying, no need to resend a serie.
>
> For example, you could propose :
> ARM: pxa: corgi: use sharpslpart parser instead of hardcoded one
>
>
> Then I'll take them into pxa/for-next if there are no objections.
>
> Cheers.
>
> --
> Robert

Robert,

your suggestion is fine for me.
Please use " ARM: pxa: MACHINE: use sharpslpart parser instead of hardcoded one"

Thanks!
Andrea

2017-08-24 09:46:35

[permalink] [raw]

Subject: Re: [PATCH v5 0/9] mtd: sharpslpart partition parser

Hi Robert,

On Thu, 24 Aug 2017 11:33:02 +0200
Andrea Adami <[email protected]> wrote:

> On Wed, Aug 23, 2017 at 9:33 PM, Robert Jarzmik <[email protected]> wrote:
> > Boris Brezillon <[email protected]> writes:
> >
> >> Le Mon, 14 Aug 2017 22:48:31 +0200,
> >>> Andrea Adami (9):
> >>> mtd: sharpslpart: Add sharpslpart partition parser
> >>> mtd: nand: sharpsl: Add partition parsers platform data
> >>> mfd: tmio: Add partition parsers platform data
> >>> mtd: nand: sharpsl: Register partitions using the parsers
> >>> mtd: nand: tmio: Register partitions using the parsers
> >>
> >> Applied patches 2, to 5 to nand/next.
> >>> ARM: pxa/corgi: Remove hardcoded partitioning, use sharpslpart parser
> >>> ARM: pxa/tosa: Remove hardcoded partitioning, use sharpslpart parser
> >>> ARM: pxa/spitz: Remove hardcoded partitioning, use sharpslpart parser
> >>> ARM: pxa/poodle: Remove hardcoded partitioning, use sharpslpart parser
> >
> > I'm quite happy with patches 6 to 9 except for the subject title length.
> >
>
> Argh, this time I got it totally wrong with the titles of the patches!
> Sorry for the eye-sore.
>
> > Andrea, if you give me an idea of change, I'll modify the titles myself before
> > applying, no need to resend a serie.
> >
> > For example, you could propose :
> > ARM: pxa: corgi: use sharpslpart parser instead of hardcoded one
> >
> >
> > Then I'll take them into pxa/for-next if there are no objections.

Wait a bit before applying. I think patches 6 to 9 have a dependency on
patch 1 (it's not a build dependency, but NAND partitioning might be
wrong if you apply them), so we need to sync. What release is
pxa/for-next targeting? If it's 4.15 I can apply patch 1 just after
4.14-rc1 is out and provide an immutable branch for you to pull in
pxa/for-next.

Regards,

Boris

2017-08-29 09:18:47

[permalink] [raw]

Subject: Re: [PATCH v5 0/9] mtd: sharpslpart partition parser

Boris Brezillon <[email protected]> writes:

> Hi Robert,
> Wait a bit before applying. I think patches 6 to 9 have a dependency on
> patch 1 (it's not a build dependency, but NAND partitioning might be
> wrong if you apply them), so we need to sync. What release is
> pxa/for-next targeting? If it's 4.15 I can apply patch 1 just after
> 4.14-rc1 is out and provide an immutable branch for you to pull in
> pxa/for-next.

Hi Boris,

It's targeting 4.15 right now. And we can do as you like, either an immutable
branch, or I wait to include these patches into my pxa/for-next until you give
me your go, it's as you like.

Cheers.

--
Robert

2017-11-09 07:28:57

[permalink] [raw]

Subject: Re: [PATCH v5 0/9] mtd: sharpslpart partition parser

Boris Brezillon <[email protected]> writes:

>> Hi Boris,
>>
>> So what's the status about the sync, should I pick the patches, and have the
>> others make it to your for-next branch ?
>
> It's been merged in l2-mtd/master (our -next branch) which is
> targeting 4.15. Unfortunately we didn't create a topic branch, which
> means you'll have to wait 4.15-rc1 before pushing patches 6 to 9 if you
> want avoid regressions. Anyway, I guess it's already too late to send
> PRs to arm-soc for 4.15.

Right, my next pull request is targetting v4.16.

Andrea, would you be so kind as to resend the serie (patches 6 - 9) on the
mailing list and to me, so that I review and apply the correct version.

Thanks.

--
Robert

From 1583483703917725490@xxx Wed Nov 08 07:55:38 +0000 2017
X-GM-THRID: 1575741048012591765
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread

2017-11-08 07:55:39

[permalink] [raw]

Subject: Re: [PATCH v5 0/9] mtd: sharpslpart partition parser

On Sun, 08 Oct 2017 11:53:11 +0200
Robert Jarzmik <[email protected]> wrote:

> Robert Jarzmik <[email protected]> writes:
>
> > Boris Brezillon <[email protected]> writes:
> >
> >> Hi Robert,
> >> Wait a bit before applying. I think patches 6 to 9 have a dependency on
> >> patch 1 (it's not a build dependency, but NAND partitioning might be
> >> wrong if you apply them), so we need to sync. What release is
> >> pxa/for-next targeting? If it's 4.15 I can apply patch 1 just after
> >> 4.14-rc1 is out and provide an immutable branch for you to pull in
> >> pxa/for-next.
> >
> > Hi Boris,
> >
> > It's targeting 4.15 right now. And we can do as you like, either an immutable
> > branch, or I wait to include these patches into my pxa/for-next until you give
> > me your go, it's as you like.
>
> Hi Boris,
>
> So what's the status about the sync, should I pick the patches, and have the
> others make it to your for-next branch ?

It's been merged in l2-mtd/master (our -next branch) which is
targeting 4.15. Unfortunately we didn't create a topic branch, which
means you'll have to wait 4.15-rc1 before pushing patches 6 to 9 if you
want avoid regressions. Anyway, I guess it's already too late to send
PRs to arm-soc for 4.15.

From 1580685284391909937@xxx Sun Oct 08 10:35:58 +0000 2017
X-GM-THRID: 1575741048012591765
X-Gmail-Labels: Inbox,Category Forums

2017-10-08 10:35:58

[permalink] [raw]

Subject: Re: [PATCH v5 0/9] mtd: sharpslpart partition parser

On Sun, 8 Oct 2017 12:09:50 +0200
Boris Brezillon <[email protected]> wrote:

> On Sun, 08 Oct 2017 11:53:11 +0200
> Robert Jarzmik <[email protected]> wrote:
>
> > Robert Jarzmik <[email protected]> writes:
> >
> > > Boris Brezillon <[email protected]> writes:
> > >
> > >> Hi Robert,
> > >> Wait a bit before applying. I think patches 6 to 9 have a dependency on
> > >> patch 1 (it's not a build dependency, but NAND partitioning might be
> > >> wrong if you apply them), so we need to sync. What release is
> > >> pxa/for-next targeting? If it's 4.15 I can apply patch 1 just after
> > >> 4.14-rc1 is out and provide an immutable branch for you to pull in
> > >> pxa/for-next.
> > >
> > > Hi Boris,
> > >
> > > It's targeting 4.15 right now. And we can do as you like, either an immutable
> > > branch, or I wait to include these patches into my pxa/for-next until you give
> > > me your go, it's as you like.
> >
> > Hi Boris,
> >
> > So what's the status about the sync, should I pick the patches, and have the
> > others make it to your for-next branch ?
>
> I'm still waiting Brian's final word about this version, and if he's
> happy with it, Richard will queue it for 4.15.

Actually, I'm waiting a feedback on v9 [1], not v5.

[1]http://patchwork.ozlabs.org/patch/808431/

From 1580683689049002941@xxx Sun Oct 08 10:10:36 +0000 2017
X-GM-THRID: 1575741048012591765
X-Gmail-Labels: Inbox,Category Forums

2017-10-08 10:10:36

[permalink] [raw]

Subject: Re: [PATCH v5 0/9] mtd: sharpslpart partition parser

On Sun, 08 Oct 2017 11:53:11 +0200
Robert Jarzmik <[email protected]> wrote:

> Robert Jarzmik <[email protected]> writes:
>
> > Boris Brezillon <[email protected]> writes:
> >
> >> Hi Robert,
> >> Wait a bit before applying. I think patches 6 to 9 have a dependency on
> >> patch 1 (it's not a build dependency, but NAND partitioning might be
> >> wrong if you apply them), so we need to sync. What release is
> >> pxa/for-next targeting? If it's 4.15 I can apply patch 1 just after
> >> 4.14-rc1 is out and provide an immutable branch for you to pull in
> >> pxa/for-next.
> >
> > Hi Boris,
> >
> > It's targeting 4.15 right now. And we can do as you like, either an immutable
> > branch, or I wait to include these patches into my pxa/for-next until you give
> > me your go, it's as you like.
>
> Hi Boris,
>
> So what's the status about the sync, should I pick the patches, and have the
> others make it to your for-next branch ?

I'm still waiting Brian's final word about this version, and if he's
happy with it, Richard will queue it for 4.15.

>
> Cheers.
>

From 1580682658844112881@xxx Sun Oct 08 09:54:14 +0000 2017
X-GM-THRID: 1575741048012591765
X-Gmail-Labels: Inbox,Category Forums

2017-10-08 09:54:14