[PATCH] qi: initialize / policy for reset and IO bringup

Andy Green andy at openmoko.com
Sun Jan 25 13:55:48 CET 2009


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

Somebody in the thread at some point said:
| Andy Green wrote:
|> I think it's simpler (certainly less wordy :-) ) if I just explain what
|> our hardware -> bootloader -> kernel design policy should be.
|
| This is a good design policy for new hardware. However, there are two
| holes:
|
| - the imperfections of existing hardware, i.e., GTA02, and
|
| - the PMU won't do us the favour of being in a nicely defined
|   state after CPU reset.
|
| So we still need to solve this initialization problem, even if we can
| reduce its scope in future hardware.

Agreed, but it guides us with how to come at that too since it tells us
what the right way looks like.  For example mass GPIO resetting in
kernel idea is incompatible with this path.

PMU is actually largely in a defined state at CPU reset, there are just
a handful of registers depending on NOPOWER (only: the other reset state
for some regs is PMU standby which we know we entered)... all we can do
about that is set them in bootloader which we can for Qi or U-Boot.
Same for the odd wrong level GPIO, we have to workaround in bootloader.
~ That doesn't undermine anything else.

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

iEYEARECAAYFAkl8YVQACgkQOjLpvpq7dMrXZwCgjh1omH29A1NOJ8BoyoXDC5HU
vY0AnjxbMyRxtDvkwKR6DmNkFNcEqrHZ
=NAuC
-----END PGP SIGNATURE-----



More information about the openmoko-kernel mailing list