[PATCH 0/5] Enable Qi / backup rootfs

[Andy Green]

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

Somebody in the thread at some point said:

| In all these cases, you could avoid using a boot parameter. But it's

No problem then.

|> that can't be handled in Qi update.
|
| But you don't want to have to update qi. Eventually, we want to treat
| it like NOR, i.e., not even advanced users should have to update it.
| That way, it can always be relied upon to boot the system.

This is the same debricking vs update argument that can only truly be
answered by USB -> JTAG onboard the phone.  Lacking that, we should
allow Qi update under special user action on GTA03 working through the
nWP system and not lock users out -- although that's a power we have to
take care about alright.  Users with debug board and Jtag can always
override it anyway.  For GTA02, the NOR "backup bootloader" means we can
update Qi how we like.

The nWP lock stuff on GTA03 just means the user gets final control over
when he updates Qi, not that it is not routinely updateable.

|> Can you provide a link to where I made that "clear"?  Should be easy
|> since you state it as a fact.
|
| Heh, I think I can tell by now when we reach the point in a
| discussion where you dig in and will defend that position to
| the knife ;-)

Didn't think I said such a thing.  As I explained contradicting your
report of my opinions, kexec is okay by me, but it is a relatively small
adjunct to having a backup kernel + rootfs rather than a cure for
cancer.  If we use it to push the statefulness of the boot system out of
the bootloader, that's a plus (although then we still need to plan where
the decision to go into the backup filesystem by default is made, and
that decision does occur at the bootloader).

| If you mean "shell and the usual utilities", then I'd agree that
| we shouldn't be too stingy, since they're likely to be very well
| tested and have reasonably low complexity. I'd even throw in a
| very simple GUI, like the Petitboot we've already talked about.

What do we actually need this backup NAND fs for in the context that we
can pop the SD Card and nuke the "system partition" in a PC?  What kind
of functionality do we think about putting in there then?  I guess
failsafe network access is good but it all seems secondary if you have
direct access to the SD Card if surgery is needed.

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

iEYEARECAAYFAkivOgIACgkQOjLpvpq7dMoY6QCfVKIyJnqmzQctj608/8ZSWu7+
rhUAn3t9919Q2OzQaWy3XBdTnu33iwoX
=feG7
-----END PGP SIGNATURE-----