[PATCH 00/12] Marvell NAND controller rework with ->exec_op()

[Boris Brezillon]

On Wed, 3 Jan 2018 21:10:28 +0100
Boris Brezillon <boris.brezillon at free-electrons.com> wrote:

> On Wed, 03 Jan 2018 20:58:29 +0100
> Robert Jarzmik <robert.jarzmik at free.fr> wrote:
> 
> > Miquel RAYNAL <miquel.raynal at free-electrons.com> writes:
> >   
> > > On Tue, 02 Jan 2018 20:21:09 +0100
> > > Robert Jarzmik <robert.jarzmik at free.fr> wrote:
> > >    
> > >> Miquel RAYNAL <miquel.raynal at free-electrons.com> writes:
> > >>     
> > >> > I think the ECC issue you faced was related to pages being written
> > >> > *and* empty. If this guess is right, the board should boot fine with
> > >> > these changes.
> > >> >
> > >> > Otherwise, please add the DEBUG define as before in both the core
> > >> > and the driver and do not hesitate to add another dump_stack()
> > >> > where it crashes (if applicable).      
> > >> 
> > >> The problem looks still the same :
> > >> [    3.560163] Bad block table not found for chip 0    
> > >
> > > Mmmmh ok.
> > >
> > > Can you please add this patch:
> > > http://code.bulix.org/61at9p-254626    
> > 
> > Well, it looks a bit better, see attached log in [1].
> > Now the BBT is detected ...
> > [    3.310841] Bad block table found at page 131008, version 0x01
> > ...
> > [    3.354944] Bad block table found at page 130944, version 0x01
> > 
> > But all blocks are considered bad ... as if the bit logic was inverted for the
> > meaning of "bad" or "good" block, see :
> > [    3.379825] nand_read_bbt: bad block at 0x000000000000  
> 
> Hm, that's weird. Can you try with the old driver (pxa3xx)?

Alternatively, you can type 'nand bad' from uboot to check if it
detects the same bad blocks.