headers
Sibin K C | 19 May 2013 21:57
Picon

Dynamically creating the volume based on the size of ubifs image size

I have a requirement to create a new volume (it can be static) based
on the size of the ubifs image (say rootfs.ubifs) which I am going to
write into that volume. The aim is to create the volume with the
minimum possible size required to write 'rootfs.ubifs' to that volume
and boot the device from it.

Can somebody please help me in this regard.

Regards,
Sibin

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Permalink | Reply | 0 comments |
headers
Ezequiel Garcia | 18 May 2013 16:31
Favicon

[PATCH v3 0/1] ubi: Introduce block devices for UBI volumes

This patch adds block device access on top of UBI volumes, which allows
for a ligthweigth solution to mount block-oriented filesystems on top of
flash devices.

If you are wondering why we want this, you can read this discussion:

  http://lkml.indiana.edu/hypermail/linux/kernel/1211.2/02556.html

In particular, it's important to note this already has users:

  http://permalink.gmane.org/gmane.linux.drivers.mtd/46221

* Changes from v2 *

On this 3rd version of the patch I've re-worked the patch considerably,
mostly integrating it with UBI, instead of making it a separate module.

Despite this integration, the ubiblock code is still completely independent
of the UBI core and it can be completely compiled-out through configuration.
In turn, making ubiblock part of UBI allows to add ioctl access to attach/detach
block devices to/from UBI volumes in a very simple way.

A new tool 'ubiblkvol' is added to ubi-utils to access these two new ioctls.

To address the 'write or not to write' discussion, the write support is enabled
with a kernel option and there's a big fat 'DANGEROUS' label on it to prevent
misusage.

I'm eager to hear some comments, and perhaps some flames: it's getting very cold
this autumn south of south-america :)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Huang Shijie | 17 May 2013 05:17
Favicon

[PATCH v6 00/10] mtd: add datasheet's ECC information to nand_chip{}

1.) Why add the ECC information to the nand_chip{} ?
   Each nand chip has its requirement for the ECC correctability, such as
   "4bit ECC for each 512Byte" or "40bit ECC for each 1024Byte".
   This ECC info is very important to the nand controller, such as gpmi.

   Take the Micron MT29F64G08CBABA for example, its geometry is
   8k page size, 744 bytes oob size and it requires 40bit ECC per 1K bytes.
   If we do not provide the ECC info to the gpmi nand driver, it has to
   calculate the ECC correctability itself. The gpmi driver will gets the 56bit
   ECC for per 1K bytes which is beyond its BCH's 40bit ecc capibility.
   The gpmi will quits in this case. But in actually, the gpmi can supports
   this nand chip if it can get the right ECC info.

2.) About the patch set:
   2.1) patch 1:
   	      The keynote patch.

   2.2) patch 2 ~ patch 6:
               These patches are for ONFI nand.
               Parse out the ecc info from the parameter page if we can, else
	       parse out the ecc info from the extended parameter page.
	       
   2.2) patch 7 ~ patch 9:
               Add the ECC info for full-id nand, and parse it out.

   2.3) patch 10 
               The gpmi uses the ecc info to set the BCH module. and with this
	       patch set, the gpmi can supports the MT29F64G08CBABA now.

v5 --> v6:
(Continue reading)

Permalink | Reply | 12 comments |
headers
Jeff Westfahl | 16 May 2013 16:21
Favicon

[RESEND v2 PATCH] mtd: nand: nand_bbt: scan for next free bbt block if writing bbt fails

If erasing or writing the BBT fails, we should mark the current BBT block
as bad and use the BBT descriptor to scan for the next available unused
block in the BBT. We should only return a failure if there isn't any space
left.

Signed-off-by: Jeff Westfahl <jeff.westfahl <at> ni.com>
---
 drivers/mtd/nand/nand_bbt.c |   21 +++++++++++++++++----
 1 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/nand/nand_bbt.c b/drivers/mtd/nand/nand_bbt.c
index 2672643..900bda1 100644
--- a/drivers/mtd/nand/nand_bbt.c
+++ b/drivers/mtd/nand/nand_bbt.c
 <at>  <at>  -697,6 +697,7  <at>  <at>  static int write_bbt(struct mtd_info *mtd, uint8_t *buf,
 			page = td->pages[chip];
 			goto write;
 		}
+	next:

 		/*
 		 * Automatic placement of the bad block table. Search direction
 <at>  <at>  -831,14 +832,26  <at>  <at>  static int write_bbt(struct mtd_info *mtd, uint8_t *buf,
 		einfo.addr = to;
 		einfo.len = 1 << this->bbt_erase_shift;
 		res = nand_erase_nand(mtd, &einfo, 1);
-		if (res < 0)
-			goto outerr;
+		if (res < 0) {
+			/* This block is bad. Mark it as such and see if there's
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Westfahl | 16 May 2013 16:18
Favicon

[RESEND PATCH] mtd: nand: nand_bbt: scan for next free bbt block if writing bbt fails

If erasing or writing the BBT fails, we should mark the current BBT block
as bad and use the BBT descriptor to scan for the next available unused
block in the BBT. We should only return a failure if there isn't any space
left.

Signed-off-by: Jeff Westfahl <jeff.westfahl <at> ni.com>
---
 drivers/mtd/nand/nand_bbt.c |   21 +++++++++++++++++----
 1 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/nand/nand_bbt.c b/drivers/mtd/nand/nand_bbt.c
index 2672643..900bda1 100644
--- a/drivers/mtd/nand/nand_bbt.c
+++ b/drivers/mtd/nand/nand_bbt.c
 <at>  <at>  -697,6 +697,7  <at>  <at>  static int write_bbt(struct mtd_info *mtd, uint8_t *buf,
 			page = td->pages[chip];
 			goto write;
 		}
+	next:

 		/*
 		 * Automatic placement of the bad block table. Search direction
 <at>  <at>  -831,14 +832,26  <at>  <at>  static int write_bbt(struct mtd_info *mtd, uint8_t *buf,
 		einfo.addr = to;
 		einfo.len = 1 << this->bbt_erase_shift;
 		res = nand_erase_nand(mtd, &einfo, 1);
-		if (res < 0)
-			goto outerr;
+		if (res < 0) {
+			/* This block is bad. Mark it as such and see if there's
(Continue reading)

Permalink | Reply | 0 comments |
headers
Caizhiyong | 16 May 2013 15:36
Favicon

mounting ubifs read-only, is it really readonly, not any wirte/erase?

    I'm using ubifs as root filesystem, and mounted readonly.

    bootargs are:
        console=ttyAMA0,115200 ubi.mtd=3 root=ubi0:ubifs ro rootfstype=ubifsmtdparts=hi_sfc:-(spi);hinand:10M(10M),50M(50M),50M(50M),-(data)
    
    I'm update ubi.img in uboot used command "nand write xxxx", but when kernel (linux 3.4) startup, there are
some write/erase operation.

    I'm add prints to the following functions:

        * %-EIO is returned, the physical eraseblock most probably went bad.
        */
        static int do_sync_erase(struct ubi_device *ubi, int pnum)
        {
            int err, retries = 0;
            struct erase_info ei;
            wait_queue_head_t wq;

            dump_stack();
            printk("\n\n\n");
            return 0;

    The stack dump prints as follow:

        [<c0014c64>] (unwind_backtrace+0x0/0xfc) from [<c02a2a2c>] (do_sync_erase+0x8/0x1c)
        [<c02a2a2c>] (do_sync_erase+0x8/0x1c) from [<c02a3818>] (ubi_io_sync_erase+0x304/0x424)
        [<c02a3818>] (ubi_io_sync_erase+0x304/0x424) from [<c02a41e8>] (erase_worker+0x50/0x510)
        [<c02a41e8>] (erase_worker+0x50/0x510) from [<c02a4f80>] (do_work+0x84/0xd4)
        [<c02a4f80>] (do_work+0x84/0xd4) from [<c02a50ac>] (ubi_thread+0xdc/0x188)
        [<c02a50ac>] (ubi_thread+0xdc/0x188) from [<c0039468>] (kthread+0x94/0x98)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Westfahl | 16 May 2013 15:35
Favicon

[RESEND PATCH] mtd: nand: nand_bbt: scan for next free bbt block if writing bbt fails

If erasing or writing the BBT fails, we should mark the current BBT block
as bad and use the BBT descriptor to scan for the next available unused
block in the BBT. We should only return a failure if there isn't any space
left.

Signed-off-by: Jeff Westfahl <jeff.westfahl <at> ni.com>
---
 drivers/mtd/nand/nand_bbt.c |   21 +++++++++++++++++----
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/nand/nand_bbt.c b/drivers/mtd/nand/nand_bbt.c
index 2672643..900bda1 100644
--- a/drivers/mtd/nand/nand_bbt.c
+++ b/drivers/mtd/nand/nand_bbt.c
 <at>  <at>  -697,6 +697,7  <at>  <at>  static int write_bbt(struct mtd_info *mtd, uint8_t 
*buf,
                        page = td->pages[chip];
                        goto write;
                }
+       next:

                /*
                 * Automatic placement of the bad block table. Search 
direction
 <at>  <at>  -831,14 +832,26  <at>  <at>  static int write_bbt(struct mtd_info *mtd, uint8_t 
*buf,
                einfo.addr = to;
                einfo.len = 1 << this->bbt_erase_shift;
                res = nand_erase_nand(mtd, &einfo, 1);
-               if (res < 0)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Westfahl | 15 May 2013 22:44
Favicon

[PATCH] mtd: nand: nand_bbt: scan for next free bbt block if writing bbt fails

If erasing or writing the BBT fails, we should mark the current BBT block
as bad and use the BBT descriptor to scan for the next available unused
block in the BBT. We should only return a failure if there isn't any space
left.

Signed-off-by: Jeff Westfahl <jeff.westfahl <at> ni.com>
---
 drivers/mtd/nand/nand_bbt.c |   21 +++++++++++++++++----
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/nand/nand_bbt.c b/drivers/mtd/nand/nand_bbt.c
index 2672643..900bda1 100644
--- a/drivers/mtd/nand/nand_bbt.c
+++ b/drivers/mtd/nand/nand_bbt.c
 <at>  <at>  -697,6 +697,7  <at>  <at>  static int write_bbt(struct mtd_info *mtd, uint8_t 
*buf,
                                                 page = td->pages[chip];
                                                 goto write;
                                 }
+                next:

                                 /*
                                  * Automatic placement of the bad block 
table. Search direction
 <at>  <at>  -831,14 +832,26  <at>  <at>  static int write_bbt(struct mtd_info *mtd, uint8_t 
*buf,
                                 einfo.addr = to;
                                 einfo.len = 1 << this->bbt_erase_shift;
                                 res = nand_erase_nand(mtd, &einfo, 1);
-                                if (res < 0)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dirk Behme | 15 May 2013 18:21
Picon

[PATCH] UBIFS: add tolerance to use variable writesize

From: Achim Dahlhoff <Achim.Dahlhoff <at> de.bosch.com>

UBIfs adapts it‘s structures according to the minimum writeSize reported
by the MTD device. For NOR flash devices, this is normally 1. For NOR
devices with internal hardware-ECC it might be more, such as the S-Die
flash chips of Micron which can use an internal ECC if the chip is
accessed in 32 byte chunks.

The UBIfs mount process checks and compares the writeSize set in the
image and the writeSize reported from the /dev/mtd . UBIfs will fail
to mount if the values differ. It should, though, not be a problem to
mount an image which was created with a writeSize larger than that of
the MTD, if it is larger by an integer factor.

This commit changes the check in a way so it will allow the image
writeSize to be larger than that of the MTD by an integer factor.
It will allow to create images and deploy them on different devices
using different writeSizes. writeSize found using values of 1, 8 and 32.

Signed-off-by: Achim Dahlhoff <Achim.Dahlhoff <at> de.bosch.com>
---
 fs/ubifs/sb.c |   12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/fs/ubifs/sb.c b/fs/ubifs/sb.c
index 4c37607..69dd794 100644
--- a/fs/ubifs/sb.c
+++ b/fs/ubifs/sb.c
 <at>  <at>  -351,6 +351,7  <at>  <at>  static int validate_sb(struct ubifs_info *c, struct ubifs_sb_node *sup)
 {
(Continue reading)

Permalink | Reply | 0 comments |
headers
Artem Bityutskiy | 15 May 2013 11:58
Picon

Re: corrupted empty space - again

On Wed, 2013-05-15 at 11:42 +0200, Michał Przepłata wrote:
> My assumption is that when UBIFS will write 2kB page to the empty space
> with bitflips, it will (right after writting) verify ECC of that data to
> be sure it is correct, and if it isn't it will write to a different LEB
> and scrub this one. That way there will be no data loss. Isn't that the
> way things are done?

No, we do not do this - it would be too ineffecient if UBIFS read
everything it just wrote. Besides, MTD layer may do some caching, and
reading may return results from a cache...

The driver can implement this functionality, though. It could then
return an error, and then UBI would have to do recovery, which is not
very fast process, because it involves moving all the data from the
faulty erasebolock somewhere else, and then torture the faulty one.

I think it is more efficient to do something in the driver on the read
path. I really do not know what would be a robust and fast solution,
though. You could check if ECC's bytes in OOB are all 0xFFs, which would
mean that the page is empty, and you need to verify the bit-flips. But
the OOB area itself may have bit-flips in the ECC positions...

But there are people in this list who are more knoledgable in the area.
I am out of MTD business for several years already and forgot a lot of
things. You just need to somehow get their attention :-)
> >
> > I think this is a bad idea, because this way you also ignore real
> > corruptions, instead of noticing them right away.
> On UBI homepage there is mentioned that one should write a process
> that will periodically re-read all UBI blocks, in order to not let
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ezequiel Garcia | 14 May 2013 13:15
Picon
Gravatar

[PATCH 0/5] mtd: nand: Fixes and improvements on pxa3xx

The Armada 370 and Armada XP SoC include a NAND controller (NFCv2) that
is similar to the one in PXA SoC. Therefore, it should be possible to support
Armada NAND using pxa3xx-nand driver.

While this effort is not ready yet, here is a set of patches that are needed
for such work.

A small summary of the patches:

  * 1/5 is a fix for a 2-year regression that removed DMA support.

  * 2/5 and 3/5 are needed to build the driver on platforms other PXA.

  * 4/5 and 5/5 add ONFI-compliant device detection and are needed
    to successfully probe newer flash devices.

Applies cleanly on top of l2-mtd.git.

Thanks!

Ezequiel Garcia (5):
  mtd: nand: pxa3xx: Set info->use_dma properly
  mtd: nand: pxa3xx: Use of_machine_is_compatible()
  mtd: nand: pxa3xx: Fix MODULE_DEVICE_TABLE declaration
  mtd: nand: pxa3xx: Add address support for READID command
  mtd: nand: pxa3xx: Add support for Read parameter page command

 drivers/mtd/nand/pxa3xx_nand.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)
(Continue reading)

Permalink | Reply | 5 comments |

Gmane