aux button interrupt to pmu?

Andy Green andy at openmoko.com
Fri Jun 6 12:46:27 CEST 2008


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

Somebody in the thread at some point said:
| Andy Green wrote:
|> In fact there should be limited trouble it can cause since we jump to a
|> wake address in a fixed CPU register that survives suspend,
|
| Yes, but there's still quite a lot of code that gets executed before
| this. What if there are differences in what this one does ? We already
| have a small one, namely the wakeup reason. (The "jump to GSTATUS2" is
| as old as time, so NOR has that one as well.)

GSTATUS3 but OK.

| And it gets worse: even if there's no incompatibility between u-boot in
| NAND and NOR, AUX may very well get deasserted between the time the CPU
| decides whether to execute SteppingStone or not, and the time before we
| jump back into the kernel. In this case, the content of the BootSRAM is
| unpredictable, and we switch right into it for execution.

Sounds pretty bad, even though it would need a bouncy AUX button; but
that's the kind of thing that can and does happen.

| So I think the bug is in that new spec trying to lead us somewhere we
| really don't want to go :)

Well this hardware bug is there anyway, but I guess it matters less if
you crash sometimes on boot into NOR whereas if you are constantly using
AUX for wake a crash is more likely (since the press action provokes the
wake and any bounce at the same time) and more painful.

Still, point taken, with GTA02 hardware as it is wake on AUX is indeed
not going to be reliable if AUX bounced or was not held down long enough.

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

iEYEARECAAYFAkhJFYMACgkQOjLpvpq7dMrjKQCeOYBx6ZE79uokvA74Z8ZbQeCe
5fsAn1Qdocle+Wbc9QnKiIPjQYfCsmA3
=MIQn
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list