• State TI Thinks Resolved
  • Locked Locked
  • Replies 27 replies
  • Answers 4 answers
  • Subscribers 101 subscribers
  • Views 1734 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.

Linux/OMAPL138B-EP: how to link code to internal memory in Linux

GSK
Intellectual 870 points

Part Number: OMAPL138B-EP
Other Parts Discussed in Thread: OMAPL138, OMAP-L138

Tool/software: Linux

Hi ,

Working on DEEPSLEEP feature implementation on a  device running kernel 3.10.12 on OMAPL138 .   we are using the gcc-4.4.1-glibc-2.10.1/bin/arm-none-linux-gnueabi- (GCC toolchain). We are facing issues on linking the code to internal memory in linux.

Fullscreen deepsleepfunction.txt Download 
static void davinci_pm_suspend(void)
{
	unsigned val;

		//Clear Self Refresh / low power (SR_PD)bit to 0
		val = __raw_readl(pdata->ddr2_ctlr_base + 0x0C);
		val &= ~(0x00800000);
		__raw_writel(val, pdata->ddr2_ctlr_base + 0x0C);

		//set the low power enable 
		val = __raw_readl(pdata->ddr2_ctlr_base + 0x0C);
		val |= (0x80000000);
		__raw_writel(val, pdata->ddr2_ctlr_base + 0x0C);

		/* Switch CPU PLL0 to bypass mode */
		val = __raw_readl(pdata->cpupll_reg_base + PLLCTL);
		val &= ~(PLLCTL_PLLENSRC|PLLCTL_PLLEN);
		__raw_writel(val, pdata->cpupll_reg_base + PLLCTL);

		/* Switch CPU PLL1 to bypass mode */
		val = __raw_readl(pdata->ddrpll_reg_base + PLLCTL);
		val &= ~(PLLCTL_PLLENSRC|PLLCTL_PLLEN);
		__raw_writel(val, pdata->ddrpll_reg_base + PLLCTL);

		udelay(PLL_BYPASS_TIME);

		/* Powerdown CPU PLL0 */
		val = __raw_readl(pdata->cpupll_reg_base + PLLCTL);
		val |= PLLCTL_PLLPWRDN;
		__raw_writel(val, pdata->cpupll_reg_base + PLLCTL);

		/* Powerdown CPU PLL1 */
		val = __raw_readl(pdata->ddrpll_reg_base + PLLCTL);
		val |= PLLCTL_PLLPWRDN;
		__raw_writel(val, pdata->ddrpll_reg_base + PLLCTL);


		/* Set DeepSleep pin in PINMUX0 register */
		val = __raw_readl(pdata->pinmux_reg_base +0x120);
		val &= ~(0xF0000000);
		__raw_writel(val, pdata->pinmux_reg_base + 0x120);

	/* Configure sleep count in deep sleep register */
	val = __raw_readl(pdata->deepsleep_reg);
	val &= ~DEEPSLEEP_SLEEPCOUNT_MASK,
	val |= 0x000F;
	__raw_writel(val, pdata->deepsleep_reg);
	/* Configure Enable Deep bit in the  sleep register */
	val = __raw_readl(pdata->deepsleep_reg);
	val |= 0x80000000;      
	__raw_writel(val, pdata->deepsleep_reg);
   	do
	{
		val = __raw_readl(pdata->deepsleep_reg);
		val &= 0x40000000;      
	}while(0==val);



		/* Clear Enable Deepsleep bit in the  sleep register */

		val = __raw_readl(pdata->deepsleep_reg);
		val &= ~(0x80000000);
		__raw_writel(val, pdata->deepsleep_reg);


		/* Clear PLLRST bit in  PLLCTL 0  */
		val = __raw_readl(pdata->cpupll_reg_base + PLLCTL);
		val &= ~PLLCTL_PLLRST;
		__raw_writel(val, pdata->cpupll_reg_base + PLLCTL);

		/* Clear PLLRST bit in  PLLCTL 1 */
		val = __raw_readl(pdata->ddrpll_reg_base + PLLCTL);
		val &= ~PLLCTL_PLLRST;
		__raw_writel(val, pdata->ddrpll_reg_base + PLLCTL);


		/* Clear PLLPWRDWN bit in  PLLCTL 0  */
		val = __raw_readl(pdata->cpupll_reg_base + PLLCTL);
		val &= ~PLLCTL_PLLPWRDN;
		__raw_writel(val, pdata->cpupll_reg_base + PLLCTL);

		/* Clear PLLPWRDWN bit in  PLLCTL 1  */
		val = __raw_readl(pdata->ddrpll_reg_base + PLLCTL);
		val &= ~PLLCTL_PLLPWRDN;
		__raw_writel(val, pdata->ddrpll_reg_base + PLLCTL);

		/* wait for CPU PLL reset */
		udelay(PLL_RESET_TIME);

		/* Set PLLRST bit in  PLLCTL 0 */
		val = __raw_readl(pdata->cpupll_reg_base + PLLCTL);
		val |= PLLCTL_PLLRST;
		__raw_writel(val, pdata->cpupll_reg_base + PLLCTL);

		/* Set PLLRST bit in  PLLCTL 1 */
		val = __raw_readl(pdata->ddrpll_reg_base + PLLCTL);
		val |= PLLCTL_PLLRST;
		__raw_writel(val, pdata->ddrpll_reg_base + PLLCTL);


		/* Wait for CPU PLL to lock */
		udelay(PLL_LOCK_TIME);

		/* Remove CPU PLL0 from bypass mode */
		val = __raw_readl(pdata->cpupll_reg_base + PLLCTL);
		val &= ~(PLLCTL_PLLENSRC);
		val |= PLLCTL_PLLEN;
		__raw_writel(val, pdata->cpupll_reg_base + PLLCTL);

		/* Remove CPU PLL1 from bypass mode */
		val = __raw_readl(pdata->ddrpll_reg_base + PLLCTL);
		val &= ~(PLLCTL_PLLENSRC);
		val |= PLLCTL_PLLEN;
		__raw_writel(val, pdata->ddrpll_reg_base + PLLCTL);


		//Enable clock to the SDRAM register

		val = __raw_readl(pdata->ddrpsc_reg_base);
		val |= (0x00000003);
		__raw_writel(val, pdata->ddrpsc_reg_base);


		//Set Reset PHY bit in DDR PHY  reset control register
		val = __raw_readl(pdata->ddr2_ctlr_base + 0x60);
		val |= (0x00000400);
		__raw_writel(val, pdata->ddr2_ctlr_base + 0x60);


		//Clear the MCLKSTOPEN bit in SDRCR
		val = __raw_readl(pdata->ddr2_ctlr_base + 0x0C);
		val &= ~(0x40000000);
		__raw_writel(val, pdata->ddr2_ctlr_base + 0x0C);


		//Clear the low power mode bit in SDRCR
		val = __raw_readl(pdata->ddr2_ctlr_base + 0x0C);
		val &= ~(0x80000000);
		__raw_writel(val, pdata->ddr2_ctlr_base + 0x0C);


}
Attached the text file to the thread which has the static void davinci_pm_suspend(void) function where the deepsleep enter and deepsleep exit is implemented. Looking at the  davinci_pm_suspend() function source code  this function is expected to run from internal memory(SRAM)but in my case this seems to be  not running from internal memory(SRAM)

 

On searching forums found sample code on how to link the code from SRAM.  Added the below line before  the davinci_pm_suspend() function definition.

#pragma CODE_SECTION(davinci_pm_suspend(), ".TI.ramfunc")

 

During the kernel Image compilation observed the warning : ignoring the #pragma CODE_SECTION.  Also the davinci_pm_suspend() function entry is missing from the system.map file.

Please share your thoughts on the same.

Regards,

Shyam G

 

  • 0
    TI__Guru**** 161600 points

    Hi,

    Is your kernel part of TI MCSDK Linux (I don't remember TI release with kernel 3.10)? Can you by any chance transition to Processor SDK Linux? Kernel 3.10 is quite outdated.

    Best Regards,
    Yordan

  • 0 in reply to Yordan Kovachev
    Intellectual 870 points

    Hi Yordan,

    Moving to latest Kernel is not required for us as we want this feature to be implemented as part of 3.10.12 kernel only

  • 0 in reply to GSK
    TI__Guru**** 161600 points

    Hi,

    Ok, you should know that pragmas are specific to the toolchain, see gcc documentation:
      

    Let me check further for options how to link code to internal memory in linux kernel.

    Best Regards,
    Yordan

  • 0 in reply to Yordan Kovachev
    Intellectual 870 points

    we use the GCC complier and the target attribute is not supported on the machine warning is observed when I add the text before my function

    __attribute__((target("arch=arm))) 

  • 0 in reply to GSK
    TI__Expert 6385 points

    Hi,

    Do note that code in arch/arm/mach-davinci/sleep.S is not linked into internal RAM. but copied over into it.

    In arch/arm/mach-davinci/pm.c, davinci_sram_suspend is a function pointer that is allocated on SRAM

    static void (*davinci_sram_suspend) (struct davinci_pm_config *);

davinci_sram_suspend = sram_alloc(davinci_cpu_suspend_sz, NULL);

    Then the code in sleep.S is copied over into it.

    davinci_sram_push(davinci_sram_suspend, davinci_cpu_suspend,
					davinci_cpu_suspend_sz);

    Finally during suspend call, you simply jump into the SRAM location allocated to you:

    	/* Configure sleep count in deep sleep register */
	val = __raw_readl(pm_config.deepsleep_reg);
	val &= ~DEEPSLEEP_SLEEPCOUNT_MASK,
	val |= pm_config.sleepcount;
	__raw_writel(val, pm_config.deepsleep_reg);

	/* System goes to sleep in this call */
	davinci_sram_suspend(&pm_config);

    This work because code in sleep.S is carefully written to be relocatable.

  • 0 in reply to Sekhar Nori
    Intellectual 870 points

    Hi Sekhar,

    Thank you for the reply.

    My requirement is to wake the OMAPL138  custom device from the deepsleep mode using the deepsleep pin by driving the deepsleep pin using external signal.

    As per your comments In order to achieve deepsleep wakeup using external signal  i should  write the assembly code for the same in sleep.S file instead of pm.c

    Do you have any pointers or references on how to implement the deepsleep wakeup using external signal in the Sleep.S file for OMAPL138.

    Please find the complete summary of my  previous query for deepsleep below

    https://e2e.ti.com/support/processors/f/791/t/803405

    Regards,

    Shyam 

  • 0 in reply to Sekhar Nori
    Intellectual 870 points

    Hi Shekar,

    Need your support in implementing the deepsleep wakeup using the deepsleep pin by driving it using the external signal. 

    I am novice to assemly language coding .

    Do you have any pointers or references  which could be helpful on how to implement the deepsleep wakeup using external signal in the Sleep.S file for OMAPL138.

    Regards,

    Shyam 

  • 0 in reply to GSK
    TI__Guru*** 125430 points

    Shyam,

    I'm back from vacation, and so I've been catching up on your previous thread and this thread.  Good comments from Sekhar regarding the mechanism by which the device goes to sleep.  One area in particular that I think I misconstrued previously related to precisely which code should be executing from internal SRAM.  Initially my thought was that the davinci_pm_suspend function should be executing from internal SRAM.  On reviewing everything again, I see that's not the case.  The davinci_pm_suspend function is only touching the CPU PLL, and that can happen from internal or external RAM.

    Along similar lines, I made a note in the previous thread that I didn't see the code that handles the DDR PLL.  Sekhar gave me the missing piece in that respect, i.e. I needed to look at the davinci_cpu_suspend function inside arch/arm/mach-davinci/sleep.S.  I see that function is handling the suspend/resume of the DDR controller and the DDR PLL.

    In summary:

    1. You made some changes to davinci_pm_suspend where you attempted to add some of the DDR handling.  Please revert those changes.  They are already being done by davinci_cpu_suspend.
    2. Can you please try stepping into davinci_cpu_suspend with JTAG?  Another option might be to add an assembly spin loop in davinci_cpu_suspend.  Once you get there, I'd like you to look at the Program Counter address to verify you're in internal RAM.
    3. Another test is it put an assembly spin loop after the "Wake up from sleep" comment in davinci_cpu_suspend.
      1. For starters, do NOT connect any JTAG.  I want you to get the OMAP-L138 fully to sleep.
      2. Wake up the device.  It should stick in the assembly spin loop in internal RAM.
      3. Connect with JTAG.  Verify you're in the assembly spin loop in davinci_cpu_suspend.

    I think you can add a spin look by doing something like:

    spin: b spin

    Best regards,
    Brad

  • 0 in reply to Brad Griffis
    TI__Guru*** 125430 points

    Shyam,

    In a separate email on this topic Sekhar made another good point.  Specifically, this relates to the TRM Section 10.10.1 Entering/Exiting Deep Sleep Mode Using Externally Controlled Wake-Up.  There's an extra step in the case that you're controlling the pin externally, i.e. step 11 is that you need to poll the SLEEPCOMPLETE bit.

    I've not tested this, but I think it should look approximately like this:

    diff --git a/arch/arm/mach-davinci/sleep.S b/arch/arm/mach-davinci/sleep.S
    index cd350dee4df..13e07d8eb44 100644
    --- a/arch/arm/mach-davinci/sleep.S
    +++ b/arch/arm/mach-davinci/sleep.S
    @@ -35,6 +35,7 @@
    #define PLL_LOCK_CYCLES (PLL_LOCK_TIME * 25)

    #define DEEPSLEEP_SLEEPENABLE_BIT BIT(31)
    +#define DEEPSLEEP_SLEEPCOMPLETE_BIT BIT(30)

    .text
    /*
    @@ -108,6 +109,12 @@ ENTRY(davinci_cpu_suspend)
    /* System goes to sleep beyond after this instruction */
    str ip, [r4]

    + /* Poll for SLEEPCOMPLETE */
    +5: ldr ip, [r4]
    + and ip, ip, #DEEPSLEEP_COMPLETE_BIT
    + cmp ip, #0
    + beq 5b
    +
    /* Wake up from sleep */

    /* Clear sleep enable */

    Best regards,
    Brad

  • 0 in reply to Brad Griffis
    Intellectual 870 points

    Hi Brad,

    Please find my reply below.

    1. You made some changes to davinci_pm_suspend where you attempted to add some of the DDR handling.  Please revert those changes.  They are already being done by davinci_cpu_suspend.

    [shyam] Reverted back all the code changes which were done earlier. I have only changed the MUX CFG for PINMUX0 register offset 28-31 to value 0 such that the deepsleep pin functionality is selected. This change is done in da850.c. Earlier the offset value was set to use the RTC ALARM functionality.

    2. Can you please try stepping into davinci_cpu_suspend with JTAG?  Another option might be to add an assembly spin loop in davinci_cpu_suspend.  Once you get there, I'd like you to look at the Program Counter address to verify you're in internal RAM

    [Shyam] Added the spinloop entry  just before the section /******** Switch DDR to Self Refresh mode *****/ in the davinci_cpu_suspend  function in sleep. S code.  With JTAG connected upon doing echo mem > /sys/power/state observed that the device entered the deepsleep mode where USB and Ethernet ports stopped working but observed that program counter value is showing up as 0xCXXXXXXX. The PC is not pointing to the internal RAM.

    Another test is it put an assembly spin loop after the "Wake up from sleep" comment in davinci_cpu_suspend.

    1. For starters, do NOT connect any JTAG.  I want you to get the OMAP-L138 fully to sleep.
    2. Wake up the device.  It should stick in the assembly spin loop in internal RAM.
    3. Connect with JTAG.  Verify you're in the assembly spin loop in davinci_cpu_suspend.

    [Shyam] Observed that device is not waking up from deepsleep mode upon driving the Deepsleep pin high using external signal. With JTAG connected the PC is pointing to address 0xCXXXXXXX

    Note:

    I have added the code code in the sleep.s  for sleepcomplete polling and also have added  spin loop after the "Wake up from sleep" comment in davinci_cpu_suspend. Also added the code for sleepcomplete polling.

    Attached the snapshot caotured incase of point 3. Please share on how to proceed further on this issue

  • 0 in reply to GSK
    TI__Guru*** 125430 points

    Shyam G said:
    [Shyam] Added the spinloop entry  just before the section /******** Switch DDR to Self Refresh mode *****/ in the davinci_cpu_suspend  function in sleep. S code.  With JTAG connected upon doing echo mem > /sys/power/state observed that the device entered the deepsleep mode where USB and Ethernet ports stopped working but observed that program counter value is showing up as 0xCXXXXXXX. The PC is not pointing to the internal RAM.

    Can you post a snippet of exactly what you added?  I wasn't expecting the device to go to sleep.  That shouldn't be possible if SLEEPENABLE=0.  Is there code somewhere that's configuring SLEEPENABLE=1 prior to your spin loop?

    How are you synchronizing the external signal with the code?  In other words, how does that signal know when the time is right to assert and deassert?

  • 0 in reply to Brad Griffis
    Intellectual 870 points

    Hi Brad,

    In the pm.c  file , with in the function the davinci_pm_Suspend() function the CPUPLL is set to bypass mode and PLL0 is powered down. and after this line the davinci_sram_suspend(pdata) is called. attached the screenshot for the PLL0 register captured after doing echo mem > /sys/power state with spinlock as mentioned in  sleep.S code attached.

    Attached the sleep.S to the thread with changes for sleep complete poll and  spinlock .

    The below code change is added for Deepsleep selection using the PINMUX0 Register. 

    MUX_CFG(DA850, RTC_ALARM, 0, 28, 15, 0, false).4604.sleep.S

    Regards,

    Shyam G

  • 0 in reply to Brad Griffis
    Intellectual 870 points

    Hi Brad,

    In the pm.c  file , with in the function the davinci_pm_Suspend() function the CPUPLL is set to bypass mode and PLL0 is powered down. and after this line the davinci_sram_suspend(pdata) is called. attached the screenshot for the PLL0 register captured after doing echo mem > /sys/power state with spinlock as mentioned in  sleep.S code attached.

    Attached the sleep.S to the thread with changes for sleep complete poll and  spinlock .

    The below code change is added for Deepsleep selection using the PINMUX0 Register. 

    MUX_CFG(DA850, RTC_ALARM, 0, 28, 15, 0, false).4062.sleep.S

    Regards,

    Shyam G

  • 0 in reply to GSK
    TI__Guru*** 125430 points

    Shyam -- if we cannot put a spin loop in the code and actually land there, I don't see how we can debug any further.  That's not something I can easily debug over a forum.  I really need you and your co-workers to figure that out, so we can proceed with debugging.  Are you able to hit a spin loop in the C code, i.e. in davinci_pm_suspend?  If so, can you step into the assembly code from there? 

  • 0 in reply to Brad Griffis
    Intellectual 870 points

    Hi Brad,

    The spin loopi,e while(1) is working in the davinci_pm_suspend() i am  using a volatile variable to break from the loop by setting the value 1 using the memory browser in CCS .

    I have put a spin loop just before calling the davinci_sram_Suspend(pdata) in the davinci_pm_suspend()  function. The moment i step over the line it is again pointing to 0xCxxxxxxxx.

    Also using mem browser when see the below address when i,m trying to see the 0x80000000:    ???? Page fault occurred reading 0x80000000 [code=0x6]

    Regards,

    Shyam G

  • 0 in reply to GSK
    TI__Guru*** 125430 points

    When you get to the davinci_pm_suspend() function, go to the disassembly window and use the "assembly step into" button in order to get into the assembly code.

  • 0 in reply to Brad Griffis
    Intellectual 870 points

    Hi Brad,

    Attached the screenshot just post exiting while loop before calling the davinci_sram_suspend(). Have done step into from 0xc001acdc and observed that the PC value is set to 0Xc001acdc and post that i dont see the code executing from SRAM . The address is always pointing to 0xcxxxxxxx.  Please share your comments.

  • 0 in reply to Brad Griffis
    Intellectual 870 points

    Hi Brad,

    Attached the screenshot just post exiting while loop before calling the davinci_sram_suspend(). Have done step into from 0xc001acdc and observed that the PC value is set to 0Xc001acdc and post that i dont see the code executing from SRAM . The address is always pointing to 0xcxxxxxxx.  Please share your comments.

  • 0 in reply to Brad Griffis
    Intellectual 870 points

    Hi Brad,

    Attached the screenshot just post exiting while loop before calling the davinci_sram_suspend(). Have done step into from 0xc001acdc and observed that the PC value is set to 0Xc001acdc and post that i dont see the code executing from SRAM . The address is always pointing to 0xcxxxxxxx.  Please share your comments.

  • 0 in reply to Brad Griffis
    Intellectual 870 points

    Hi Brad,

    The below function is supposed to jump the exection to SRAM

    davinci_sram_suspend(pdata);

    On the disassemble of the above function gives the below output

    I dont see any jump instrcution which enable the code to jump to any SRAM address. Please let me know if my understanding is correct.

    Regards,

    Shyam G

  • 0 in reply to Brad Griffis
    Intellectual 870 points

    Hi Brad,  

    on doing the step into using the JTAG over CCS the code is executing from 0xc884400 when we jump to code mentioned below.

    In the pm.c file on calling the sram_alloc(davinci_cpu_suspend_sz, NULL); the address  is 0xc8844000.

    Attached the code snippet below for your reference.

    davinci_sram_suspend = sram_alloc(davinci_cpu_suspend_sz, NULL);
    dev_err(&pdev->dev, "SRAM memory Address is %lx", (long unsigned int)davinci_sram_suspend);


    In an ideal case scenario the Sram_alloc() function should have returned address value in the address space (0x80000000 --------------- 0x8001FFFF 128K Shared RAM).

    Instead we have received a address value of 0xC8844000 which falls in the address range ( 0xC0000000 ----------- 0xCFFFFFFF 256M DDR2/mDDR Data).
    This could be reason for the address value showing up 0XCxxxxxx during the JTAG debugging when we call the davinci_sram_suspend(pdata).

    Also observed that in mach-davinci/sram.c file saw the below text before the sram_init().
    It mentions that doesn't yet support the holding code needed for enter and exit suspend states.
    Does this mean the SRAM allocation is not happening from SRAM area and instead it is happening frpm DDR2 area and am assuming this could be the reason for deepsleep not working as expected.
    Please share your comments on this.


    /*
    * REVISIT This supports CPU and DMA access to/from SRAM, but it
    * doesn't (yet?) support some other notable uses of SRAM: as TCM
    * for data and/or instructions; and holding code needed to enter
    * and exit suspend states (while DRAM can't be used).
    */
    static int __init sram_init(void)

  • 0 in reply to GSK
    TI__Guru*** 125430 points

    Shyam G said:

    Attached the code snippet below for your reference.

    davinci_sram_suspend = sram_alloc(davinci_cpu_suspend_sz, NULL);
    dev_err(&pdev->dev, "SRAM memory Address is %lx", (long unsigned int)davinci_sram_suspend);


    In an ideal case scenario the Sram_alloc() function should have returned address value in the address space (0x80000000 --------------- 0x8001FFFF 128K Shared RAM).

    Given the explanation from Sekhar earlier, I suspect this function is actually allocating the code in internal SRAM.  The address we're seeing is a virtual address, but the corresponding physical address likely is in the 0x80000000 vicinity.

    Shyam G said:
    /*
    * REVISIT This supports CPU and DMA access to/from SRAM, but it
    * doesn't (yet?) support some other notable uses of SRAM: as TCM
    * for data and/or instructions; and holding code needed to enter
    * and exit suspend states (while DRAM can't be used).
    */
    static int __init sram_init(void)

    That's a very old comment.  It looks out-dated, i.e. we did move some code into SRAM for suspend/resume.  I'm trying to get more information in terms of whether we have ever had this capability working in Linux.

    One other thing that I'm wondering about...  After a failed resume, you mentioned you can connect to the ARM right?  Normally the bottom bar of CCS shows whether the MMU is enabled or disabled.  Can you check the MMU status in the case of your failed wake-up?

  • 0 in reply to Brad Griffis
    Intellectual 870 points

    Hi Brad, 

    After a failed resume, you mentioned you can connect to the ARM right?

    [Shyam] I am able to connect to ATM

    Normally the bottom bar of CCS shows whether the MMU is enabled or disabled.  Can you check the MMU status in the case of your failed wake-up?

    [Shyam] The MMU is always enabled . Even in the case of failed wake up it is enabled.

    The SRAM memory virtual  Address is : c8844000   physical address: 80004000.

    We made  below code change to get  the physical address 

    dma_addr_t dma;

    davinci_sram_suspend = sram_alloc(davinci_cpu_suspend_sz, &dma);
    dev_err(&pdev->dev, "SRAM memory Address is %lx   physical address  is %lx", (long unsigned int)davinci_sram_suspend,  (long unsigned int)dma);

    Also observed that the disassembly code starting firm 0xC8844000 is not having any valid assembly code releated to deepsleep enter and exit . Attaching the snapshot captured with JTAG debugging. I am assuming the davinci_sram_push(davinci_sram_suspend,davinci_cpu_suspend, davinci_cpu_suspend_sz) is not copying the code to SRAM .

    Please share your comments on this

    Regards,

    Shyam G

  • 0 in reply to GSK
    TI__Guru*** 125430 points

    Shyam G said:

    The SRAM memory virtual  Address is : c8844000   physical address: 80004000.

    We made  below code change to get  the physical address 

    dma_addr_t dma;

    davinci_sram_suspend = sram_alloc(davinci_cpu_suspend_sz, &dma);
    dev_err(&pdev->dev, "SRAM memory Address is %lx   physical address  is %lx", (long unsigned int)davinci_sram_suspend,  (long unsigned int)dma);

    Great idea!  That confirms what I suspected related to difference in virtual/physical addresses.

    Shyam G said:
    Also observed that the disassembly code starting firm 0xC8844000 is not having any valid assembly code releated to deepsleep enter and exit .

    Can you confirm at what point you were looking at that memory?  Did you put a spinloop in the davinci_pm_suspend C code and look at the corresponding disassembly at that time? I just want to be sure you weren't connecting at a random time and looking at that area of memory.  Since the page tables change depending on context that mapping wouldn't always be valid.

    Can you look at that same memory through a memory window?  Does it also show as all zeros?  

    Another thought might be to put a spin loop before the davinci_sram_push function such that you can look at that address before/after the davinci_sram_push() call.  That would allow you to see whether it was relocating the code as expected in the first place.  Perhaps there is code elsewhere that is zeroing out that SRAM, etc.

  • 0 in reply to Brad Griffis
    TI__Guru*** 125430 points

    Update:  I had some offline discussion with Shyam as there was some issue with the forum.

    Looks like immediately following davinci_sram_push() the assembly code is viewed in the expected location.  By the time the sleep code runs, it shows as all zeros.  So it seems like something is Shyam's system is blasting that memory.  Another possibility might be if the MMU mappings changed.  You could check for that possibility by disabling the MMU while halted and then viewing the physical address in the window.

  • 0 in reply to Brad Griffis
    Intellectual 870 points

    Hi Brad,

    We also have the  DSP firmware running on our device.

     

    Currently we have  stopped loading the DSP firmware onto our device and observed that the  SRAM memory is not getting clobbered and with echo mem > /sys/power/state the device looks like entering the deepsleep mode .

     

    The ethernet port and the USB port on the device are not functional post the deepsleep. The ping to device is failing and the USB com port is not observed in the device manager.

     

    After driving the DEEPSLEEP pin using external signal the device woke up from deepsleep. That is the USB comport got enumerated and I am able to use the USB com port for configuration purpose.

     

    The Ethernet port on the device is not working post deepsleep wakeup .  The Software stack portion for Ethernet seems to be up. The ping to device is also not working.

     

    Can you please help us on why the ethernet might not be working. Attached the ifconfig coutput post the device wakeup from deepsleep

    Regards,

    Shyam G

  • 0 in reply to GSK
    TI__Guru 50170 points

    Hi, Shyam,

    I saw you have another thread for the Ethernet issue after waking up. I assume the original issue of this thread is resolved. Please click "Resolved" if it is the case. I'll close this thread for now.

    Rex