One of the things I’ll need to accomplish is to put the BBAI64 into a low power mode, but wake it back up in a state similar to how it went to sleep, and preferably wake much faster than a complete reboot would. From the J721E TRM, these are the various powermodes supported by the chip:
I honestly don’t know which one is what I really want/need. My intention is to get as low of a power-signature from the device as possible, while still maintaining the minimal amount necessary to quickly restore the device to the active state it was in prior to entering sleep.
Reading through the descriptions of each, it’s not really clear what the consequences to each are. For instance, if the chip is put into a DeepSleep state, when being reactivated, will Linux have to be rebooted? Or can Linux (and any applications launched) resume where they were? What about SuspendToRAM?
Since I don’t know what mode is most appropriate yet, from here on, my use of the word “suspend” is in the generic sense, not in reference to a specific power state as shown above in Fig 5-26.
It doesn’t take too much imagination to guess that a pin from the WKUP domain is required. I didn’t find any pins on P8 or P9 that are in this domain, however the UART0 pins on the tiny white connector labelled J2 along the edge of the BBAI64 are from this domain. Since I don’t need that UART, I’m fine commandeering one of its pins as a wakeup trigger. Out of lack of any other knowledge, I chose WKUP_UART_RXD (J29) and mapped it as a GPIO pin in my Sysconfig.
The plan is to be able to send a voltage into that pin and have the system come out of sleep and return to full function, no different than a computer would being woken from a sleep-state.
So given my desire, my questions are probably going to be self-evident to someone that can see where I’m going with this. But here are the questions I know to ask at this point:
-
Is my approach on point or are there some caveats and details that I’m obviously not aware of that are going to require I alter my approach?
-
Assuming this approach is possible, what else other than mapping the pin as a GPIO pin is necessary to trigger a wake-up behavior? I don’t know if it needs to be mapped in the DTB as an interrupt or if there’s some other more-specific incantation required.
-
What command from Linux puts the BBAI64 into suspend?
I don’t know if it is related, but I did find a file named k3-j721e-mcu-wakeup.dtsi. Looking through it, there’s a number of entries that seem like they MIGHT be necessary? But then there’s a lot more that seem unrelated to my intentions. So I don’t know if this file is a source for pillaging pieces or if it is a distraction that isn’t going to really be helpful.
So any details as to what it might take to accomplish this goal would be useful.
Edit:
Looking deeper into the TRM, I find this:
The only state that shows it is transitioned away from due to GPIO is DeepSleep.
As I read further, Stand-by technically can also but that’s only because Stand-by is not a very low power mode. Everything is powered and remains running, just at a lower speed hence any GPIO pin could be used to trigger the system out of this mode, not just a WKUP pin. And while this is a lower-power mode compared to active, my guess is its power draw is still going to be significantly higher than a car battery could tolerate for long periods of inactivity. Ideally, a draw of no more than 25mA would be preferred. My guess is this mode would be a few hundred mA at the lowest.
