[PATCH v3 0/7] Marvell NAND controller rework with ->exec_op()

[Miquel Raynal]

Hi Robert,

On Fri, 12 Jan 2018 09:45:01 +0100
Boris Brezillon <boris.brezillon at free-electrons.com> wrote:

> On Fri, 12 Jan 2018 09:09:17 +0100
> Robert Jarzmik <robert.jarzmik at free.fr> wrote:
> 
> > Miquel RAYNAL <miquel.raynal at free-electrons.com> writes:
> > 
> > I begun all your test procedure (on my zylonite board).
> > The timing registers are the same in both pxa3xx_nand and
> > marvell_nand, ie : [    3.085539] Timing registers from Bootloader:
> > [    3.089971] -  NDTR0: 0x00161c1c
> > [    3.095979] -  NDTR1: 0x0f3c00a2
> > 
> > I can attach the dmesg of the first run (dump of OOB). Yet I think
> > you're missing the point as to where the bug lies.  
> 
> We definitely don't know where the bug lies, otherwise we wouldn't do
> the remote debug session we're doing here.
> 
> > 
> > In the zylonite setup, the BBT is _not_ in the OOB of each block.
> > Instead, it lies at the end of the NAND, in the last blocks (see
> > struct nand_bbt_descr). Reading each block and declaring it as bad
> > as is done in marvell_nand (at least that is my understanding of
> > your traces), but it is not what should be done if a match is found
> > for the bbt_pattern. Instead, the BBT should be loaded from the
> > last 8 blocks of the NAND, ie. page 130944 and page 131008 in my
> > setup.  
> 
> The driver is not searching for a BBT because it's explicitly disabled
> in your pdata (if it was enabled we would see something like "Bad
> block table not found ..." or "Bad block table found ..." in the
> logs). And that's anyway not the bug we're trying to fix here. In
> your setup (2k pages with Hamming ECC), the bad block markers, i.e.
> the markers present in each block and used to mark a block good or
> bad (0xffff => good, != 0xffff => bad), should be preserved. So, the
> symptoms we're seeing here, where almost all blocks are reported as
> bad when scanning BBMs, is not expected, and that's what we're trying
> to debug/fix.

Also, the first blocks are (presumably) taken by the Bootloader, having
data there in the OOB is not impossible. Could you please show the same
dumps within the partition where you UBI/EXT setup relies?

> 
> > 
> > Therefore, I would rather think that marvell-nand is not using the
> > BBT at the end of the nand rather than misconfiguring the timing
> > registers.  
> 
> Timing mis-configuration was just a lead we had to follow. It seems
> that it's not the problem here, but we had to test it. Now, the
> missing BBT scan is clearly caused by an explicit config telling the
> driver to ignore the BBT. You can try to enable it if you want to
> test BBT handling (pdata->flash_bbt = 1), but even if that works,
> we'd like to understand why the regular BBM scanning does not work.
> 
> Honestly, it's hard to be sure what you're testing, because we don't
> know whether you're testing the branch Miquel provided or manually
> apply some changes locally. Can you push your local changes somewhere
> (if any)?

Yes, please, can you push a branch with your patches?


As far as I remember, you removed the flash_bbt from the pdata to avoid
smashing the BBT again. Can you test this works with the old driver ?

If the old driver fails without flash_bbt, then you should go back to
the original setup and test again the last modifications.

Thanks,
Miquèl