Hello *,
On 02/07/2016 12:34 PM, Ian Campbell wrote:
> So far I see no evidence for the claim that flashcp should not be used
> for writing to NAND devices in either its --help or its source (it has
> no man page AFAICS).
>
> Having a tool in Debian called "flashcp" which can (according to this
> report, I haven't checked this myself) destroy some classes of flash
> device with no warning is a clear problem irrespective of flash
> -kernel's use of that tool.
>
> At the very least flashcp should either abort when used on NAND devices
> or should be renamed norwrite (cf. nandwrite) but ideally it would Just
> Work properly when used on a nand device.
"Work properly" might not be well defined here. If flashcp should be
taught to write to nand, how should it behave? Like nandwrite with -p?
What about -m? Probably without -o.
I would guess that renaming flashcp to (say) norwrite isn't an option
for upstream. I think the naming was coined before nand flash was widely
adopted. So I still think the best thing to do here is to teach
flash-kernel about nand chips and let it use nandwrite then. Adding a
note to flashcp -h that it is only supposed to work on nor and let it
fail for nand also sounds right.
> mtd-utils maintainer(s), please let me know if this is either wontfix
> or if the fix is going to take some time, in either case I will
> workaround flashcp in flash-kernel (either permanently or temporarily
> respectively).
>
> I suppose it is also possible that this is a bug in the underlying
> /dev/mtdN and/or mtdblockN device or in the h/w specific driver at the
> bottom of the stack?
No, mtdblockN exposes bad blocks by design:
http://linux-kernel.2935.n7.nabble.com/PATCH-Make-the-mtdblock-read-write-skip-the-bad-nand-sector-td756524.html
Best regards
Uwe
