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. > >> I suggest to support both new and old hardware in the same code. Why > >> not? It is 95% the same. > > > > Instead of making the S3c2440 NAND driver more and more complicated (what > > is the benefit of all in one driver?) I would vote for fading it out (as > > its hardware do not change anymore). And creating a new driver for all > > more recent CPUs with MLC support. > > > > My idea was also to not support simple ECC on these newer CPUs anymore. > > Using the 8 bit reed-solomon checksum would be an improvement for SLCs as > > well (and also their OOB sizes are large enough to store the 8 bit > > checksums). And at least if we want to boot from NAND we cannot continue > > to use simple ECC checksums anymore. > > Maybe that's right. But simple ECC support is very simple anyway, > harmless to keep. Or _useless_ to keep ;) > And looks like some low-cost Chinese boards still have SLC even with newer > CPUs. The better the checksum the saver your NAND data content is. That is why I want to use reed-solomon checksums even for SLCs (and keep in mind: you _must_ use 8 bit reed-solomon checksums if you want to boot from NAND). > [...] > BTW, do we want software ECC support too? No. Nobody needs it and nobody wants it (ways to slow). jbe -- Pengutronix e.K. | Juergen Beisert | Linux Solutions for Science and Industry | http://www.pengutronix.de/ | _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
