OMAP-L138: Waking up from Deep Sleep

Hello Wes,

The RTC reset issue was discovered post the 2.6.37 release made by our team, hence it is not part of the release package.

Are you telling that, even after applying the RTC reset patch, you are not able come out of deep sleep state? Please try passing "no_console_suspend" from the U-Boot bootargs. This will keep serial alive during suspend and any error/warning messages will be printed on the console.

Regards, Sudhakar

Hi Sudhakar,

Thank you for your reply.

One thing I should mention is that I am using the Secure chip (rev. B) on the OMAP-L138.

Yes, after applying the RTC reset patch, I am not able to come out of deep sleep unless I physically reboot the board. I've tried booting from NFS and from NOR. I added "no_console_suspend" to my bootargs and get the following output from a NOR boot:

root@arago:~# hwclock -r
Fri Jan 13 11:03:53 2012  0.000000 seconds
root@arago:~# hwclock -r
Fri Jan 13 11:03:55 2012  0.000000 seconds
root@arago:~# rtcwake -d /dev/rtc0 -m mem -s 5
wakeup from "mem" at Fri Jan 13 11:04:47 2012
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.01 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
PM: suspend of devices complete after 1.625 msecs
PM: late suspend of devices complete after 0.219 msecs

I added a few debug statements in the following output from an NFS boot:

root@arago:~# hwclock -r
Fri Jan 13 11:31:07 2012  0.000000 seconds
root@arago:~# hwclock -r
Fri Jan 13 11:31:09 2012  0.000000 seconds
root@arago:~# rtcwake -d /dev/rtc0 -m mem -s 5
wakeup from "mem" at Fri Jan 13 11:31:31 2012
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.01 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
kernel/power/suspend.c, suspend_devices_and_enter
--> drivers/base/power/main.c, dpm_suspend
--> drivers/rtc/rtc-omap.c, omap_rtc_suspend: event(2)
omap_rtc_suspend: enable_irq_wake(19)
arch/arm/mach-davinci/cp_intc.c, cp_intc_set_wake
<-- omap_rtc_suspend
PM: suspend of devices complete after 20.657 msecs
<-- drivers/base/power/main.c, dpm_suspend
PM: late suspend of devices complete after 0.234 msecs
arch/arm/mach-davinci/pm.c, davinci_pm_suspend
System goes to sleep in this call

The last line, "System goes to sleep..." is right before the call to davinci_sram_suspend() in arch/arm/mach-davinci/pm.c. I have another print statement after the call to davinci_sram_suspend(), which is never printed. Is there more to the patch than the changes in drivers/rtc/rtc-omap.c, like maybe in cp_intc_set_wake() which just returns 0?

Thanks,
Wes

Hi Sudhakar,

I switched back to the non-secure chip, used the same uImage and booted from NFS and the board did come out of deep sleep. Note the output below:

root@arago:~# hwclock -r
Fri Jan 13 12:13:10 2012  0.000000 seconds
root@arago:~# hwclock -r
Fri Jan 13 12:13:12 2012  0.000000 seconds
root@arago:~# rtcwake -d /dev/rtc0 -m mem -s 5
wakeup from "mem" at Fri Jan 13 12:13:40 2012
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.01 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
kernel/power/suspend.c, suspend_devices_and_enter
--> drivers/base/power/main.c, dpm_suspend
--> drivers/rtc/rtc-omap.c, omap_rtc_suspend: event(2)
omap_rtc_suspend: enable_irq_wake(19)
arch/arm/mach-davinci/cp_intc.c, cp_intc_set_wake
<-- omap_rtc_suspend
PM: suspend of devices complete after 20.712 msecs
<-- drivers/base/power/main.c, dpm_suspend
PM: late suspend of devices complete after 0.237 msecs
arch/arm/mach-davinci/pm.c, davinci_pm_suspend
System goes to sleep in this call
Are we awake?
PM: early resume of devices complete after 0.054 msecs
drivers/rtc/rtc-omap.c, omap_rtc_resume
arch/arm/mach-davinci/cp_intc.c, cp_intc_set_wake
eth0: attached PHY driver [SMSC LAN8710/LAN8720] (mii_bus:phy_addr=1:00, id=7c0f
1)
PM: resume of devices complete after 18.652 msecs
Restarting tasks ... done.
PHY: 1:00 - Link is Up - 100/Full
root@arago:~#

Can you think of any reason why this doesn't work with the secure chip?

Thanks,
Wes

Hi Sudhakar,

I've tracked down where the secure chip is getting hung up. Unfortunately, it is all in assembly code located in virtual address space and I haven't been able to exactly match it up to a .S file. Here is the assembly blurb:

    0xFFFE0114:   E8BD9FFF LDMFD         R13!, {R0-R12, PC}
    0xFFFE0118:   E3A06C0A MOV           R6, #0xA00
    0xFFFE011C:   E0866102 ADD           R6, R6, R2, LSL #2
    0xFFFE0120:   E791C006 LDR           R12, [R1, R6]
    0xFFFE0124:   E3CCC01F BIC           R12, R12, #0x1F
    0xFFFE0128:   E18CC000 ORR           R12, R12, R0
    0xFFFE012C:   E781C006 STR           R12, [R1, R6]
    0xFFFE0130:   E591C120 LDR           R12, [R1, #0x120]
    0xFFFE0134:   E38CC001 ORR           R12, R12, #0x1
    0xFFFE0138:   E581C120 STR           R12, [R1, #0x120]
    0xFFFE013C:   E591C128 LDR           R12, [R1, #0x128]
    0xFFFE0140:   E20CC001 AND           R12, R12, #0x1
    0xFFFE0144:   E35C0000 CMP           R12, #0x0
--> 0xFFFE0148:   1AFFFFFB BNE           0xFFFE013C
    0xFFFE014C:   E3A06B02 MOV           R6, #0x800
    0xFFFE0150:   E0866102 ADD           R6, R6, R2, LSL #2
    0xFFFE0154:   E791C006 LDR           R12, [R1, R6]
    0xFFFE0158:   E20CC01F AND           R12, R12, #0x1F
    0xFFFE015C:   E15C0000 CMP           R12, R0
    0xFFFE0160:   1AFFFFFB BNE           0xFFFE0154
    0xFFFE0164:   E1A0F00E MOV           PC, R14
    0xFFFE0168:   C002B030 ANDGT         R11, R2, R0, LSR R0

And the registers:

R0  = 0x00000002
R1  = 0xFEE27000
R2  = 0x00000006
R3  = 0xFEE1A000
R4  = 0xFEE2C008
R5  = 0x00000000
R6  = 0x00000A18
R7  = 0xC2810000
R8  = 0xC0E21000
R9  = 0xC0D35D58
R10 = 0x00000003
R11 = 0x00089F78
R12 = 0x00000001
R13 = 0xC1CF9EB8
R14 = 0xFFFE0044
PC  = 0xFFFE013C

Register 12 never changes to 0, as it does with the non-secure chip. The closest approximation that I've come to is in arch/arm/mach-omap2/sram34xx.S, in the wait_sdrc_idle1 section. I think that the BNE instruction marked with an arrow above is on line 210 of that file. Is this is so, does that mean that the system is waiting for DDR to go idle before entering or leaving deep sleep mode?

Thanks,
Wes

Hi Sudhakar,

The assembly excerpt above is not from the file that I first thought. It is actually from davinci_ddr_psc_config() function in sleep.S. As it turns out, after calling the Power Domain Transition Command for DDR (PSC1-6), the memory and registers go into a bad state (0x0BAD0BAD). I pulled a DDR self-refresh test that a made several months ago into the ARM UBL and came across the same problem. In an attempt to disable the VCLK, the system hangs on the PSC transition. This is only a problem on the Secure OMAP-L138 chip, and can occur before Linux is even started. This test and the rtc wake command work fine on the Non-Secure OMAP-L138. Can this thread be moved "OMAP-L13x, AM1x and C674 Processors Forum", or should I start a new thread?

Thanks,
Wes

Hi Wes,

I do not have permission to move this thread. I would suggest please start a new thread under "OMAP-L13x, AM1x and C674 Processors Forum", and point to this link.

Thanks, Sudhakar