Status NAND Hardware ECC

[Andy Green]

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

Somebody in the thread at some point said:
| 2009/2/11 Andy Green <andy at openmoko.com>:
|> Sounds good, what's the upstream way?
|
| The upstream way is to use the kernel option
| CONFIG_MTD_NAND_S3C2410_HWECC. That way we need to know if hardware
| ECC is available at compile time, which should be very hard for the
| packaging guys. The hard way would be to provide two kernel versions,
| one for the NANDs flashed with the old dfu-utils and one for the
| not-yet-available-new-dfu-util (???). ;-) This would however in the
| longrun either force the people to reflash their phone (note one could
| make this depend on the phone-type GTA01: default off, GTA02: default
| on) or force the distros to maintain two kernel builds...

None of that really works for me, "upstream way" or not :-)

| I don't know what to do here, but I like the idea to fallback to
| software ECC if hardware ECC fails. What would be a relyable way to
| detect this?

I was thinking if you get an error off hw ECC, instead of blowing chunks
right away you always try the soft ECC action on the same data and
accept what that says as the actual answer.

After the first block has been processed from a partition, you can set a
flag in RAM to say for that partition you can either skip trying hw ECC
or disallow trying soft ECC, and save the time and power on the one that
you by then know isn't necessary.  Similarly, that flag tells you which
ECC style to write in that partition.

The only other thing we'd need is a way /sys or otherwise to force this
flag for writes in a partition.  That way, you can assert that you will
use hw ECC for example when you are about to nuke a partition that can
previously have been soft ECC.


About the dfu-util thing, maybe what we should say is that if you want
to use hard ECC for a NAND speed boost, you should use Qi.  Qi gets
around the dfu problem because then the only way to write those
partitions is from Linux, which'd have these heuristics.

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

iEYEARECAAYFAkmS1s0ACgkQOjLpvpq7dMrH0gCaAsK+fQR6qdwK5O0FZAQ3YqXF
F+QAmgLG2qtktgrTu/BvYV5/Po7LOBze
=GQET
-----END PGP SIGNATURE-----