this week work on KBOOT

[Andy Green]

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

Somebody in the thread at some point said:

Hey Werner, hope your hols were fun.

| Seems that I got back just at the right time ;-)
|
| Changing the partitioning architecture and replacing u-boot with kboot
| are two separate issues, so I don't quite see the need to view this as
| an "either/or" question.

Right, it's a "what first" question for xiangfu.

| Switching to kboot reduces the cost of maintaining the status quo in
| the long run by avoiding the effort for keeping u-boot running (which
| should be small at the moment if we freeze our version), and by
| eliminating the need to port new functionality we will need in future
| products. Of course, the sooner we get this done, the less time we have
| to sink into u-boot.

Well that's really the difference, I think backup kernel + rootfs will
fill in for kboot OK.  But, nothing wrong with kboot if it magically
exists.  It just seems we get teleported to a better win by reducing the
bootloader to the minimum first.  Hey if two people are on it by all
means do both.

| Regarding the dynamic partitions, the actual technical implementation
| is almost trivial, but I'd like to verify that my math and my
| assumptions about bad block patterns are indeed correct. If our GTA02
| production logs now include the bad block information, that would tell
| us if my model for bad block distribution is close enough to reality.
| Otherwise, we have to get a bit more creative :)
|
| Andy, are you also considering to get rid of the bad block table, or
| just the evil dynamic partitions ?

We have to differentiate between possible GTA01/02 reformat and GTA03
usage.  All I am worrying about is GTA03.

The dynamic partitions are truly insane so I think we have to use your
"fixed worst case offset plan", even if the worst case is bad.  Or if
the real worst case is an outlier, accept 0.05% dead devices.

On GTA03 we are in a neat position that Linux does not have to support
NAND.  The bootloader alone can be responsible for write and read of
NAND, and the backup rootfs can be an initrd (yeah I know, but not
having to deal with NAND in Linux makes it fine).  We can update NAND by
bootloader finding a CRC-protected update file on SD Card.

So for GTA03, yes I think we could throw out the bad block table.  If we
were to retrofit this on GTA01/02 with NAND rootfs I dunno (and I dunno
we should bother unless we assert the same GTA03 principle then about SD
Card rootfs).

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

iEYEARECAAYFAkhEGKAACgkQOjLpvpq7dMpSFwCfd23W83JclnUhqd/OmxshPaW7
03IAoIzQY8sMOMtE6w83yTf/CFU2cYUz
=fHm9
-----END PGP SIGNATURE-----