Status NAND Hardware ECC

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| Hello Matt, hello Werner,
|
| I'm aware that hardware ECC is supported in the kernel. My question is
| more, what would be needed to actually use it. From your comments I
| see that the problem is the way our rootfs was flashed. Is this
| correct?
|
| If yes, then are there any plans to "fix" dfu-util to set the ECC
| field in a compatible way?
| What would be a good transition process?
| Is there a bitfield or similar one could set in nand to flag which ECC
| algorithm was used? The kernel could then autodecide if it should
| fallback to the currently used algorithm.

Maybe... another zero state way would be to try the faster hard ECC
first and then try the soft algorithm and accept either match.  It could
be sped up by keeping a per-partition flag in RAM so that after n times
where they were all hard or all soft matches you just mark that whole
partition as hard or soft and only use that syndrome.

| The reason why I'm asking is that our way to decide which ECC to use
| differs from the upstream way and is furthermore redundant to the
| config option in the kernel. I would like to cleanup mach-gta02 a
| bit...

Sounds good, what's the upstream way?

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmSeFEACgkQOjLpvpq7dMqy8wCgjq6/k1ZbTTGIktbjIIKAMiGe
B6oAn3CUIzFGNVJzQbsl5/48UNW9TaY4
=rJsV
-----END PGP SIGNATURE-----