On 04.05.2012 18:00, Juergen Beisert wrote:
> Alexey Galakhov wrote:
>> On 04.05.2012 17:13, Juergen Beisert wrote:
>>> AFAIR the MLC ECC generator is different in its handling. At least it is
>>> much slower than the 1 bit ECC generator and so the routines must wait
>>> the result to continue on the block data.
>>
>> Correct.
>>
>> This is achieved by adding register polling loop at the beginning of
>> corresponding calculate() function. The rest of function is almost the
>> same, just the number of ECC bytes is larger.
>>
>> The S3C2440 has a hardware ECC corrector which we do not use yet.
>
> AFAIK only a hardware ECC _calculator_, but no correction unit. It must be
> done in software.
At least S5PV210 has a correction unit. If you provide correct ECC to
the unit (write into NFxECCDx), you may then read back the exact byte
and bit position of the error from NFESTAT.
S3C2440 seems to have something very similar. At least it has bits with
same names in NFESTAT. Its usage is not documented in my copy of
datasheet, perhaps in some appnote?
The "s3c_nand.c" driver does like that, even for 2440:
nfmeccdata0 = (read_ecc[1] << 16) | read_ecc[0];
nfmeccdata1 = (read_ecc[3] << 16) | read_ecc[2];
writel(nfmeccdata0, regs + S3C_NFMECCDATA0);
writel(nfmeccdata1, regs + S3C_NFMECCDATA1);
nfestat0 = readl(regs + S3C_NFMECCERR0);
err_type = nfestat0 & 0x3;
and then (if err_type == 1):
dat[(nfestat0 >> 7) & 0x7ff] ^= (1 << ((nfestat0 >> 4) & 0x7));
The MLC case is very similar. The only exception is that there is no
write-back of ECC values, instead one should READ the corresponding part
of OOB immediately after reading the data.
_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
