What is required to suspend and wake up a BBAI64?

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:

  1. 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?

  2. 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.

  3. 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.

1 Like

The deafening silence leads me to believe this isn’t a well known area of the BB platform.

1 Like

Maybe asking this question at it’s e2e forum would be better… Also, Linux should have some kind of suspend api or something, maybe they have implemented this for tda4.

I re-posted on the e2e, and after finding a similar post, I don’t have any hope of getting an answer over there. Here’s a quote from that post:

No support for deep sleep or hibernate on TDA4VM SDK. You are trying to do hibernation on TDA4VM? If yes we do NOT support that.

Now granted, they were working with the TI’s TDA4VM EVM, not the BBAI64. And the wording is such that they don’t support it on that setup.

I did get an answer back, but as suspected, not helpful and I don’t think the person actually read my request fully or had any desire to actually help. Ironically, it was the same person that answered the above question. Here’s what I got back:

The hardware definitely supports the low power modes however in the SDK(Software) there is NO support for suspend to RAM and wake up from that.

This is a heterogeneous SOC. R5F is the boot core which also runs the device manager, M3 runs the TI foundational security. A72 runs the HLOS.
So entering low power mode from Linux will need to diligently save the context of all the multiple firmware that run on the multiple cores of SoC &
restoring it back. In short this is a complicated feature and there is NO support in software. No plans for support in future.

This response makes sense for SuspendToRam. My guess is this would be very similar to a PC’s hibernate state where the processor, for all intents and purposes, is having to reboot. It’s just booting in a special mode where all its state info is having to be reloaded and manually restored, then triggered to start executing once everything is back in place. The difference here is that instead of spooling the entire contents of RAM the filesystem to hold the hibernation info, the RAM remains powered so that step can be skipped making startup a little faster.

However the DeepSleep mode, seems much less complicated…at least my interpretation of it reading the TRM. If DeepSleep is maintaining power to the processors, stopping each processor’s clock, and only killing power to the peripherals, then this seems far less complicated. I glean some of that from the Power Domains section of the TRM:

Now granted Linux would have to reconfigure the powered-off peripherals (such as UARTs) that were in use once they are repowered to their previous state, however I would’ve thought that would be a native part of Linux by now since it would likely have to do that on any platform (e.g. a laptop). I would hope pinmux settings would be one of the things being preserved so re-running through the device-tree to remux things isn’t necessary. But I don’t know that for sure. This is part of why I’m asking the questions.
What’s required?
What’s already developed and solved these needs? …And how do I make use of them?
What remains unsolved?

There was no mention from the TI person on this. So I’m going to copy/paste the following from the TRM (Sec 12.1.2.4.5) back to them and ask for some clarification on how this is done:

Stay tuned for what TI responds with, but I don’t have high hopes that it’ll be particularly enlightening.

So far, I’ve gotten no followup response on the e2e (not surprising). I know my posts tend to be a wall-of-text and the average person’s knee-jerk reaction is TLDR; ! But these are complicated subjects, and the details matter.

Just for completeness, here’s a link to that thread:
TI e2e: TDA4VM: What is required to suspend and wake up a BBAI64?

It’s not particularly informative and is mostly a repeat of the same things I’ve said here.

It does bother me a little that TI markets the TDA4VM as being for automotive use, but they have no example code or even suggestions for how they envisioned/tested it to be deployed in that environment…as it relates to power-down/quick-wake scenarios. My guess is they were so focused on the AI processing aspect that they ignored the basics.

And ironically those C66x/C7x processors are not even the focus of my intents for this chip. My focus is to make use of the PRUs of which they don’t want to claim exist.