AM4376: Suspend/resume issue with DDR settings

Hi Sir

we did some experiemnts in AM437x GP-EVM.

we modified the DDR parameter  emif_ddr_phy_ctlr_1 from 0x0E004008 to 0x00048008.

and then execute echo mem > /sys/power/state ->  system cannot wakeup

we are also checking the emif_ddr_phy_ctlr_1 setting in excel file and found there is something wrong.

if we want to adjust the register value of  emif_ddr_phy_ctlr_1 to be 0x0E004008 , the DDR setting must be DDR2.

please advise why this register will cause system wake up failed. 

BR

Yimin

Hi Sir 

we found the root cause why the system cannot go into suspend mode and wake up well.

In GP-EVM DDR Setting, the RDLVL_MASK,RDLVLGATE_MASK,WRLVL_MASK these masks are enabled in order not to perform h/w leveling training.

In AM437x_EMIF_Configuration_Tool and wiki , TI advises to disable RDLVL_MASK,RDLVLGATE_MASK,WRLVL_MASK  in order to perform h/w leveling training.

But it will cause our MB cannot go into suspend mode and wake up well.

if we follow GP-EVM's setting to enable RDLVL_MASK,RDLVLGATE_MASK,WRLVL_MASK in order not to perform h/w leveling training. the system can do suspend mode and wake up well.

please advise 

BR

Yimin

Hi Sir

Do you have any update? 

in GP-EVM, the HW leveling is disabled and can do suspend/resume well.

if we enable HW leveling, the suspend/resume function would fail. 

In Wiki, TI advises enabling HW leveling.

please advise.

BR

Yimin

Hi Sir

It's been almost a month and no update from TI.

Do we need to create another thread to discuss this issue which can duplicate in EVM ? 

BR

Yimin

Hi SIr

Do you have any update ?

thanks

BR
Yimin

Yimin,

By playing around with CCS, I found that all the memory values were “jumping around” while I was in this failed resume state.  By writing EMIF4D_READ_WRITE_LEVELING_CTRL = 0x80000000 (i.e. initiating leveling), everything suddenly stabilized.  I've been looking at the function am43xx_resume_from_deep_sleep which is in the file arch/arm/mach-omap2/sleep43xx.S.  It doesn't look like we re-run the leveling when we resume from deep-sleep.  I believe that's the fundamental issue.

So it's not fully resolved yet, but we're getting closer.  I wanted to share this information with you in case you are able to perform any experiments of your own along these lines.

Best regards,
Brad

We have an internal meeting scheduled for tomorrow afternoon to discuss further.  We will get this figured out soon.

Yimin,

As I mentioned, we have a call on this topic tomorrow.  However, I've been looking into it and I have a prelim patch available.  Note that this has not been rigorously tested, nor has it even been reviewed for that matter!  However, I'd like for you to try it out and verify that it's working for you too.

Here's Rev 1 of the patch:

• https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/0001_2D00_AM4_2D00_Fix_2D00_resume_2D00_code_2D00_to_2D00_support_2D00_hw_2D00_leveling.patch

Please let me know how it goes.  I used Processor SDK Linux 4.03 as the baseline for my patch.

Best regards,
Brad

Yimin,

After reviewing with others, we determined we also needed a wait loop to allow the leveling to complete before the code runs.

Here's Rev 2 of the patch:

• https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/5756.0001_2D00_AM4_2D00_Fix_2D00_resume_2D00_code_2D00_to_2D00_support_2D00_hw_2D00_leveling.patch

Furthermore, in u-boot there were a couple other changes (besides unmasking the leveling).

1. To bring proper support for PHY_INVERT_CLKOUT=1, you would need the patch shown here.
2. One other recommended change relates to the value of ext_phy_ctrl_36:

diff --git a/arch/arm/mach-omap2/am33xx/ddr.c b/arch/arm/mach-omap2/am33xx/ddr.c
index 2949d1d..5c9f108 100644
--- a/arch/arm/mach-omap2/am33xx/ddr.c
+++ b/arch/arm/mach-omap2/am33xx/ddr.c
@@ -285,8 +285,8 @@ static void ext_phy_settings_hwlvl(const struct emif_regs *regs, int nr)
writel(0x00000000, &emif_reg[nr]->emif_ddr_ext_phy_ctrl_34_shdw);
writel(0x00000000, &emif_reg[nr]->emif_ddr_ext_phy_ctrl_35);
writel(0x00000000, &emif_reg[nr]->emif_ddr_ext_phy_ctrl_35_shdw);
- writel(0x000000FF, &emif_reg[nr]->emif_ddr_ext_phy_ctrl_36);
- writel(0x000000FF, &emif_reg[nr]->emif_ddr_ext_phy_ctrl_36_shdw);
+ writel(0x00000077, &emif_reg[nr]->emif_ddr_ext_phy_ctrl_36);
+ writel(0x00000077, &emif_reg[nr]->emif_ddr_ext_phy_ctrl_36_shdw);

/*
* Sequence to ensure that the PHY is again in a known state after

TI's software team is working on integrating these changes into future versions of u-boot and the kernel.

Have you had a chance to try out any of the patches yet?  Please let us know what you're observing.

Best regards,
Brad

Hi Sir 

thanks for your help. it works in the customized board.

BTW, we saw below issue in log message. Is it the same issue or side effect ?

root@rd:~# dmesg | grep err

[    0.191913] omap_l3_noc 44000000.ocp: L3 debug error: target 8 mod:0 (unclearable)

[    0.191972] omap_l3_noc 44000000.ocp: L3 application error: target 8 mod:0 (unclearable)

BR

Yimin

Hi Sir

we used GP-EVM to do patch.


/* EMIF DDR3 Configurations are different for production AM43X GP EVMs */
const struct emif_regs ddr3_emif_regs_400Mhz_production = {
//.emif_ddr_phy_ctlr_1 = 0x0E004008,
.emif_ddr_phy_ctlr_1 = 0x00004008,

Update sleep43xx.S files

the error message can show up.
[ 0.211875] omap_l3_noc 44000000.ocp: L3 debug error: target 8 mod:0 (unclearable)
[ 0.211934] omap_l3_noc 44000000.ocp: L3 application error: target 8 mod:0 (unclearable)

if we do suspend/resume. it seems there is no error message and no abnormal behaviors.

root@am437x-evm:~# echo mem > /sys/power/state
[ 306.184372] PM: Syncing filesystems ... done.
[ 306.192048] Freezing user space processes ... (elapsed 0.002 seconds) done.
[ 306.206374] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[ 306.215681] Suspending console(s) (use no_console_suspend to debug)
[ 306.252262] PM: suspend of devices complete after 28.041 msecs
[ 306.256404] PM: late suspend of devices complete after 4.108 msecs
[ 306.260757] PM: noirq suspend of devices complete after 4.320 msecs
[ 306.260768] PM: Successfully put all powerdomains to target state
[ 306.260768] PM: Wakeup source UART
[ 306.280324] PM: noirq resume of devices complete after 19.436 msecs
[ 306.283965] PM: early resume of devices complete after 3.151 msecs
[ 306.285199] net eth0: initializing cpsw version 1.15 (0)
[ 306.285223] cpsw 4a100000.ethernet: initialized cpsw ale version 1.4
[ 306.285238] cpsw 4a100000.ethernet: ALE Table size 1024
[ 306.386017] Micrel KSZ9031 Gigabit PHY 4a101000.mdio:00: attached PHY driver [Micrel KSZ9031 Gigabit PHY] (mii_bus:phy_addr=4a101000.mdio:00, irq=-1)
[ 306.390059] cpts ptp bc clkid 0
[ 306.412910] Suspended for 10.894 seconds
[ 306.413534] usb usb1: root hub lost power or was reset
[ 306.413553] usb usb2: root hub lost power or was reset
[ 306.533744] PM: resume of devices complete after 249.744 msecs
[ 306.632370] Restarting tasks ... done.

BR
Yimin

Yimin,

We have observed your issue related to the startup error.  We've been working on that issue and also a corresponding issue in suspend/resume (i.e. once you resolve the startup error then the error "moves" to the first time suspend/resume occurs).  Tomorrow is a holiday in the US, and we have a meeting on Thursday to discuss further.  I have some experimental code that looks to be working properly, but we need to discuss further internally before I post it.  So perhaps at the end of this week we will have something or maybe early next week.

Best regards,
Brad