• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 99 subscribers
  • Views 4071 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

BeagleBone Black Android 4.2.2 Suspend/Resume

Strahinja Jankovic
Prodigy 55 points
Other Parts Discussed in Thread: AM3358, AM3359

Hello,

Are there any instructions for downloading/building Android 4.2.2 with functional suspend/resume on BeagleBone Black?

I am working on BeagleBone Black with LCD7 cape. I have tried using following releases of Android 4.2.2:

- Prebuilt TI_Android_JB_4_2_2_DevKit_4_1_1 release (from here)

- Compiled JellybeanOnBeaglebone_WithSGX (from here)

- Prebuilt image from Circuitco (from here)

However, none of these releases has functional suspend/resume. Below is what I was able to do.

With TI and Rowboat release (kernel version 3.2), when I press ENTER button on the LCD7 cape, screen turns off.

If I press the ENTER button again, or touch the screen, within a second or two after screen gets turned off, the screen turns on again. Here are messages from dmesg:

[   72.187835] request_suspend_state: sleep (0->3) at 72134653765 (2000-01-01 00:01:10.336853329 UTC)
[   72.997985] request_suspend_state: wakeup (3->0) at 72944803910 (2000-01-01 00:01:11.146972956 UTC)

If I wait some time (as far as I can see, it depends on how long the board has been working; if it has been working for couple of minutes, it takes around 3 seconds, if it has just been turned on, it can take up to 10 seconds), then whatever I do (press the ENTER button, or touch/press the screen) gives me no result, the board hangs and I have to reset it. Here are messages from dmesg:

[  205.330780] request_suspend_state: sleep (0->3) at 205277836810 (2000-01-01 00:14:38.484549459 UTC)
[  213.109710] PM: Syncing filesystems ... done.
[  213.192901] Freezing user space processes ... (elapsed 0.01 seconds) done.
[  213.216094] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
[  213.235992] Suspending console(s) (use no_console_suspend to debug)

If I start pressing the screen as soon as I see messages above, than after couple of seconds, suspend gets aborted and screen turns on again. Here are messages from dmesg:

[  165.641906] request_suspend_state: sleep (0->3) at 165588109612 (2000-01-01 00:02:43.875452920 UTC)
[  165.751312] PM: Syncing filesystems ... done.
[  165.866973] Freezing user space processes ... (elapsed 0.01 seconds) done.
[  165.887054] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
[  165.906829] Suspending console(s) (use no_console_suspend to debug)
[  171.051330] LCD Controller timed out
[  171.052551] sched: RT throttling activated
[  171.061218] PM: suspend of devices complete after 5147.003 msecs
[  171.065368] omap_hwmod: adc_tsc: _wait_target_disable failed
[  171.066772] active wake lock event0-316, time left 346
[  171.066802] active wake lock event1-316, time left 498
[  171.066864] pm_noirq_op(): platform_pm_suspend_noirq+0x0/0x50 returns -11
[  171.066894] PM: Device power.0 failed to suspend late: error -11
[  171.067749] PM: early resume of devices complete after 0.823 msecs
[  171.068023] PM: Some devices failed to power down
[  171.212432] net eth0: CPSW phy found : id is : 0x7c0f1
[  171.213195] PHY 0:01 not found
[  171.237518] PM: resume of devices complete after 169.433 msecs
[  171.309204] Restarting tasks ... done.
[  171.481475] suspend: exit suspend, ret = -11 (2000-01-01 00:02:49.715022012 UTC)
[  171.574920] request_suspend_state: wakeup (3->0) at 171521123528 (2000-01-01 00:02:49.808466836 UTC)

On the other hand, the release from Circuitco (kernel version 3.8) has blank /sys/power/state file, and when I press POWER button on the LCD7 cape, screen only turns black (doesn't even turn off), and nothing else happens.

I tried using the TI's release with regular BeagleBone, and it behaves as expected: after I press ENTER key and screen turns off, no matter how much time passes, after I touch the screen, the screen turns on and board is functional. Here is the dmesg:

<6>[  424.619537] request_suspend_state: sleep (0->3) at 398807885455 (2000-01-01 00:07:03.264914820 UTC)
<6>[  424.803466] PM: Syncing filesystems ... done.
<7>[  424.809967] PM: Preparing system for mem sleep
<4>[  424.811187] Freezing user space processes ... (elapsed 0.01 seconds) done.
<4>[  424.834838] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
<7>[  424.854583] PM: Entering mem sleep
<4>[  424.854644] Suspending console(s) (use no_console_suspend to debug)
<3>[  429.867309] LCD Controller timed out
<6>[  429.876708] PM: suspend of devices complete after 5014.617 msecs
<6>[  429.878753] PM: late suspend of devices complete after 1.953 msecs
<6>[  432.608459] GFX domain entered low power state
<6>[  432.608520] Successfully transitioned all domains to low power state
<6>[  432.812347] PM: early resume of devices complete after 203.338 msecs
<6>[  432.821960] wakeup wake lock: event0-328
<6>[  432.939941] net eth0: CPSW phy found : id is : 0x7c0f1
<3>[  432.941528] PHY 0:01 not found
<6>[  432.964752] PM: resume of devices complete after 151.660 msecs
<7>[  433.019165] PM: Finishing wakeup.
<4>[  433.019195] Restarting tasks ... 
<6>[  433.053039] request_suspend_state: wakeup (3->0) at 404511488614 (2000-01-01 00:07:11.088594855 UTC)
<4>[  433.101379] done.
<6>[  433.122680] suspend: exit suspend, ret = 0 (2000-01-01 00:07:11.158249111 UTC)

Thank you for your help!

Strahinja Jankovic

  • 0
    TI__Expert 7220 points

    Hello,

    On BeagleBoneBlack and LCD7, there is no key/switch  connected to GPIO bank 0. This will prevent you from waking up the system from suspend.

    Do you have an LCD4 cape? It has S6/ENTER key connected to GPIO- bank 0. For Android to get back to lock screen, you may need to remap this key to KEY_POWER in board file and in gpio-keys.kl.

    Or else do you have the serial cable access? With serial input you will be able to wake up the system.

    Regards,

    Arun

  • 0 in reply to Arun Joseph
    Prodigy 55 points

    Hello,

    Thank you for you reply!

    As far as I can see in the LCD7 reference manual, and quote from section 2.2:

    In revision A3 the Enter button has been moved from GPIO3_19 to GPIO0_3 and LCD_DVDD_EN has moved from GPIO1_31 to GPIO0_2. These changes in GPIOs are to support awake interrupt in sleeping mode.

    the A3 revision (that I'm using) has button ENTER tied to GPIO bank 0, so wakeup should be possible using ENTER key.

    I have tried to wake up the board using serial console, but it doesn't work. Are there any specific instructions on how to do it? I have tried writing 'enabled' to /sys/devices/platform/omap/omap_uart.0/tty/ttyO0/power/wakeup, but it shows no difference. I have also looked at AM335x_Power_Management_User_guide, but there are no specific instructions for uart wakeup.

    However, I was able to find a workaround for suspend/resume, and I would really appreciate if you have a suggestion for a simpler solution. Here is the workaround:

    1) Enable pinmux suspend_io_pad_conf (/sys/kernel/debug is mounted at /d)

    # echo 1 > /d/omap_mux/board/suspend_io_pad_conf/enable_suspend_io_pad_conf

    2) Write uart0_rxd.gpio1_10=0x27 to suspend_pad_conf (I saw this in the AM335x_Power_Management_Standby_User's_Guide, just switched from standby to suspend)

    # echo uart0_rxd.gpio1_10=0x27 > /d/omap_mux/board/suspend_io_pad_conf/suspend_pad_conf

    3) Press ENTER key on LCD7, so the board suspends

    4) Board cannot be resumed, so it needs to be restarted using the RESET button (not unplugged!)

    5) After the board boots up, wakeup works using all three available methods: GPIO (ENTER key), UART (serial console) and touch screen.

    6) As long the board isn't unplugged (ie as long it's rebooted only using RESET button), wakeup works.

    This is functional enough for testing, but is unusable for everyday work. Am I doing something wrong? Do you have some suggestions on how to make suspend/resume functional? Thank you.

    Best regards,

    Strahinja Jankovic

  • 0 in reply to Strahinja Jankovic
    TI__Expert 7220 points

    Hi,

    Thanks. I did not have an A3 revision of LCD7 cape.

    I have been doing some experiments on BBB, and found that the DDR self refresh timing and the self refresh assert does not get configured on first sleep sequence. Check the registers 0x4C000038 and 0x4C00003C. But after a reset these values are getting configured.

    So what we can do is write 0x2a0 to 0x4C000038 and 0xa0 to 0x4C00003C from SPL code or u-boot prompt. Suspend and resume would work after this. Suspend pad conf setting are not required. (They are used to optimize the IO pad power in sleep state )

    But I am still wondering why the writes does not go through from sleep33xx.S.

    Regards,

    Arun

     

  • 0 in reply to Arun Joseph
    Prodigy 55 points

    Thanks, this solved the problem!

    Best regards,

    Strahinja Jankovic

    Arun Joseph said:

    Hi,

    Thanks. I did not have an A3 revision of LCD7 cape.

    I have been doing some experiments on BBB, and found that the DDR self refresh timing and the self refresh assert does not get configured on first sleep sequence. Check the registers 0x4C000038 and 0x4C00003C. But after a reset these values are getting configured.

    So what we can do is write 0x2a0 to 0x4C000038 and 0xa0 to 0x4C00003C from SPL code or u-boot prompt. Suspend and resume would work after this. Suspend pad conf setting are not required. (They are used to optimize the IO pad power in sleep state )

    But I am still wondering why the writes does not go through from sleep33xx.S.

    Regards,

    Arun

     

  • 0 in reply to Strahinja Jankovic
    Prodigy 220 points

    Dear Strahinja and Arun,


    Could you give me some indications about where I can write (path, files, shell...) the registers 0x4C000038 and 0x4C00003C. I'm a little confused about it.

    Regards,

  • 0 in reply to Arun Joseph
    Prodigy 120 points

    Hi Arun,

    I implemented the (2) writes in u-boot arch/arm/cpu/armv7/am33xx/board.c in the function s_init.

     

    void s_init(void)
    {

    ...

    writel(0x2a0, 0x4c000038);
     writel(0xa0, 0x4c00003c);

    }

    It works on our Beaglebone Black boards with Rev A6 (running Android 4.2). However when l loaded the u-boot images onto the newly received Beaglebone black rev B. I got "LCDC Sync Lost" all the time.

    I understand that the BBB Rev A6 uses AM3358 instead of AM3359 chip. I wonder if those register values need to be modified for the different chip. Or there might be some other reason. Also I still don't understand how those PM register values affect the LCD controller behavior.

    BTW, after I removed those (2) lines to set the PM control registers, the LCDC sync lost error goes away. But I couldn't wakeup the system.

    Regards,

    Lei

  • 0 in reply to Lei Wang10
    Prodigy 190 points

    Hi Lei, 

    I've encountered the same effect, see http://e2e.ti.com/support/embedded/android/f/509/p/385712/1375300

    Writing these registers in the bootloader caused the same "LCDC sync lost" at my board.

    You could try to activate the self refresh in PWR_MGMT_CTRL (0x4c000038) in am33xx_pm_begin(...) and clear the self refresh bit in am33xx_pm_end(...) like this:

    static int am33xx_pm_begin(suspend_state_t state)

    {
    int ret = 0;
    int state_id = 0;

    /* mp,2014-12-15: Set PWR_MGMT_CTRL to self refresh */
    void __iomem *base = am33xx_get_ram_base();
    __raw_writel(0x2a0, base + EMIF4_0_SDRAM_MGMT_CTRL);
    readl(base + EMIF4_0_SDRAM_MGMT_CTRL);
    __raw_writel(0xa0, base + EMIF4_0_SDRAM_MGMT_CTRL_SHADOW);
    readl(base + EMIF4_0_SDRAM_MGMT_CTRL_SHADOW);

    The same with 0x00 in am33xx_pm_end(...).

    Note: I call readl(...) because the datasheet SPRUH73I states in Table 7-233. PWR_MGMT_CTRL Register Field Descriptions: Note: After updating this field, at least one dummy read access to SDRAM is required for the new value to take affect.
    But I don't know if this is really required in this case.

    Hope this helps.

  • 0 in reply to CM_
    Prodigy 120 points
    Hi,

    Thanks for sharing the code.

    I did similar implementation in the am33xx_pm_finish and am33xx_do_sram_idle. But It is essentially same as what you did.

    Thanks again!

    Lei