|
Hi, I am facing some issues related to system wake up from the sleep. The SPEAr system is a SOC having the ARM cortex core. The system hardware has certain power islands, and one such island contains the Memory controller. If all the power islands except for the one with memory controller are switched off before moving into sleep, the wake up and system restore happens fine. But once I switch off the power island containing Memory Controller, we are facing certain issues as soon as I re-enable the MMU. Before Moving into sleep the following actions are performed. 1. The code execution is done on the "Always on RAM". As the PC jumps to Always on RAM, the contents of link register and GPR are latched on to stack in DDR. Post this all the push operations are done on a temporary stack maintained in Always on ram (AOR) 2. Store sp and spsr to AOR 3. Save all ARM registers: Coprocessor access control register, TTBR0, TTBR1 and Translation table base control, Domain access control register, data fault status register, instruction fault status register, Data aux fault status register, instruction aux fault status, data fault address register and instruction fault address register, user r/w thread and process ID, user r/o thread and process ID, priv only thread and process ID, cache size selection, Data TLB lockdown, instruction TLB lockdown registers, Secure or non secure vector base address, FCSE PID, Context PID, Primary remap, normal remap registers, current cpsr, Data memory barrier and Data sync barrier... 4. Switch off Instruction Cache, prediction flow, data cache. Then Switch off the MMU, put the DDR is self refresh. 5. Latch the memory controller initialization values on to stack 5. Move the system into low power mode, and then switch off the power domains. Post wake up the actions are performed to restore in the reverse order. The values of the registers poped back is verified to be fine. 1. An additional step is to reset and reprogram the Memory controller with the values latch on to the stack. When the MMU is re-enabled, the PC jumps fine to the Virtual address on the "Always-on RAM". Then I pop the contents of link register, and GPR, from the stack. The contents of these registers matched with the contents that were pushed before moving into sleep (verification done). The DDR contents were also verified to be correct for some random locations ( 0x0-0x8000) before and after sleep, to ensure that the DDR corruption is not triggering the problem. The last step involves programming the Program counter to a location on DDR (latched in link register on DDR stack). But as soon as the Program Counter is programmed with the value of link register (popped from DDR), the system gets a error, which I am not able to trace using the lauterbach debugger. I suspect that there are still few things left in MMU configuration (not sure), which I missed. The corruption problem could not be totally ruled out though as the memory controller also moves to off state in system sleep, and then is reset followed by DDR moved out of self refresh. I would really appreciate any help on this. Regards Deepak |
_______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
