[RFC] S3C24xx: Fixing the NAND handling

[RFC] S3C24xx: Fixing the NAND handling

[Juergen Beisert]

Hi,

anyone here with an idea how to fix this:

The NAND support for the S3C24xx CPU seems totally broken in the current 
kernel:

 - the driver's local OOB layout for small page NANDs overwrites the vendors
   bad block marker (a really bad idea!)
 - the ECC setup for large page NANDs violates NANDs partial write count (it
   forces 8 partial writes instead of allowed 4 per 2048 byte page)

How to adapt barebox according to the kernel? If we do OOB and ECC setup 
correctly in barebox, the mainline kernel cannot work with this data. If we 
do it in the same way than the kernel, we lose the bad block markers or do 
more writes than the manufacturer allows for reliable data security.

Changing the kernel is also hard to do, because it breaks existing software 
installations which should just run with more recent kernels.

jbe

-- 
Pengutronix e.K.                              | Juergen Beisert             |
Linux Solutions for Science and Industry      | Phone: +49-8766-939 228     |
Vertretung Sued/Muenchen, Germany             | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686              | http://www.pengutronix.de/  |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [RFC] S3C24xx: Fixing the NAND handling

[Zoltán Kócsi]

On Mon, 7 Mar 2011 14:24:13 +0100
Juergen Beisert <jbe@pengutronix.de> wrote:


>  - the driver's local OOB layout for small page NANDs overwrites the
> vendors bad block marker (a really bad idea!)
>  - the ECC setup for large page NANDs violates NANDs partial write
> count (it forces 8 partial writes instead of allowed 4 per 2048 byte
> page)
> 
> How to adapt barebox according to the kernel? If we do OOB and ECC
> setup correctly in barebox, the mainline kernel cannot work with this
> data. If we do it in the same way than the kernel, we lose the bad
> block markers or do more writes than the manufacturer allows for
> reliable data security.
> 
> Changing the kernel is also hard to do, because it breaks existing
> software installations which should just run with more recent kernels.

I believe that kernel has to be fixed. If it is broken and violates the
chip manufacturer's speifications, then you can't (or shouldn't) use it
on the field anyway. In that case you have to accept that upgrading the
kernel will mean that you also have to rewrite whatever code you have
which depends on the *incorrect* treatment of the hardware. 

Prolonging the existence of mistreatment of hardware in the name of
backward compatibility is not a good thing, I believe.

Zoltan

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [RFC] S3C24xx: Fixing the NAND handling

[Jean-Christophe PLAGNIOL-VILLARD]

On 13:08 Tue 08 Mar     , Zoltán Kócsi wrote:
> On Mon, 7 Mar 2011 14:24:13 +0100
> Juergen Beisert <jbe@pengutronix.de> wrote:
> 
> 
> >  - the driver's local OOB layout for small page NANDs overwrites the
> > vendors bad block marker (a really bad idea!)
> >  - the ECC setup for large page NANDs violates NANDs partial write
> > count (it forces 8 partial writes instead of allowed 4 per 2048 byte
> > page)
> > 
> > How to adapt barebox according to the kernel? If we do OOB and ECC
> > setup correctly in barebox, the mainline kernel cannot work with this
> > data. If we do it in the same way than the kernel, we lose the bad
> > block markers or do more writes than the manufacturer allows for
> > reliable data security.
> > 
> > Changing the kernel is also hard to do, because it breaks existing
> > software installations which should just run with more recent kernels.
> 
> I believe that kernel has to be fixed. If it is broken and violates the
> chip manufacturer's speifications, then you can't (or shouldn't) use it
> on the field anyway. In that case you have to accept that upgrading the
> kernel will mean that you also have to rewrite whatever code you have
> which depends on the *incorrect* treatment of the hardware. 
> 
> Prolonging the existence of mistreatment of hardware in the name of
> backward compatibility is not a good thing, I believe.
I agree but you may have device on the market that use it and depond on it to
boot as you can not change the bootloader so you do need to detect it

or make the old way optionnal at least and use the correct one as default

Best Regards,
J.

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [RFC] S3C24xx: Fixing the NAND handling

[Juergen Beisert]

Hi,

sorry for the noise, but:

Juergen Beisert wrote:
> The NAND support for the S3C24xx CPU seems totally broken in the current
> kernel:

No, it isn't.

>  - the driver's local OOB layout for small page NANDs overwrites the
> vendors bad block marker (a really bad idea!)

It does not. I mixed it up with large page NANDs. :-(

>  - the ECC setup for large page NANDs violates NANDs partial write count
> (it forces 8 partial writes instead of allowed 4 per 2048 byte page)

It does not. The MTD framework writes the data in 8 pieces in this case. But 
from the NANDs point of view it is a single write only.

So, no need to fix anything in the kernel. Maybe only in my brain....

jbe

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox