headers
Brian Norris | 1 Jun 2011 01:31
Picon

[PATCH 2/8] mtd: nand: separate chip options / bbt_options

This patch handles the problems we've been having with using conflicting
flags from nand.h and bbm.h in the same nand_chip.options field. We
should try to separate these two spaces a little more clearly, and so I
have added a bbt_options field to nand_chip.

Important notes about nand_chip fields:
* bbt_options field should contain ONLY flags from bbm.h. They should be
  able to pass safely to a nand_bbt_descr data structure.
    - BBT option flags start with the "NAND_BBT_" prefix.
* options field should contian ONLY flags from nand.h. Ideally, they
  should not be involved in any BBT related options.
    - NAND chip option flags start with the "NAND_" prefix.
* Every flag should have a nice comment explaining what the flag is. While
  this is not yet the case on all existing flags, please be sure to write
  one for new flags. Even better, you can help document the code better
  yourself!

Please try to follow these conventions to make everyone's lives easier.

Among the flags that are being moved to the new bbt_options field
throughout various drivers, etc. are:
 * NAND_BBT_SCANLASTPAGE
 * NAND_BBT_SCAN2NDPAGE
and there will be more to come.

Signed-off-by: Brian Norris <computersforpeace <at> gmail.com>
---
 drivers/mtd/nand/nand_base.c |   10 +++++-----
 drivers/mtd/nand/nand_bbt.c  |    5 ++---
 include/linux/mtd/nand.h     |    4 ++++
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian Norris | 1 Jun 2011 01:31
Picon

[PATCH 4/8] mtd: nand: rename NAND_USE_FLASH_BBT

Recall the recently added prefix requirements:
 * "NAND_" for flags in nand.h, used in nand_chip.options
 * "NAND_BBT_" for flags in bbm.h, used in nand_chip.bbt_options
        or in nand_bbt_descr.options

Thus, I am changing NAND_USE_FLASH_BBT to NAND_BBT_USE_FLASH.

Again, this flag is found in bbm.h and so should NOT be used in the
"nand_chip.options" field.

Signed-off-by: Brian Norris <computersforpeace <at> gmail.com>
---
 Documentation/DocBook/mtdnand.tmpl             |    2 +-
 arch/arm/mach-davinci/board-da830-evm.c        |    2 +-
 arch/arm/mach-davinci/board-da850-evm.c        |    2 +-
 arch/arm/mach-davinci/board-dm355-evm.c        |    2 +-
 arch/arm/mach-davinci/board-dm355-leopard.c    |    2 +-
 arch/arm/mach-davinci/board-dm365-evm.c        |    2 +-
 arch/arm/mach-davinci/board-dm644x-evm.c       |    2 +-
 arch/arm/mach-davinci/board-mityomapl138.c     |    2 +-
 arch/arm/mach-davinci/board-neuros-osd2.c      |    2 +-
 arch/arm/mach-davinci/board-tnetv107x-evm.c    |    2 +-
 arch/arm/mach-davinci/include/mach/nand.h      |    2 +-
 arch/arm/mach-orion5x/ts78xx-setup.c           |    2 +-
 arch/cris/arch-v32/drivers/mach-a3/nandflash.c |    2 +-
 arch/cris/arch-v32/drivers/mach-fs/nandflash.c |    2 +-
 drivers/mtd/nand/atmel_nand.c                  |    2 +-
 drivers/mtd/nand/autcpu12.c                    |    4 ++--
 drivers/mtd/nand/bcm_umi_nand.c                |    2 +-
 drivers/mtd/nand/cafe_nand.c                   |    2 +-
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian Norris | 1 Jun 2011 01:32
Picon

Re: git.infradead.org is being lazy

On Tue, May 31, 2011 at 11:07 AM, Mike Frysinger <vapier.adi <at> gmail.com> wrote:
> git.infradead.org appears to be dead.  anyone know when it'll be back
> ?  i havent pulled mtd-utils.git in a while, so my local clone isnt
> too useful (to see if a bug we found has been fixed).

I've had that same problem multiple times recently (including today).
lists.infradead.org was also having problems, I think.

Anyway, the servers seem to be up again.

Brian

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Permalink | Reply | 0 comments |
headers
Brian Norris | 1 Jun 2011 01:31
Picon

[PATCH 7/8] mtd: nand: renumber the reorganized flags in nand.h / bbm.h

After several steps of rearrangement and consolidation, it is probably
worth re-sequencing the numbers on some of our affected flags in nand.h
and bbm.h.

Signed-off-by: Brian Norris <computersforpeace <at> gmail.com>
---
 include/linux/mtd/bbm.h  |   23 ++++++++++++-----------
 include/linux/mtd/nand.h |    6 +++---
 2 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/include/linux/mtd/bbm.h b/include/linux/mtd/bbm.h
index 0fa030a..57d6a8d 100644
--- a/include/linux/mtd/bbm.h
+++ b/include/linux/mtd/bbm.h
 <at>  <at>  -92,28 +92,29  <at>  <at>  struct nand_bbt_descr {
  * layout or if this information is already purged. Must be used in conjunction
  * with NAND_BBT_CREATE.
  */
-#define NAND_BBT_CREATE_EMPTY	0x01000000
+#define NAND_BBT_CREATE_EMPTY	0x00000400
 /* Search good / bad pattern through all pages of a block */
-#define NAND_BBT_SCANALLPAGES	0x00000400
+#define NAND_BBT_SCANALLPAGES	0x00000800
 /* Scan block empty during good / bad block scan */
-#define NAND_BBT_SCANEMPTY	0x00000800
+#define NAND_BBT_SCANEMPTY	0x00001000
 /* Write bbt if neccecary */
-#define NAND_BBT_WRITE		0x00001000
+#define NAND_BBT_WRITE		0x00002000
 /* Read and write back block contents when writing bbt */
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike Frysinger | 1 Jun 2011 04:20
Picon

Re: [PATCH v6 1/8] MTD: Add integrator-flash feature to physmap

On Tue, May 31, 2011 at 17:44, Marc Zyngier wrote:
> On Tue, 31 May 2011 23:11:14 +0400 Sergei Shtylyov wrote:
>> Marc Zyngier wrote:
>> > In the process of moving platforms away from integrator-flash
>> > (aka armflash), add to physmap the few features that make
>> > armflash unique:
>>
>> > - optionnal probing for the AFS partition type
>> > - init() and exit() methods, used by Integrator to control
>> >   write access to the various onboard programmable components
>>
>> > Signed-off-by: Marc Zyngier <marc.zyngier <at> arm.com>
>> > Acked-by: Catalin Marinas <catalin.marinas <at> arm.com>
>> > Cc: David Woodhouse <dwmw2 <at> infradead.org>
>> [...]
>>
>> > diff --git a/include/linux/mtd/physmap.h b/include/linux/mtd/physmap.h
>> > index bcfd9f7..d37cca0 100644
>> > --- a/include/linux/mtd/physmap.h
>> > +++ b/include/linux/mtd/physmap.h
>> >  <at>  <at>  -22,6 +22,8  <at>  <at>  struct map_info;
>> >
>> >  struct physmap_flash_data {
>> >     unsigned int            width;
>> > +   int                     (*init)(struct platform_device *);
>> > +   void                    (*exit)(struct platform_device *);
>>
>>     How about a declaration for 'struct platform_device' beforehand? This breaks
>> build on other platforms at least...
>
(Continue reading)

Permalink | Reply | 5 comments |
headers
Artem Bityutskiy | 1 Jun 2011 09:42
Picon

Re: [PATCH v6 1/8] MTD: Add integrator-flash feature to physmap

On Tue, 2011-05-31 at 22:20 -0400, Mike Frysinger wrote:
> On Tue, May 31, 2011 at 17:44, Marc Zyngier wrote:
> > On Tue, 31 May 2011 23:11:14 +0400 Sergei Shtylyov wrote:
> >> Marc Zyngier wrote:
> >> > In the process of moving platforms away from integrator-flash
> >> > (aka armflash), add to physmap the few features that make
> >> > armflash unique:
> >>
> >> > - optionnal probing for the AFS partition type
> >> > - init() and exit() methods, used by Integrator to control
> >> >   write access to the various onboard programmable components
> >>
> >> > Signed-off-by: Marc Zyngier <marc.zyngier <at> arm.com>
> >> > Acked-by: Catalin Marinas <catalin.marinas <at> arm.com>
> >> > Cc: David Woodhouse <dwmw2 <at> infradead.org>
> >> [...]
> >>
> >> > diff --git a/include/linux/mtd/physmap.h b/include/linux/mtd/physmap.h
> >> > index bcfd9f7..d37cca0 100644
> >> > --- a/include/linux/mtd/physmap.h
> >> > +++ b/include/linux/mtd/physmap.h
> >> >  <at>  <at>  -22,6 +22,8  <at>  <at>  struct map_info;
> >> >
> >> >  struct physmap_flash_data {
> >> >     unsigned int            width;
> >> > +   int                     (*init)(struct platform_device *);
> >> > +   void                    (*exit)(struct platform_device *);
> >>
> >>     How about a declaration for 'struct platform_device' beforehand? This breaks
> >> build on other platforms at least...
(Continue reading)

Permalink | Reply | 1 comment |
headers
Artem Bityutskiy | 1 Jun 2011 09:48
Picon

Re: ubifs_decompress: cannot decompress ...

On Fri, 2011-05-27 at 17:12 -0400, Matthew L. Creech wrote:
> Hi,
> 
> We encountered a device which has the following error:
> 
> UBIFS error (pid 428): ubifs_decompress: cannot decompress 1010 bytes,
> compressor lzo, error -22
> UBIFS error (pid 428): read_block: bad data node (block 388, inode 556196)
> UBIFS error (pid 428): do_readpage: cannot read page 388 of inode
> 556196, error -22
> UBIFS error (pid 428): ubifs_decompress: cannot decompress 1010 bytes,
> compressor lzo, error -22
> UBIFS error (pid 428): read_block: bad data node (block 388, inode 556196)
> UBIFS error (pid 428): do_readpage: cannot read page 388 of inode
> 556196, error -22
> 
> The device is still bootable (though not functional), so I can get
> more debug info if needed.  Any ideas on what could cause this?

Yes, you can enable mount and recovery debugging messages and send me
the log.

> - MPC8313 (using fsl_elbc_nand driver)
> - 1GB NAND flash (partitioned into 5MB for U-Boot, remainder for UBI/UBIFS)
> - 2.6.39 kernel
> 
> Thanks!
> 

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Artem Bityutskiy | 1 Jun 2011 09:51
Picon

Re: ubifs_decompress: cannot decompress ...

On Tue, 2011-05-31 at 17:47 -0400, Matthew L. Creech wrote:
> Unfortunately it's not repeatable enough for us to capture adequate
> debug output - we've had several devices logging extensive debug
> output via netconsole for months now, but none have recreated this
> problem so far under those conditions.

How this happens? What do you do? Does this happen after mount when you
first read your data? Or this happens at some point while you stress
testing your system? Or this happens after a power cut?

--

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Permalink | Reply | 14 comments |
headers
Lars Michael | 1 Jun 2011 09:57
Picon
Favicon

U-Boot: using nand write to flash an ubi image, ubi part fails

Hello,

Using mkfs.ubifs and ubinize I have created an image with 5 volumes. In Linux I could flash it using
"ubiformat /dev/mtd1 -f /root/ubi.img" and attach it using "ubiattach /dev/ubi_ctrl -m 1". It worked.

In production I would prefer to write the image from U-Boot. So in U-Boot I used "nand erase" then "nand
write" to flash the image. Then I want to attach by "ubi part" command - but this fails: "UBI error:
ubi_init: UBI error: cannot initialize UBI, error -17"

Then I booted Linux (via nfs) and tried to re-format+attach, but now it fails. Format complains about
eraseblock contents and missing erase counters: 

ubiformat: warning!: 1099 of 2036 eraseblocks contain non-ubifs data
ubiformat: warning!: only 937 of 2036 eraseblocks have valid erase counter

The ubiattach now reports lots of:
...
UBI error: check_corruption: PEB 0 contains corrupted VID header, and the data does not contain all 0xFF,
this may be a non-UBI PEB or a severe VID header corruption which requires manual inspection

UBI warning: process_eb: valid VID header but corrupted EC header at PEB 4
...

I realize that the U-Boot 'nand erase' does not preserve the erase counters. So what would be the correct way
to erase and write in U-Boot? And why is the ubiformat not able to correct the problems?

My kernel is 2.6.29 patched with 165 patched from the ubi back port tree.
U-Boot is 2009.08 with ubifs support, but I am not sure if there are relevant patches. The CPU is a v4 ColdFire
and 256MB Micron NAND.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Artem Bityutskiy | 1 Jun 2011 09:54
Picon

Re: -EBADMSG with free-space-fixup flag

On Fri, 2011-05-27 at 17:47 -0400, Ben Gardiner wrote:
> Hi Matthew, Artem,
> 
> Following-up on my problems with the free-space-fixup no da850evm.
> 
> I have done lots of manual testing with u-boot and mtd-utils on-top-of
> 'c724452 UBIFS: switch to dynamic printks' to confirm that there isn't
> an 0xff ECC problem with davinci-nand.
> 
> I found that by the time the -74 is returned for PEB 18, the contents
> on NAND have been replaced.
> 
> I turned on lots of UBIFS debugging and saw that the PEB in question
> is in fact LEB 1; which is geting written to as part of the
> auto-resize of (master)

OK, so we missed the fact that we may have auto-resize before the
fix-up.

> NB: I have ubi attached with --vid-hdr-offset of 2048 because of the
> subpage writing limitations of davinci-nand.

Which means your driver may be incorrect - it should report that it does
not support sub-pages - does it do this? Then UBI will not even try to
use sub-pages and you won't need that option.

--

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
(Continue reading)

Permalink | Reply | 1 comment |

Gmane