[RFC 0/5] fix data+OOB writes, add ioctl

Ricard Wanderlof ricard.wanderlof at axis.com
Thu Aug 25 05:33:10 EDT 2011


On Wed, 24 Aug 2011, Brian Norris wrote:

> On Wed, Aug 24, 2011 at 8:36 AM, Ricard Wanderlof
> <ricard.wanderlof at axis.com> wrote:
> ...
>> I had a problem
>> in that in the mtdchar.c I have it looks like this:
>
> Did you mean nand_base.c?

Yes, sorry about that.

>> whereas your patch looks like it was made against a version which lacks the
>> memsets. First I thought it was because I was running an older kernel
>> ...
> My patches were based on l2-mtd-2.6.git, actually. David Woodhouse
> rarely pulls patches into his mtd-2.6 tree, so I have moved to working
> with Artem's l2-mtd-2.6 tree, where all the MTD work that's waiting
> for upstream sits (some stuff's been there since May). This is not
> obvious, and usually when it matters, I try to mention it in the patch
> summaries.

I guess I should have thought of it but never thought to look there.

> Anyway, I believe the relevant patch dependency (from l2-mtd-2.6.git) is:
>
>   commit a8ee364bbf14861d5d0af39c4da06c30441895fb
>   Author: THOMSON, Adam (Adam) <adam.thomson at alcatel-lucent.com>
>   mtd: nand_base: always initialise oob_poi before writing OOB data

That seems right.

>> Nevertheless, after applying the patch, as you suspected, using 'nandwrite
>> -o -n' fails, in this case the application hangs after outputting
>>
>> Writing data to block 0
>
> I guessed you would be more likely to get a segmentation fault on a
> NULL pointer, but I may be wrong.

Something seems to hang at a lower level, because the system becomes 
unresponsive at this point (I can telnet in, but trying to access the 
flash with ls for instance causes the shell to hang).

> If you're still up for trying, you can try applying Adam Thomson's
> patch, then my RFC, then the inlined amendment I sent. With your
> feedback, I will

(something seems missing here ... nevertheless)

I applied the patches as you mentioned, which brought success. Dumping a 
partition with nanddump, then writing it back with nandwrite -o -n results 
in the correct data being written both to the main and oob areas.

(Without your inlinend patch, the nandwrite application still hangs after 
Writing to data block 0).

So the conclusion would be that this combination of patches does not break 
Peter Wippich's patch.

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30



More information about the linux-mtd mailing list