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