andy at openmoko.com
Wed Aug 13 12:49:51 CEST 2008
-----BEGIN PGP SIGNED MESSAGE-----
Somebody in the thread at some point said:
| The "0x00000000" is printouts of GSTATUS4 which I added - and as you
| this is 0 all the way. So I think the problem is something else. Any
| Apparently it works well for the modem.
Try enabling interrupt for the other motion sensor. There are two EINT
interrupts coming one from each, but one is handled by an EINT in 0..3
range, these are managed separately from EINT 4..15. There can be a
problem in reporting for this in U-Boot maybe.
I would say "update your U-Boot" but I recall you showed an 0x200 result
from there a few days ago.
| I'm also not sure how the resume process really works, does the board
| in U-boot first?
Yes, resume is actually pretty much a cold reset since the CPU core
power has been gone. The main difference is that IO power was kept up
so the GPIOs stayed up, and GSTATUS* hold data.
U-boot gets run but early on while still in the assembly init part it
detects it is in resume and aborts normal processing, it instead jumps
right into the address kept in GSTATUS3, left there by the kernel. That
is the magic address to start resume actions, etc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the openmoko-kernel