nanddump badblock options

[Brian Norris]

On Mon, Jun 20, 2011 at 12:22 PM, Mike Frysinger <vapier.adi at gmail.com> wrote:
>> -----------------------------------------------------------------------------------------------------------------
>>  Old option         New option                   Comment
>> -----------------------------------------------------------------------------------------------------------------
>>  <default>     =>   --bb=padbad                  dump flash data, substituting 0xFF for any bad blocks
>
> maybe add a pad option so people can specify the data rather than just
> 0xff ?  although that's probably just overkill and no one would
> actually use it ...

Hmm, I'm thinking that'd be a little bit of overkill.

>>  --noskipbad   =>   --bb=dumpbad                 dump flash data, including any bad blocks
>>  --skipbad     =>   --bb=skipbad, <default>      dump good data, completely skipping any bad blocks (new default)
>>  --omitbad     =>   --bb=omitbad                 (dump flash data, substituting nothing for any bad blocks?)
>
> i think omitbad is covered by the other options.

omitbad isn't *exactly* covered by the other options, but it is very
close to the same as skipbad (recall the conversation when I
introduced --skipbad a couple of weeks ago). The only difference is
that omitbad ensures you dump data only from a specified "address
range", perhaps at the expense of the correct dump length, while
skipbad ensures the correct dump length, continuing past the
"specified range" if bad blocks are found.

I'm all for killing omitbad though, so I'll just respin my patch set
and send out v2...

> the one i'm really
> concerned in keeping is --bb=dumpbad for cases where the bbt says it's
> bad, but it isnt really, so i want the data unmolested.

Sure, that makes sense.

Also, I haven't heard any comments on my idea of changing the default
OOB options, where nanddump should NOT, by default, dump OOB data
(like nandwrite, which does NOT write OOB by default). I'm thinking we
could change the default here and add an option to force it to include
OOB:

--omitoob : do not dump OOB
--oob : dump OOB

So for the next release, I would implement the new --oob flag and add
appropriate warnings, and then following the release, we could change
the default. This leaves the question of the short option, -o, since
its current meaning (--omitoob) conflicts with the -o usage in
nandwrite (--oob). I'm thinking either:
1) Change -o so that it means "--oob" to match nandwrite (i.e.,
include OOB in dump)
2) Kill the short option -o entirely, since it's too confusing to
change it over to the nandwrite-compatible form.

This is mostly just a question of what is least confusing to the
mtd-utils user community; I can adapt to my own code changes!

Brian