[PATCH] mtd: nand: Use the mirror BBT descriptor when reading its version

[Artem Bityutskiy]

Let's probe Mike and Robert and see what they say.

On Tue, 2012-06-12 at 17:42 -0700, Brian Norris wrote:
> On Tue, Jun 12, 2012 at 3:42 AM, Artem Bityutskiy <dedekind1 at gmail.com> wrote:
> > On Sun, 2012-06-10 at 22:59 -0700, Brian Norris wrote:
> >> On Sun, Jun 10, 2012 at 3:58 AM, Shmulik Ladkani
> >> <shmulik.ladkani at gmail.com> wrote:
> >> > - Not runtime tested.
> >>
> >> Patch looks fine, but this makes me curious: does anyone use
> >> NAND_BBT_ABSPAGE? It looked broken to me when I tried it not too long
> >> ago, but I didn't look too deeply. (I doubt that this typo was its
> >> only problem, but I may try again...)
> >
> > Looks like this is used in diskonchip.c.
> 
> Hmm, OK. This driver seems to be very stale (very few real
> fixes/improvements in git history). Anyone know if diskonchip.c even
> works with the current BBT code?
> 
> I retried NAND_BBT_ABSPAGE on my own driver, and it seems that this
> code-path has no ability to *create* a bad block table where one
> didn't exist previously. It simply reads whatever data is present at
> the given page(s) (according to td->pages[]), regardless of ECC
> errors, junk data, lack of BBT markers (i.e., "Bbt0" or "1tbB"), and
> versioning.
> 
> So when I use NAND_BBT_ABSPAGE with an erased block at page 1024, I
> get the following:
> 
>    Bad block table at page 1024, version 0xFF
> 
> And no blocks are detected bad (simply because there was 0xff "table
> data"). But then, I get even worse results if the uninitialized BBT
> block has arbitrary (non-0xff) data! nand_bbt would just mark random
> blocks as bad...
> 
> So, this "feature" seems severely limited - designed for a somewhat
> static, pre-initialized BBT. I can probably survive by continuing to
> ignore this eyesore, but I'd rather just fix it or kill it.
> 
> Brian

-- 
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20120618/56a59889/attachment.sig>