Hauke Mehrtens | 24 May 19:16 2015

iProc nand iproc-idm register

Hi Ray,

in the iproc_nand driver your are using this register range:
reg = <0x18046000 0x600>, <0xf8105408 0x600>, <0x18046f00 0x20>;
reg-names = "nand", "iproc-idm", "iproc-ext";

I think the iproc-idm register range is the wrap address part on bcma
bus. On the bcma bus it is 0x1000 in size and 0x0408 is the offset of
the IO control register in it. Are the new iProc devices different here
or is this register not always at this offset but varies?

Wouldn't it be better to specify the complete range like this:
reg = <0x18046000 0x600>, <0xf8105000 0x1000>, <0x18046f00 0x20>;
Then you can read the register at offset 0x408 in that range.


Linux MTD discussion mailing list

Guido Martínez | 22 May 20:32 2015

[RFC/PATCH] ubi-utils: add ubiecdump tool

This utility allows to dump the erase counter of each PEB in the UBI
device for auditing and testing purposes. It prints one value per line,
using -1 for bad PEBs and when errors occur. This allows to do some
quick stats like:

$ ubidumpec -m 7 | sort -n | uniq -c
     21 -1
    682 8
    130 9
    538 10

 where we see 21 bad blocks, 682 blocks with an EC of 8 and so on, or to
plot histograms automatically.

It can be invoked with either an attached ubi device (/dev/ubi0) or with
and MTD device that contains a UBI volume (-m 7).

Signed-off-by: Guido Martínez <guido <at> vanguardiasur.com.ar>
Hi, this new tools allow to do some easy auditing on the ECs of the UBI
device. It was inspired by the "Wear-leveling peculiarities" thread on
linux-mtd. It only support printing the ECs one-by-one, but I could
extend it to show basic statistics if there's interest for that.


 Makefile              |   3 +-
 ubi-utils/.gitignore  |   1 +
 ubi-utils/ubidumpec.c | 186 ++++++++++++++++++++++++++++++++++++++++++++++++++
(Continue reading)

Brian Norris | 22 May 19:58 2015

[PATCH] mtd: remove incorrect file name

This is an example of why it doesn't make much sense to put this
information here in the first place. I don't really know what purpose it

Signed-off-by: Brian Norris <computersforpeace <at> gmail.com>
 drivers/mtd/devices/spear_smi.c | 4 ++--
 drivers/mtd/nand/nand_base.c    | 2 --
 drivers/mtd/nand/nand_bbt.c     | 2 --
 drivers/mtd/nand/nand_ids.c     | 2 --
 drivers/mtd/nand/ndfc.c         | 2 --
 5 files changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/mtd/devices/spear_smi.c b/drivers/mtd/devices/spear_smi.c
index 508bab3bd0c4..04b24d2b03f2 100644
--- a/drivers/mtd/devices/spear_smi.c
+++ b/drivers/mtd/devices/spear_smi.c
 <at>  <at>  -1,8 +1,8  <at>  <at> 
  * SMI (Serial Memory Controller) device driver for Serial NOR Flash on
  * SPEAr platform
- * The serial nor interface is largely based on drivers/mtd/m25p80.c,
- * however the SPI interface has been replaced by SMI.
+ * The serial nor interface is largely based on m25p80.c, however the SPI
+ * interface has been replaced by SMI.
  * Copyright © 2010 STMicroelectronics.
  * Ashish Priyadarshi
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index c4619e3ac4ab..a157757347ec 100644
(Continue reading)

Brian Norris | 22 May 19:58 2015

[PATCH] mtd: nand: correct indentation within conditional

We had an extra tab.

Signed-off-by: Brian Norris <computersforpeace <at> gmail.com>
 drivers/mtd/nand/nand_base.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index a157757347ec..ceb68ca8277a 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
 <at>  <at>  -3685,7 +3685,7  <at>  <at>  static struct nand_flash_dev *nand_get_flash_type(struct mtd_info *mtd,
 			if (find_full_id_nand(mtd, chip, type, id_data, &busw))
 				goto ident_done;
 		} else if (*dev_id == type->dev_id) {
-				break;
+			break;



Linux MTD discussion mailing list

Nikhilesh Reddy | 22 May 02:31 2015

ubi_assert(list_empty(&used)) in ubi_attach_fastmap


I am running kernel 3.10.

I recently saw an issue where ubi_assert(list_empty(&used)) in 
ubi_attach_fastmap always hits on a partition.

Searching this issue I found
diff --git a/drivers/mtd/ubi/fastmap.c b/drivers/mtd/ubi/fastmap.c
index 600c4f9..9858bfb 100644 (file)
--- a/drivers/mtd/ubi/fastmap.c
+++ b/drivers/mtd/ubi/fastmap.c
 <at>  <at>  -814,7 +814,9  <at>  <at>  static int ubi_attach_fastmap(struct ubi_device *ubi,
         list_for_each_entry_safe(tmp_aeb, _tmp_aeb, &free, u.list)
                 list_move_tail(&tmp_aeb->u.list, &ai->free);

-       ubi_assert(list_empty(&used));
+       list_for_each_entry_safe(tmp_aeb, _tmp_aeb, &used, u.list)
+               list_move_tail(&tmp_aeb->u.list, &ai->erase);

Can you please give me a background on this patch.
Is this safe to apply without any of patches in the list


Can this occur when trying to attach an empty partition?
(Continue reading)

Sheng Yong | 21 May 11:56 2015

[RFC PATCH 0/4] UBI: Fastmap: Some cleanup and check if a vol exists when attaching

Hi, folks,

PATCH 1-3 do some cleanup.

PATCH 4 checks if a volume already exists when fastmap doing attach.
ubi_write_fastmap() does not guarantee if two volumes have the same vol
ID. So fastmap should check it when attaching, and if something is wrong,
scan_all() could try to attach instead of fastmap.


Sheng Yong (4):
  UBI: Fastmap: Use max() to get the larger value
  UBI: Fastmap: Remove unnecessary `\'
  UBI: Fastmap: Rename variables to make them meaningful
  UBI: Fastmap: Do not add vol if it already exists

 drivers/mtd/ubi/build.c   |  4 +--
 drivers/mtd/ubi/fastmap.c | 81 +++++++++++++++++++++++++----------------------
 2 files changed, 46 insertions(+), 39 deletions(-)



Linux MTD discussion mailing list

(Continue reading)

Brian Norris | 21 May 02:05 2015

[PATCH 1/3] mtd: brcmnand: refactor bcm63138 SoC layering

Removes an unnecessary allocation and saves a little bit of pointer

Signed-off-by: Brian Norris <computersforpeace <at> gmail.com>
 drivers/mtd/nand/brcmnand/bcm63138_nand.c | 18 ++++++++----------
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/mtd/nand/brcmnand/bcm63138_nand.c b/drivers/mtd/nand/brcmnand/bcm63138_nand.c
index 3f4c44c24e14..59444b3a697d 100644
--- a/drivers/mtd/nand/brcmnand/bcm63138_nand.c
+++ b/drivers/mtd/nand/brcmnand/bcm63138_nand.c
 <at>  <at>  -22,7 +22,8  <at>  <at> 

 #include "brcmnand.h"

-struct bcm63138_nand_soc_priv {
+struct bcm63138_nand_soc {
+	struct brcmnand_soc soc;
 	void __iomem *base;

 <at>  <at>  -35,7 +36,8  <at>  <at>  enum {

 static bool bcm63138_nand_intc_ack(struct brcmnand_soc *soc)
-	struct bcm63138_nand_soc_priv *priv = soc->priv;
+	struct bcm63138_nand_soc *priv =
+			container_of(soc, struct bcm63138_nand_soc, soc);
 	void __iomem *mmio = priv->base + BCM63138_NAND_INT_STATUS;
(Continue reading)

Punnaiah Choudary Kalluri | 19 May 15:49 2015

[PATCH v2 1/2] mtd: arasan: Add device tree binding documentation

This patch adds the dts binding document for arasan nand flash

Signed-off-by: Punnaiah Choudary Kalluri <punnaia <at> xilinx.com>
Changes in v2:
- None.
 .../devicetree/bindings/mtd/arasan_nfc.txt         |   27 ++++++++++++++++++++
 1 files changed, 27 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mtd/arasan_nfc.txt

diff --git a/Documentation/devicetree/bindings/mtd/arasan_nfc.txt b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
new file mode 100644
index 0000000..7815120
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
 <at>  <at>  -0,0 +1,27  <at>  <at> 
+Arasan Nand Flash Controller with ONFI 3.1 support
+Required properties:
+- compatible: Should be "arasan,nfc-v3p10"
+- reg: Memory map for module access
+- interrupt-parent: Interrupt controller the interrupt is routed through
+- interrupts: Should contain the interrupt for the device
+Optional properties:
+- arasan,has-mdma: Boolean to support dma transfer for nand read/write.
+for nand partition information please refer the below file
(Continue reading)

Michał Leśniewski | 19 May 11:24 2015

Influence of mkfs.jffs2 parameters on file system behavior


I have a question about the parameters passed to mkfs.jffs2 and their
influence on the JFFS2 behavior.

When generating an image one can specify the erase block size of the
flash, for which the image is generated, by suppling
`--eraseblock=...` on the command line.  There is also a `--pagesize`
parameter -- this parameter allows specifying the virtual memory page
size of the target system (often 4kB).

I found out that by mistake, I generated images with the wrong values
of these two parameters:

1. Some of the images I used were generated with the right page size
(4kB), but the wrong erase block size (flash memory has 128kB blocks,
the parameter supplied to mkfs.jffs2 was 64kB).  Surprisingly, I
didn't experience any problems with the file system, even when the
file system was heavily used (lots of file reads, rewrites, etc.).
However, when I switched the kernel from version 2.6.27 to version
3.4.31, sometimes files seemed to be trimmed or parts of them were
zeroed.  Could this be caused by the erase block size mismatch? The
documentation states that generating an image with a smaller erase
block than the actual flash device uses is harmless

2. Some other images I generated used the right erase block size but
the wrong virtual memory page size (2kB instead of 4kB).  I didn't
encounter any problems with the file system.  So in this case my
question is what influence does the `--pagesize` parameter have and
(Continue reading)

Brian Norris | 19 May 01:26 2015

[PATCH] mtd: lantiq-flash: use default partition parsers

The default implementation already probes for cmdlinepart and ofpart.

Signed-off-by: Brian Norris <computersforpeace <at> gmail.com>
 drivers/mtd/maps/lantiq-flash.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/mtd/maps/lantiq-flash.c b/drivers/mtd/maps/lantiq-flash.c
index 33d26f5bee54..e2f878216048 100644
--- a/drivers/mtd/maps/lantiq-flash.c
+++ b/drivers/mtd/maps/lantiq-flash.c
 <at>  <at>  -45,7 +45,6  <at>  <at>  struct ltq_mtd {

 static const char ltq_map_name[] = "ltq_nor";
-static const char * const ltq_probe_types[] = { "cmdlinepart", "ofpart", NULL };

 static map_word
 ltq_read16(struct map_info *map, unsigned long adr)
 <at>  <at>  -168,8 +167,7  <at>  <at>  ltq_mtd_probe(struct platform_device *pdev)
 	cfi->addr_unlock2 ^= 1;

 	ppdata.of_node = pdev->dev.of_node;
-	err = mtd_device_parse_register(ltq_mtd->mtd, ltq_probe_types,
-					&ppdata, NULL, 0);
+	err = mtd_device_parse_register(ltq_mtd->mtd, NULL, &ppdata, NULL, 0);
 	if (err) {
 		dev_err(&pdev->dev, "failed to add partitions\n");
 		goto err_destroy;

(Continue reading)

Brian Norris | 19 May 01:25 2015

[PATCH] mtd: plat_nand: use default partition probe

It's harmless to add 'ofpart' (the only different parser supported in
default mtdpart.c) to plat_nand. That let's us kill off one more custom
partition prober listing.

Signed-off-by: Brian Norris <computersforpeace <at> gmail.com>
 drivers/mtd/nand/plat_nand.c | 4 +---
 drivers/mtd/nand/xway_nand.c | 4 ----
 2 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/mtd/nand/plat_nand.c b/drivers/mtd/nand/plat_nand.c
index 4535c263fae5..717cf623fcde 100644
--- a/drivers/mtd/nand/plat_nand.c
+++ b/drivers/mtd/nand/plat_nand.c
 <at>  <at>  -24,8 +24,6  <at>  <at>  struct plat_nand_data {
 	void __iomem		*io_base;

-static const char *part_probe_types[] = { "cmdlinepart", NULL };
  * Probe for the NAND device.
 <at>  <at>  -95,7 +93,7  <at>  <at>  static int plat_nand_probe(struct platform_device *pdev)
 		goto out;

-	part_types = pdata->chip.part_probe_types ? : part_probe_types;
+	part_types = pdata->chip.part_probe_types;

(Continue reading)