imx27: No space left to write bad block table

[Miquel Raynal]

Hi Fabio,

Fabio Estevam <festevam at gmail.com> wrote on Mon, 19 Apr 2021 09:48:20
-0300:

> On Mon, Apr 19, 2021 at 9:41 AM Fabio Estevam <festevam at gmail.com> wrote:
> 
> > This commit landed in linux-next 20210329. I was able to find the
> > kernelci log for this version and NAND is correctly probed:
> > https://storage.kernelci.org/next/master/next-20210329/arm/imx_v4_v5_defconfig/gcc-8/lab-pengutronix/baseline-imx27-phytec-phycard-s-rdk.html
> >
> > The first NAND error starts with 20210330:
> > https://storage.kernelci.org/next/master/next-20210330/arm/imx_v4_v5_defconfig/gcc-8/lab-pengutronix/baseline-imx27-phytec-phycard-s-rdk.html  
> 
> linux-next 20210329 introduced the following logs that were not
> present previously:
> 
> Bad block table written to 0x000007fa0000, version 0x01
> Bad block table written to 0x000007f80000, version 0x01
> 
> Maybe this new 'two Bad block tables' will confuse the subsequent boots?

I am pretty sure now the commit I pointed earlier today is the root
cause (but I don't know why, yet). Somehow it skips the bad block table
which is more or less declared like a bad block from a 'low level'
point of view (so that the user cannot erase/overwrite it). Here,
the kernel does not find the valid BBT. It then creates a new couple of
BBT. But doing so at the next boot, the recently created BBT won't be
detected anymore... until there are no more free blocks reserved for
that and that's where the probe fails.

So yes, the NAND controller driver probes correctly with next-20210329
but in fact the real bad block table is not found and this is the root
cause.

Thanks,
Miquèl