mtd nand erase and bad block

Angus CLARK angus.clark at st.com
Mon Jul 2 03:14:38 EDT 2012


Hi Artem,

On 06/29/2012 11:31 AM, Artem Bityutskiy wrote:
> On Wed, 2012-06-27 at 13:37 +0100, Angus CLARK wrote:
>> However, for case 2, I just want to force the erase operation so I can wipe the
>> BBTs and return the device as close as possible to its original state.  We could
>> put some logic in the kernel, "if 'MEMBBSCRUB" on BBT blocks, do not
>> update/rewrite BBTs", but I think this "policy" decision would be better handled
>> in userspace.
> 
> Sounds like you need 2 separate ioctls:
> 1. MEMBBSCRUB

There are occasions when it is useful to unmark a bad block, but without erasing
first.  Therefore, I guess my preference would be to split this further:
'erase-bad-block' and 'mark-block-as-good'.

> 2. MEMBBTWIPE
> 

This could be a useful addition, since it avoids the need for the user to
calculate the offsets for the BBT blocks.

However, I just have a slight concern about adding the now three new ioctls for
what is essentially development and debugging purposes.  (Indeed, we would
probably want a way of disabling these features for production systems.)

Support for 'erase-bad-block' requires minimal updates, and this one ioctl can
be used to achieve the functionality of the other two, albeit with a little
expert knowledge!  Support for 'mark-block-as-good' and 'wipe-bbts' ioctls would
require more extensive updates (in particular, to nand_bbt.c which has been
updated heavily since the kernel version I have available for testing!).

I would probably edge towards adding just the 'erase-bad-block' option, although
I except my judgement might be slightly biased here, since I have been using a
variant of this for a year or so.  I am happy to implement either approach, but
I would be interested to learn others' views first.

Cheers,

Angus



More information about the linux-mtd mailing list