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

Brian Norris computersforpeace at gmail.com
Tue Jun 12 20:42:00 EDT 2012


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



More information about the linux-mtd mailing list