[PATCH 0/8] Qi solve GTA02 dynparts compatability and parse idenity partition

[Andy Green]

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

Somebody in the thread at some point said:

| So the partitions from Qi and u-boot will agree even though they're
| using different methods for obtaining this information.

Ie, no problem.

|> Similarly you assume any other partition contents can just absorb the
|> loss of one or more 128KBytes and I'm not sure that's going to be so
|> going on, eg, kernel part + backup / menu rootfs.
|
| Yes, the whole logic of having a guaranteed number of good blocks
| falls apart when a block wears out. One more reason why dynamic
| partitions are bad.

Agreed, but in GTA02 context due to NOR U-Boot still needing to allow
compatible unbricking, we cannot move off it (and now support it in Qi
anyway).  So this is a done deal for today, but we never use it again.

|> erase cycles with ECC (which we don't use in Qi), compared to 100K erase
|> / write endurance for any cell.
|
| Hmm yes, we really should do the ECC. There's no telling how few
| cycles you really get without it ...

Considering SD boot works fine with Qi the only truly critical block is
only erase block +0 containing Qi -- 8K of that block is always read at
boot without ECC anyway AFAIK.  So we're talking about protecting 2/3rds
of the bootloader with ECC... I think it's acceptable risk until someone
shows failure from this, not to mention the ECC support itself will
increase the size of bootloader and risk of bit error.

Updating bootloader is quite uncommon for bulk of users, we have worse
things to worry about.

|> It illustrates raw NAND is evil and flaky as told many times here.
|
| We better keep up the indoctrination so that people don't get ideas
| about using all that precious NAND laying vacant in GTA03 ;-)

People will get ideas there's not much that can be done about it.

But this should get the priority from us it deserves.  The only business
we have with GTA03 NAND is the "identity" partition has to go in there,
so we have to have only minimal support to read and write it in Linux
and maybe read it in Qi.

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

iEYEARECAAYFAkmJas4ACgkQOjLpvpq7dMqEzACffNRoT94jbDZucxoK16qp1Rox
m5UAmgNoF8m8vWcJGoTUQdoB7phhqioG
=uph5
-----END PGP SIGNATURE-----