[PATCH 0/5] Enable Qi / avoiding re-introducing "hidden variable"

[Andy Green]

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

Somebody in the thread at some point said:
| Andy Green wrote:
|> On the one hand it can be useful to control the commandline -- although
|> it isn't actually generally useful for production device.
|
| Well, many of our users are developers or technophile enough that
| they wouldn't be afraid of adding, say, an option that changes the
| kernel's log buffer, or some of the other command line options we
| introduce along the way.

The fact they aren't afraid of it isn't really telling us it is
"generally useful for production device" though.

|> If we can hold on to this situation where there is no persistent state
|> at all in the bootloader world except its own patchlevel,
|
| Now I'm confused. I'm proposing to make it externally settable,
| e.g., with a file in /boot when booting from SD. Right now, that
| command line is hard-coded into qi, which seems to be the worst
| kind of persistent state.

No the point is that "no persistent state at all in the bootloader world
expect its own patchlevel".  So if we nuke in Qi v 123, we always get
the same behaviour from the device from bootloader side.  It leaves open
different kernels and so on, but we can nuke them too and then our
situation is deterministic.

| For NAND, the equivalent would be a well-known location there the
| command line is/can be placed, i.e., another one of our new-style
| NAND partitions. Again, qi only needs to know that basic layout,
| which it already has to for the kernel, without being concerned
| what is exactly in that command line or how it gets set.

Obviously there is no technical difficulty to do it for NAND or SD.  I
am trying to avoid the whole class of behaviour-changing variable hidden
in the device though.  I saw several GTA02 A5 and A6 come from different
stages of factory firmwares with different environments that meant
different bootloader results even after I DFU'd in a new bootloader.
That's not what we need to shoot ourselves in the foot with if it can be
avoided.  Having got it this far, I think it can be avoided, at least
until I heard a story about some critical need for control of kernel
commandline that really can't be avoided or synthesized in bootloader
(like canned rootfs partition based on boot device).

| Cool ! We can probably move most of the GPIO settings as well.

Is there any benefit to that?  We have to touch enough GPIO registers to
get the bits we do need working we might as well just set them.

I remembered after the coffee sank in we also need to do something about
the 100mA USB / dead battery situation.  That situation is imperfect
anyway in U-Boot, since we enumerate, destroy device side, re-enumerate
(or not) but either way we pull > 100mA during Linux boot then.

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

iEYEARECAAYFAkiuk0MACgkQOjLpvpq7dMqVQQCdEEmPvdWaIqWyl29PdZum8/EF
tOsAoJO0BRJMM0ZUoBK8Jvx+2X+Tpqm/
=+U10
-----END PGP SIGNATURE-----