-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said: | Hey, | | I had a look at using hardware ECC for the s3c244x. I'm in a state that I | patched uboot to write a ECC for dfu flashed stuff that the kernel likes to | read it and is happy.
Wah, no wonder you need a drink. Nice work. | What is left: | - Flag day? Provide a upgrade path? | - hardware_ecc=1 into the cmdline and then enable it in the kernel We can recover from this with NOR U-Boot if it has some issue, but that is a bit scary for customers. Likewise U-Boot env changes are scary for customers. We need to confirm "operation is not degraded" and then just transition to it as the default. Particularly in U-Boot, we just need the one way. ~ I think it means sticking these on andy branch with hard ECC enabled for a little while to get comfortable with them, but right now I am blocked with other problems on andy branch and will take these in a day or two. BTW on the A5 I use it continues to pull 8MBytes of NAND when booting from there, I guess it is in its environment, hopefully this got reduced ~ to the 2MBytes actually necessary on shipping devices. | - Check if the ECC is useful at all (have to look at the result of the | hardware register) | - Is the ECC config useful? We have main memory ECC0 and ECC1 but only write | in so small chunks that we fill up ECC0? How does this relate to the 2K page | - I have to learn more about OOB, ECC and NAND. And figure out why we do the | ECC over 256 bytes for LP... | - Find out why it is not twice as fast? | - Wonder why we only have 8-bit flash and if it is matters? That's what Samsung gave us, obviously it impacts performance but equally obviously can't do anything about it. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiMIVkACgkQOjLpvpq7dMrXkwCaA4yFJoXI/ql6Cj/IFVUFNj1Q KtQAn1OlLG4BFyiS0Fj+SU1THWPBNO7F =M4cS -----END PGP SIGNATURE-----
