nanddump shows all bad blocks

nanddump shows all bad blocks

[Bishop, Mark]

When I do this:
root:/> nanddump  -l 0x20000 -s 0x60000   --bb=padbad -f testfile
/dev/mtd0

It shows that the ECC has failed, but I know there is good data in there
as that I can read the data in uboot.
0x60000-0x7ffff holds my uboot environment.

ECC failed: 429
ECC corrected: 0
Number of bad blocks: 4
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00060000 and ending at 0x00080000...

My 'testfile' is full of 0xFFs as the option specifies (padbad:  dump
flash data, substituting 0xFF for any bad blocks).

I know mtd0 is mapped to that partition:
...
Creating 4 MTD partitions on "MT29F2G08ABAEAWP":
0x000000000000-0x000000080000 : "bootloader(nand)"
0x000000080000-0x000000880000 : "linux kernel(nand)"
0x000000880000-0x000006c80000 : "file system(nand)"
0x000006c80000-0x000010000000 : "file system(ubifs)"
...

Any idea how I can make this work?

Re: nanddump shows all bad blocks

[Peter Barada]

> When I do this:
> root:/> nanddump  -l 0x20000 -s 0x60000   --bb=padbad -f testfile
> /dev/mtd0
>
> It shows that the ECC has failed, but I know there is good data in there
> as that I can read the data in uboot.
> 0x60000-0x7ffff holds my uboot environment.
>
> ECC failed: 429
> ECC corrected: 0
> Number of bad blocks: 4
> Number of bbt blocks: 0
> Block size 131072, page size 2048, OOB size 64
> Dumping data starting at 0x00060000 and ending at 0x00080000...
>
> My 'testfile' is full of 0xFFs as the option specifies (padbad:  dump
> flash data, substituting 0xFF for any bad blocks).
>
> I know mtd0 is mapped to that partition:
> ...
> Creating 4 MTD partitions on "MT29F2G08ABAEAWP":
> 0x000000000000-0x000000080000 : "bootloader(nand)"
> 0x000000080000-0x000000880000 : "linux kernel(nand)"
> 0x000000880000-0x000006c80000 : "file system(nand)"
> 0x000006c80000-0x000010000000 : "file system(ubifs)"
> ...
>
> Any idea how I can make this work?
>
Sounds as if the kernel is using a different ECC method to read the data
than what u-boot used to write it...

-- 
Peter Barada
peter.barada@gmail.com

RE: nanddump shows all bad blocks

[Bishop, Mark]

> Sounds as if the kernel is using a different ECC method to read the
> data
> than what u-boot used to write it...
> 

This has nothing to do with the internal ECC being turned on or off on
the part?

RE: nanddump shows all bad blocks

[Bishop, Mark]

> -----Original Message-----
> From: linux-mtd-bounces@lists.infradead.org [mailto:linux-mtd-
> bounces@lists.infradead.org] On Behalf Of Bishop, Mark
> Sent: Thursday, April 05, 2012 3:39 PM
> To: linux-mtd@lists.infradead.org
> Subject: RE: nanddump shows all bad blocks
> 
> > Sounds as if the kernel is using a different ECC method to read the
> > data
> > than what u-boot used to write it...
> >
> 
> This has nothing to do with the internal ECC being turned on or off on
> the part?
> 

root:/> ./fw_printenv
MTD_open
MTD_ioctl
MTD_ioctl
MTD_read
MTD_close
Warning: Bad CRC, using default environment
bootcmd=bootp; setenv bootargs root=/dev/nfs
nfsroot=${serverip}:${rootpath}
ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm
bootdelay=5
baudrate=115200

Ok, that's what I needed to wake up the brain cells.  However, I really
need 'ethaddr' and it isn't being shown.  

Any idea why it isn't showing the entire environment?

RE: nanddump shows all bad blocks

[Bishop, Mark]

> -----Original Message-----
> From: linux-mtd-bounces@lists.infradead.org [mailto:linux-mtd-
> bounces@lists.infradead.org] On Behalf Of Bishop, Mark
> Sent: Thursday, April 05, 2012 3:39 PM
> To: linux-mtd@lists.infradead.org
> Subject: RE: nanddump shows all bad blocks
> 
> > Sounds as if the kernel is using a different ECC method to read the
> > data
> > than what u-boot used to write it...
> >
> 
> This has nothing to do with the internal ECC being turned on or off on
> the part?
> 


Nevermind.  Problem solved.  Thanks everyone, especially Mike.

Re: nanddump shows all bad blocks

[Mike Frysinger]

On Thu, Apr 5, 2012 at 15:38, Bishop, Mark wrote:
>> Sounds as if the kernel is using a different ECC method to read the
>> data than what u-boot used to write it...
>
> This has nothing to do with the internal ECC being turned on or off on
> the part?

if you're booting off the nand on the bf52x/bf54x, you should enable
CONFIG_BFIN_NFC_BOOTROM_ECC in u-boot and
CONFIG_MTD_NAND_BF5XX_BOOTROM_ECC in the kernel.

if you aren't booting off the nand, you should disable both.

hardware vs software ecc shouldn't matter.  but don't quote me on that :p.

switching between the two modes is easiest by going into u-boot and
running "nand scrub".  obviously that'll erase your nand in the
process, but so it goes ;).
-mike