于 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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
