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? > > [...] > >>>>> 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? Regards, Mike
