[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:

|> runs it with a suitable kernel commandline
|
| How about loading the command line from the file system as well
| (with a hard-coded fallback default) ?

On the one hand it can be useful to control the commandline -- although
it isn't actually generally useful for production device.  On the other
hand, there is a class of issue coming out of U-Boot environment way
that you can have two identical devices with identical firmware and they
act different.  That is definitely not good for us.

If we can hold on to this situation where there is no persistent state
at all in the bootloader world except its own patchlevel, (currently not
even any external modality in it either) it has advantages... whether we
will be able to hold on to that I dunno, but I plan to try.  So it means
we need a convincing story about why we need to re-introduce "hidden
variable" concept before we do that.

|> (To enable multiboot, we can additionally scan for partition with
|> boot flag if that's what people want.)
|
| It would add convenience if we were able to switch between two
| kernels without having to rely on external help or having to pop
| cards. But we can add this later.
|
| Wonderful. When do we deprecate u-boot completely ? ;-)

We have to do some small meddlings in the kernel world now to adapt to
the absence of PMU init and so on.  But really those meddlings are a lot
more contained than I imagined, kernel and rootfs comes up already fine
and only charging is likely broken, it's a few lines.

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

iEYEARECAAYFAkiuggYACgkQOjLpvpq7dMrZSACeOJy9eLZMqpx/vfXWFI6IrO0u
4BIAn1LjkvGnXrI0sqWfeb7PkDHEH16w
=1e0a
-----END PGP SIGNATURE-----