I am working on expanding the suspend and resume capability for Linux
running on a Xilinx Zynq Soc that has dual ARM A9s using the Xilinx 2014.4
PetaLinux distribution that uses the 3.17 kernel.
The distribution currently supports suspend and resume without removing
power to the processors. I am working on expanding the support to include
removing power to the processors while the DDR memory is in self refresh
mode, then performing a warm boot and having the first stage boot loader
(FSBL) hand control back to the Linux kernel in the correct spot to continue
with the resume process.
I am looking for what routine to have the first stage boot loader call. I
think it might be cpu_resume in arch/arm/kernel/sleep.S, but I am not sure
and would like to verify that it is the correct routine to be calling.
I am jumping to this from the FSBL after a suspend and warm boot, and single
stepping through the code in a debugger. It gets to the end of this routine,
but the debugger looses connection near the end of that routine shortly
after this instruction is executed: ARM( ldmia r0!, {r1, sp, pc}
)
In an effort to see if this is the correct entry point, I have modified pm.c
in arch/arm/mach-zynq.c to call soft_restart(virt_to_phys(cpu_resume)) just
after the resume has happened in the case where the processors are not
powered off, but are woken back up with an interrupt. The soft_restart
routine turns off the MMUs and clears the caches, and I am using it to get
the processors into a similar state as to what they would be in if they had
been power cycled. The cpu_resume routine expects to be called with cache
and MMU off. This test mostly works, and gets much further than calling
cpu_resume from the FSBL. It gets out of assembly code, and back into C, and
is printing messages. The cpu_resume routine expects to be called with cache
and MMU off.
I have read the Documentation/power/devices.txt file, and anything else I
could find.
I have already done a version of this that uses the no OS flow to put the
DDR into self refresh and power cycle the processors, and tested it on
hardware. That flow does not use virtual memory.
I have looked for other code that does this, but since the code performing
the warm boot is device firmware and not kenel code I have not found an
example yet.
Is cpu_resume the correct renentry point for resuming after a suspend?
Can anyone point me to an example I can look at?
Thank you in advance,
John McCaskill
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
