Hi Zhou,
Le jeu., juil. 14 2022 at 12:14:07 +0800, Zhou Yanjie
<zhouyanjie@xxxxxxxxxxxxxx> a écrit :
Hi Paul,
On 2022/7/14 上午4:57, Paul Cercueil wrote:
Le jeu., juil. 14 2022 at 03:44:34 +0800, Mike Yang
<reimu@xxxxxxxxxxxxx> a écrit :
Hi Paul,
On 7/14/22 00:08, Paul Cercueil wrote:
Hi Mike,
[...]
If I comment the "wait" instruction, it will exit the suspend
process immediately. And yes, I don't think it suspended
properly.
Ok. I was suggesting to try that since it would show if the crash
happens when a particular device gets suspended.
Are you certain that your wakeup IRQ is unmasked?
I'm not sure. Which register should I check?
Check the IMCR0 / IMCR1 registers. Everything should be masked
except your wakeup source. If your wakeup source is a GPIO, also
check that the mask register that corresponds to your GPIO.
Do you mean ICMR0 and ICMR1 in the Interrupt Controller?
Yes, sorry.
Cheers,
-Paul
[...]
I'm afraid the above didn't work for me. Have you tested
suspend-to-ram in person on a X series SoC?
I didn't test on X-series, I mostly work with JZ. But that
part of the design didn't change since the JZ4740.
Cheers,
-Paul
To be honest, I never owned a board with a JZ series SoC. And
sorry for assuming the suspend-to-ram is unusable on all
Ingenic SoCs. IIRC, all the JZ series SoCs have external
DRAM, while the X series SoCs have internal DRAM. Also
Ingenic advertised the power saving features of the X series
SoCs heavily. Things might be different since it may involve
additional power management.
Even if the 3.x method you were describing works, the currently
upstream method should work as well, and if it doesn't, we
probably should try to figure why.
I remember doing some tests on the JZ4770 some years ago, and I
would get a power consumption of 7mA when suspended - that's
for the whole board, measured at the 3.7V battery, so about
0.026 W. The only things powered ON then are the RAM chips and
the SoC's RTC module.
At the time of writing the last sentence of the email, Dr. Zhou
just pointed out that it may has something to do with the
secure boot feature introduced in the X series SoC, although
the feature is not enabled. I already mailed my X1000E &
X1501 boards to Dr. Zhou for further tests. You may want to
get a X1000(E) board (e.g. halley2) and test this by yourself.
I do have a Cu1000-Neo board, but I have never used it, I
wouldn't know how to test this.
Cheers,
-Paul
Earlier today, Dr. Zhou and I talked to a senior engineer from
Ingenic. He said an extra piece of code is necessary for the X
series, and more CPM registers (other than LPM) are needed to be
configured. The X series can't reconfigure the DRAM to exit
self-refresh mode by themselves. He also said, if we really don't
want to put the code inside the kernel, it's possible to store
the $pc somewhere in the RAM and modify UBoot SPL to do
additional checks (e.g. P0 powerup flag) and jump back to the $pc
after reconfiguring DRAM. I'm not sure if this will work, since
the core will boot straight from the BROM, and the SFC and/or MSC
peripherals will be reconfigured before it can load SPL again
into the SRAM. It may cause confusion to the kernel SFC/MSC
drivers. From his words, we can have another method: incorporate
the code inside UBoot and write it to the SRAM prior to booting
the kernel. What's your opinion?
The X1000 has more CPM registers and do support turning the CPU
completely off, which is new compared to the JZ4780, so that part
is true. However, the regular method to enter SLEEP mode is still
described in the X1000, X1830 and X2000 programming manuals, and
it's the exact same method described in the JZ4780 and even in the
JZ4740 programming manuals. So allow me to doubt.
Knowing that Ingenic's 3.x kernel implements the "complete shutdown"
sleep mode, I would think that this is why your senior engineer
said that an extra piece of code is necessary - because that's how
they implemented it. But that does not mean that it is required,
and nothing in any of the X-series programming manuals suggests
that it is required.
Cheers,
-Paul
