-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said:
| The "0x00000000" is printouts of GSTATUS4 which I added - and as you can see | this is 0 all the way. So I think the problem is something else. Any clues? | 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 wake up | 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. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiivE8ACgkQOjLpvpq7dMqEkwCfb3Pot7Mf+8/xy05KExZc1MoP hYwAn0OfytrS9cLUje8msAJ8mEoIFC16 =tqCP -----END PGP SIGNATURE-----
