[PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip

[LiuShuo]

于 2011年08月23日 16:14, Matthieu CASTET 写道:
> LiuShuo a écrit :
>> 于 2011年08月23日 00:19, Scott Wood 写道:
>>> On 08/22/2011 11:13 AM, Matthieu CASTET wrote:
>>>> Scott Wood a écrit :
>>>>> To eliminate it we'd need to do an extra data transfer without reissuing
>>>>> the command, which Shuo was unable to get to work.
>>>>>
>>>> That's weird because our controller seems quite flexible [1].
>>>>
>>>> Something like that should work ?
>>>>
>>>>               out_be32(&lbc->fir,
>>>>                        (FIR_OP_CM2<<   FIR_OP0_SHIFT) |
>>>>                        (FIR_OP_CA<<   FIR_OP1_SHIFT) |
>>>>                        (FIR_OP_PA<<   FIR_OP2_SHIFT) |
>>>>                        (FIR_OP_WB<<   FIR_OP3_SHIFT));
>>>> refill FCM buffer with next 2k data
>>>>
>>>>               out_be32(&lbc->fir,
>>>>                        (FIR_OP_WB<<   FIR_OP3_SHIFT) |
>>>>                        (FIR_OP_CM3<<   FIR_OP4_SHIFT) |
>>>>                        (FIR_OP_CW1<<   FIR_OP5_SHIFT) |
>>>>                        (FIR_OP_RS<<   FIR_OP6_SHIFT));
>>> Something like that is what I originally suggested, but Shuo said it
>>> didn't work (even in theory, it requires a CE-don't-care NAND chip,
>>> since bus atomicity is broken).
>>>
>>> Shuo, what specifically did you try, and what did you see happen?
>>>
>>> -Scott
>> First, if we want to read 4K data with once command issuing, we can't
>> use HW_ECC.
> Yes, but as ivan said doesn't the cost of 2 read isn't bigger than software ecc ?
>
>> Even if we use SW_ECC, we always get lots of weird '0xFF's between 1st
>> 2k and 2nd 2k data.
> Did you understand where those 0xff comes (what's the size of them. Doesn't the
> controller try to insert spare aera ?)
I don't understand. I set FBCR to 2048, the controller will read the 
main area without spare area.
But the size of them is nearly spare area size( more or less a few bytes).
I can't guess the behavior of the controller then, so I select another way.

Could you try to do it and explain how those 0xff comes ?
> Could you detail the sequence you used ?
>
First half :
                   out_be32(&lbc->fbcr, 2048);
                   out_be32(&lbc->fir,
                            (FIR_OP_CM0 << FIR_OP0_SHIFT) |
                            (FIR_OP_CA << FIR_OP1_SHIFT) |
                            (FIR_OP_PA << FIR_OP2_SHIFT) |
                            (FIR_OP_CM1 << FIR_OP3_SHIFT) |
                            (FIR_OP_RBW << FIR_OP4_SHIFT));


Sencond half :
                 out_be32(&lbc->fbcr, 2048);
                 out_be32(&lbc->fir,
                            (FIR_OP_RB << FIR_OP0_SHIFT) |
                            (FIR_OP_RBW << FIR_OP1_SHIFT));


-Liu Shuo

> Matthieu
>
>