[PATCH 2/4] Fine split S3C arch dependencies from generic code

Juergen Beisert jbe at pengutronix.de
Fri May 4 05:58:24 EDT 2012

Alexey Galakhov wrote:
> On 03.05.2012 23:41, Juergen Beisert wrote:
> >> create mode 100644 arch/arm/mach-samsung/include/mach/s3c-nand.h
> >> delete mode 100644 arch/arm/mach-samsung/include/mach/s3c24xx-nand.h
> >
> > That is a really bad idea. I just renamed these files at January 2012 to
> > reflect their CPU (refer b29b8f43d56b62e406349a5cf1ed56f17454c1f7). Why
> > do you revert this change again? The NAND controller in the S3C24XX CPU
> > is unique to this CPU. The NAND controller in the S3C6410 differs from
> > it, and I guess the same is true in the S5 CPU. So, the newer CPUs need
> > their own NAND drivers.
> >
> > What is the sense of renaming these files?
> In fact, exactly the opposite is true. The NAND controller in S5PV210 is
> almost exactly the same as in S3C24xx. The only difference is the
> numbering of registers. Also S5P suports 1-bit and 4-bit HW ECC while
> S3C has only 1-bit. 

Does the S5P not support 8 bit ECC? That would be a step backwards and would 
make it useless for recent MLC NAND devices.

> The algorithm is the same, even s3c2440_nand_read_buf() works correctly.

These routines are useless for NANDs of type MLC which are the standard today.

> S3C6410 has the same controller as well.

No it hasn't. Believe me. Using the old 1 bit ECC (and also the 4 bit ECC) 
makes no sense any more. Even the built-in iROM forces the 8 bit ECC mode if 
you want to boot it from NAND. And I guess it is the same on the S5P CPU.


Pengutronix e.K.                              | Juergen Beisert             |
Linux Solutions for Science and Industry      | http://www.pengutronix.de/  |

More information about the barebox mailing list