The wake up source needs to be the interrupt from the AXP chip, I think~
edit: ohwait I think you’ve already explored all of that 
Looking through your updates, I think you’re much farther along on understanding what’s going on than I am. There’s some interesting stuff with how the axp228 is configured w/ some registers set in the patches from CPi that could intersect but it seems like you’re mostly focused below that at this point?
Could be related! A successful resume depends on a lot of stuff, including power regulators (PWM or constant), wakeup sources, DDR self-refresh, power domain config, sram preservation etc. etc. Gotta say this is well beyond what I’m usually focused on (where a proper BIOS/UEFI is doing all the hard work)…
Nevertheless, AXP228 config could be related because, even if I now connect R124, switch GPIO0_A5 from emmc_pwr to GPIO, and config negative edge wakeup, it seems not the intended way that rk3399 receives a power-on interrupt. I mean, without that the system can also detect if I press the key (definitely not through GPIO0_A5 since it’s NC) – so maybe I should config AXP228/RK808 to get ready first and then send the interrupt? I have no idea.
Another thing is that there’s a PWM regulator connected to PWM3 (vdd_log, from the name it seems to be the logic-level vdd). Currently I’m not configuring any PWM or APIO functionalities during suspend. So that’s another thing to consider.
To complicate things further, there’re another two pieces of closed-source blobs – the rockchip boot rom, and the code that runs on the onboard m0 microcontroller. Something like the BIOS. These are related to how the init params are passed into bl31 (or not at all!), and how bl31 gets to know the system configuration without devicetree.
Maybe I should also throw these into Ghidra and take a look…
Current situation: wfi definitely executed. But when I try to wake it up, it does not reach the “suspend_finish” code as I expect. It does not hit my “fan loop breakpoint”. I don’t even know why it would execute that to begin with, because I would think when it wakes up it should continue executing code after wfi (stm32 arduino thinking, but it looks like all these “trusted firmware” say otherwise) – it probably did not execute code after wfi either, because awaits there is a panic handler that “should not be reached”, and will perform a soft reset immediately.
It is hard to move forward without proper debugging tools at this moment.
One thing to add, rk3399 only supports gpio0 and 1 for low power mode, so if PMIC_INT_L is connected to gpio3 like the tropical tree devices it won’t be a wakeup source anyway ((