dm814x low power modes?

Daniel70334

Hello,

I'm trying to implement a low power mode for when our product goes idle. I still need the CPU, serial port, USB, and ethernet connection to be active, but I am trying to shut off everything else (M3, DSP, video pipeline).

I started by killing my app, and doing:

/etc/init.d/pvr-init stop
firmware_loader 0 /usr/share/ti/rpe/dm81xx_c6xdsp_debug.xe674 stop
/etc/init.d/load-hd-firmware.sh stop

But when I unloaded the RPE DSP firmware, I got:

# firmware_loader 0 /usr/share/ti/rpe/dm81xx_c6xdsp_debug.xe674 stop
FIRMWARE: I2cInit will be done by M3
FIRMWARE: Memory map bin file not passed
Usage : firmware_loader <Processor Id> <Location of Firmware> <start|stop> [-mmap <memory_map_file>] [-i2c <0|1>]
===Mandatory arguments===
<Processor Id> 0: DSP, 1: Video-M3, 2: Vpss-M3
<Location of Firmware> firmware binary file
<start|stop> to start/stop the firmware
===Optional arguments===
-mmap input memory map bin file name
-i2c 0: i2c init not done by M3, 1(default): i2c init done by M3
FIRMWARE: isI2cInitRequiredOnM3: 1
FIRMWARE: Default memory configuration is used
Firmware LAssertion at Line no: 1799 in /home/bob/ti-ezsdk_dm814x-evm_5_05_02_00/component-sources/syslink_2_20_02_20/packages/ti/syslink/utils/hlos/knl/Linux/../../../../../../ti/syslink/ipc/hlos/knl/MessageQ.c: (MessageQ_module->heaps [heapId] != NULL) : failed
oader debugging not configured
Default FL_DEBUG: warning
Allowed FL_DEBUG levels: error, warning, info, debug, log
MemCfg: DCMM (Dynamically Configurable Memory Map) Version : 2.1.2.1
FIRMWARE: 0 stop Successful

And when I check PM_ACTIVE_PWRSTST, it seems like the ACTIVE (DSP) power domain is still on:

# devmem2 0x48180A04 # ReadPM_ACTIVE_PWRSTST
/dev/mem opened.
Memory mapped at address 0x40172000.
Value at address 0x48180A04 (0x40172a04): 0x37

So I looked at some other stuff:

# devmem2 0x48180420 # Read CM_ACTIVE_GEM_CLKCTRL
/dev/mem opened.
Memory mapped at address 0x40129000.
Value at address 0x48180420 (0x40129420): 0x50000

STBYST = 1 ("Standby: Module is in standby"), but IDLEST = 1 ("Trans: Module is performing transition: wakeup, or sleep, or
sleep abortion"). It seems like some condition is not satisfied.

# devmem2 0x48180A10 # Read RM_ACTIVE_RSTCTRL
/dev/mem opened.
Memory mapped at address 0x4015d000.
Value at address 0x48180A10 (0x4015da10): 0x3

Warm and local resets are asserted, which I guess is okay.

# devmem2 0x48180A00 # Read PM_ACTIVE_PWRSTCTRL
/dev/mem opened.
Memory mapped at address 0x40158000.
Value at address 0x48180A00 (0x40158a00): 0x30000

PowerState = 0 ("OFF"), which I guess is good. Active_MEM_ONState = 3, which I cannot tell if this is good or bad.

Other info: it seems like SGX, ISP, and DSS were turned off successfully:

# devmem2 0x48180F04 # Read PM_SGX_PWRSTST
/dev/mem opened.
Memory mapped at address 0x400df000.
Value at address 0x48180F04 (0x400dff04): 0x0

# devmem2 0x48180804 # Read PM_ISP_PWRSTST
/dev/mem opened.
Memory mapped at address 0x404e8000.
Value at address 0x48180804 (0x404e8804): 0x0

# devmem2 0x48180D04 # Read PM_DSS_PWRSTST
/dev/mem opened.
Memory mapped at address 0x401bd000.
Value at address 0x48180D04 (0x401bdd04): 0x0

However, the HDVICP did not get shut off by these actions. I was able to turn it off based on info that I found in another e2e post with Pavel Botev:

devmem2 0x48180620 w 0 #CM_IVAHD0_CLKSTCRL
devmem2 0x48180624 w 0 #CM_IVAHD0_SL2_CLKCTRL
devmem2 0x48180600 w 1 #CM_IVAHD0_CLKSTCTRL
devmem2 0x48180C10 w 7 #RM_HDVICP_RSTCTRL
devmem2 0x48180C00 w 0 #PM_IVAHD0_PWRSTCTRL

So, my questions are:

Is there something needed before unloading the RPE DSP firmware to avoid the syslink assertion?
Is there something else needed to turn off the ACTIVE (DSP) power domain?
Is there a recommended way to turn off the HDVICP power domain, or should "load-hd-firmware.sh stop" have done it for me?

FYI, I am using ti-ezsdk_dm814x-evm_5_05_02_00.

Many thanks,
Dan -

over 12 years ago

0 Pavel Botev over 12 years ago

TI__Guru**** 170625 points

Hi Daniel,

Daniel70334 said:
Is there something needed before unloading the RPE DSP firmware to avoid the syslink assertion?

I am using the DM814x EVM, and I can unload the DSP firmware without any syslink error reporting. I am using EZSDK 5.05.02.00. See the log below:

Arago 2011.09 dm814x-evm ttyO0

dm814x-evm login: root
root@dm814x-evm:~# cd /usr/share/ti/rpe
root@dm814x-evm:/usr/share/ti/rpe# firmware_loader 0 dm81xx_c6xdsp_debug.xe674 start
FIRMWARE: I2cInit will be done by M3
FIRMWARE: Memory map bin file not passed
Usage : firmware_loader <Processor Id> <Location of Firmware> <start|stop> [-mmap <memory_map_file>] [-i2c <0|1>]
===Mandatory arguments===
<Processor Id>         0: DSP, 1: Video-M3, 2: Vpss-M3
<Location of Firmware> firmware binary file
<start|stop>           to start/stop the firmware
===Optional arguments===
-mmap                  input memory map bin file name
-i2c                   0: i2c init not done by M3, 1(default): i2c init done by M3
FIRMWARE: isI2cInitRequiredOnM3: 1
FIRMWARE: Default memory configuration is used
Firmware Loader debugging not configured
Default FL_DEBUG: warning
Allowed FL_DEBUG levels: error, warning, info, debug, log
MemCfg: DCMM (Dynamically Configurable Memory Map) Version : 2.1.2.1
FIRMWARE: 0 start Successful
root@dm814x-evm:/usr/share/ti/rpe# ./aacdec_a8host_debug.xv5T -i aacdectest.cfg
AAC decoder example
======================

Starting threads

Playback through Audio Driver...

Completed Decoding 433 frames of davinci.aac file.
Test completed
root@dm814x-evm:/usr/share/ti/rpe# cd
root@dm814x-evm:~# /etc/init.d/pvr-init stop
Stopping PVR
root@dm814x-evm:~# firmware_loader 0 /usr/share/ti/rpe/dm81xx_c6xdsp_debug.xe674 stop
FIRMWARE: I2cInit will be done by M3
FIRMWARE: Memory map bin file not passed
Usage : firmware_loader <Processor Id> <Location of Firmware> <start|stop> [-mmap <memory_map_file>] [-i2c <0|1>]
===Mandatory arguments===
<Processor Id>         0: DSP, 1: Video-M3, 2: Vpss-M3
<Location of Firmware> firmware binary file
<start|stop>           to start/stop the firmware
===Optional arguments===
-mmap                  input memory map bin file name
-i2c                   0: i2c init not done by M3, 1(default): i2c init done by M3
FIRMWARE: isI2cInitRequiredOnM3: 1
FIRMWARE: Default memory configuration is used
Firmware Loader debugging not configured
Default FL_DEBUG: warning
Allowed FL_DEBUG levels: error, warning, info, debug, log
MemCfg: DCMM (Dynamically Configurable Memory Map) Version : 2.1.2.1
FIRMWARE: 0 stop Successful
root@dm814x-evm:~#

Could you please provide full log (u-boor, kernel, filesystem). May be I can find something in your log that is causing this syslink error.

Can you try with the following sequence:

# firmware_loader 0 /usr/share/ti/rpe/dm81xx_c6xdsp_debug.xe674 stop

# /etc/init.d/pvr-init stop

# /etc/init.d/matrix-gui-e stop

# /etc/init.d/load-hd-firmware.sh stop

I will further investigate regarding #2 and #3 and provide you a feedback.

Pavel

0 Pavel Botev over 12 years ago

TI__Guru**** 170625 points

Daniel70334 said:
Is there something else needed to turn off the ACTIVE (DSP) power domain?

Daniel70334 said:
Is there a recommended way to turn off the HDVICP power domain, or should "load-hd-firmware.sh stop" have done it for me?

Can you check if the way below will work for you

http://processors.wiki.ti.com/index.php/DM814x_AM387x_PM_Suspend_resume_overview#Turn_OFF_Power_domains

Pavel

0 Daniel70334 over 12 years ago in reply to Pavel Botev

Expert 1745 points

Pavel,

First, thank you for responding.

Pavel Botev said:

root@dm814x-evm:~# cd /usr/share/ti/rpe
root@dm814x-evm:/usr/share/ti/rpe# firmware_loader 0 dm81xx_c6xdsp_debug.xe674 start
FIRMWARE: I2cInit will be done by M3

We were adding "-i2c 0" to the firmware_loader line. Is that not correct?

(I tried removing it, but I got same error as before.)

Pavel Botev said:

Could you please provide full log (u-boor, kernel, filesystem). May be I can find something in your log that is causing this syslink error.

See attached.

Pavel Botev said:

Can you try with the following sequence:

# firmware_loader 0 /usr/share/ti/rpe/dm81xx_c6xdsp_debug.xe674 stop

# /etc/init.d/pvr-init stop

# /etc/init.d/matrix-gui-e stop

# /etc/init.d/load-hd-firmware.sh stop

Interesting. Normally, I stop my OMX+RPE application first, then do the firmware_loader stop. When I do that, the syslink error happens during the second step, when I stop the DSP. But then I tried stopping RPE before stopping my application, as you suggested. When RPE was stopped, I did not get any error. But then I got the syslink error on the second step - when I shut done my OMX+RPE app - I guess during Rpe_delete(), Rpe_deinit(), or System_procDeInit(). Did you expect that might be the case?

Pavel Botev said:

Is there something else needed to turn off the ACTIVE (DSP) power domain?

Daniel70334 said:
Is there a recommended way to turn off the HDVICP power domain, or should "load-hd-firmware.sh stop" have done it for me?

Can you check if the way below will work for you

http://processors.wiki.ti.com/index.php/DM814x_AM387x_PM_Suspend_resume_overview#Turn_OFF_Power_domains

[/quote]

I tried doing "echo 1 > /sys/kernel/debug/pm_debug/turnoff_idle_powerdomains" both before and after my running "load-hd-firmware.sh stop". Both ACTIVE and HDVICP power domains remained active (i.e., value was 0x37, not idle).

(Then I did the five devmem2 writes to power down HDVICP, as in my original post. HDVICP again went to idle, while ACTIVE did not. So, really, no change from before.)

0 Pavel Botev over 12 years ago in reply to Daniel70334

TI__Guru**** 170625 points

Daniel,

Daniel70334 said:
We were adding "-i2c 0" to the firmware_loader line. Is that not correct?

This parameter (-i2c) is used for :

-i2c 0: i2c init not done by M3, 1(default): i2c init done by M3

When you use "-i2c 0" I2C init is not done by Cortex-M3 (media controller) processor: FIRMWARE: isI2cInitRequiredOnM3: 0. This means that I2C can be used from the Cortex-A8/Linux. When "-i2c 1" or no parameter is used, the I2C can be used from the Cortex-M3.

I tried with "-i2c 0" option, it works also fine on my side. So this should not be an issue.

I found these two threads that seems related:

http://e2e.ti.com/support/embedded/linux/f/354/t/173761.aspx

http://e2e.ti.com/support/embedded/linux/f/354/p/214813/759796.aspx

Is it possible that you run CodecEngine/C6Run and OMX concurrently?

Can you check this wiki, please follow the exact steps/instructions: http://processors.wiki.ti.com/index.php/RPE_EZSDK_examples

Can you also run the Syslink/MessageQ and Codec Engine examples from the ti-ezsdk_dm814x-evm_5_05_02_00/docs/DM814x_EZ_Software_Developers_Guide.pdf, sections:

3.2 Running the SysLink examples
3.3 Running the Codec Engine examples

Do these Syslink/MessageQ and CodecEngine examples run fine and with no errors?

I will further check for the ACTIVE/DSP power down.

Regards,

Pavel

0 Pavel Botev over 12 years ago in reply to Pavel Botev

TI__Guru**** 170625 points

Daniel,

Regarding Active/DSP power off, I receive the following registers programming order:

PM_ACTIVE_PWRSTCTRL[1:0] -> 00

CM_GEM_CLKSTCTRL[1:0] -> 01

CM_ACTIVE_GEM_CLKCTRL[1:0] -> 00

DSP_IDLE_CFG[15] -> 1 (Part of control module)

The problem now is that DSP_IDLE_CFG register can be written only from privileged/supervisor mode, while we are in user mode. I will try to switch to privileged/supervisor mode and check if this sequence will result in DSP power off.

Regards,

Pavel

0 Daniel70334 over 12 years ago in reply to Pavel Botev

Expert 1745 points

Hi Pavel,

Pavel Botev said:

I found these two threads that seems related:

http://e2e.ti.com/support/embedded/linux/f/354/t/173761.aspx

http://e2e.ti.com/support/embedded/linux/f/354/p/214813/759796.aspx

Is it possible that you run CodecEngine/C6Run and OMX concurrently?

Can you check this wiki, please follow the exact steps/instructions: http://processors.wiki.ti.com/index.php/RPE_EZSDK_examples

CodecEngine? C6Run? Sorry, I don't understand these words. Are they used internally by RPE library, or syslink? We have a single application that uses OMX for video decoding and display, RPE for audio decoding, and ALSA for audio output. The RPE part is based on the aacdec_a8host_debug example, mentioned in the above wiki. So if aacdec uses CodecEngine, then perhaps we do as well.

The other posts indicate some problem in older EZSDK versions. We are using EZSDK 5_05_02_00. Does 5_05_02_00 support decoding audio with RPE library while simultaneously decoding and displaying video with OMX? It seems to work for us quite often - expect for that assertion.

Is there some change needed in EZSDK 5_05_02_00 for proper usage of RPE for audio decode and OMX for video decode?

Dan -

0 Pavel Botev over 12 years ago in reply to Daniel70334

TI__Guru**** 170625 points

Daniel,

No, I do not think CodecEngine/C6Run are used by RPE/AACDEC.

Daniel70334 said:
We have a single application that uses OMX for video decoding and display, RPE for audio decoding, and ALSA for audio output.

Could you please share with me this application, I want to run it on my own DM8148 EVM, to check if I will be able to reproduce this syslink error.

Regards,

Pavel

0 Daniel70334 over 12 years ago in reply to Pavel Botev

Expert 1745 points

Pavel,

I'm not sure that I am allowed to give you a proprietary application. Anyway, it seems unnecessary - I was able to reproduce this issue with normal EZSDK examples. I use the EZSDK's pre-built MLO / u-boot / uImage / rootfs images. Please try this procedure:

1. Start EVM as you would normally.

2. Wait for TI's Qt matrix app to start.

3. Load DSP code using the following lines:

# cd /usr/share/ti/rpe
# firmware_loader 0 ./dm81xx_c6xdsp_debug.xe674 start

4. Start video decode+display as background process:

# /usr/bin/runDecodeDisplayHDMI &

5. Start audio decode while video is still being decoded:

# ./aacdec_a8host_debug.xv5T -i aacdectest.cfg

6. Wait for video display to finish.

7. Attempt to stop DSP firmware:

# firmware_loader 0 /usr/share/ti/rpe/dm81xx_c6xdsp_debug.xe674 stop
FIRMWARE: I2cInit will be done by M3
FIRMWARE: Memory map bin file not passed
Usage : firmware_loader <Processor Id> <Location of Firmware> <start|stop> [-mmap <memory_map_file>] [-i2c <0|1>]
===Mandatory arguments===
<Processor Id> 0: DSP, 1: Video-M3, 2: Vpss-M3
<Location of Firmware> firmware binary file
<start|stop> to start/stop the firmware
===Optional arguments===
-mmap input memory map bin file name
-i2c 0: i2c init not done by M3, 1(default): i2c init done by M3
FIRMWARE: isI2cInitRequiredOnM3: 1
FIRMWARE: Default memory configuration is used
Firmware Loader debugging not configured
Default FL_DEBUG: warning
AllowAssertion at Line no: 1799 in /swcoe/sdk/cm/netra/arago-tmp/work/dm814x-evm-none-linux-gnueabi/ti-syslink-2_20_02_20-r1j/syslink_2_20_02_20/packages/ti/syslink/utils/hlos/knl/Linux/../../../../../../ti/syslink/ipc/hlos/knl/MessageQ.c: (MessageQ_module->heaps [heapId] != NULL) : failed
ed FL_DEBUG levels: error, warning, info, debug, log
MemCfg: DCMM (Dynamically Configurable Memory Map) Version : 2.1.2.1

Hopefully, you can see the same error.

Dan -

0 Pavel Botev over 12 years ago in reply to Daniel70334

TI__Guru**** 170625 points

Daniel,

Yes, I can reproduce the syslink error. I will check with the BIOS/Syslink team and with the SDK team for possible solution.

Regarding the write access to the DSP_IDLE_CFG[15] bit, the latest status is below. I am still trying the proposed solution.

You can define these in your assembly code and export and use in your ‘c’ code.

INT_SetSupervisor should set processor to supervisor mode, INT_SetUser should set it back to User mode. Kindly make sure when you go into supervisor, you exit it by calling user otherwise you would get into issues relating to stacks in user and svc modes.

INT_SetSupervisor

MOV R12,LR

SWI 0xFA

MOV LR,R12

BX LR

INT_SetUser

MOV R12,LR

SWI 0xFB

MOV LR,R12

BX LR

Regards,

Pavel

0 Pavel Botev over 12 years ago in reply to Pavel Botev

TI__Guru**** 170625 points

Daniel,

Regarding the syslink error, it seems that the “Firmware Loader” stop command is attempting to unregister a MessageQ heap but it has been given an invalid heapId to unregister thus the assertion. The "Firmware Loader" source code is located at:

ti-ezsdk_dm814x-evm_5_05_02_00/board-support/media-controller-utils_3_00_00_05/src/firmware_loader/firmware_loader.c

As this one is too abstracted from the hardware, and we are in the DM814x hardware forum, I would recommend you to check for further support in the Linux software forum:

http://e2e.ti.com/support/embedded/linux/default.aspx

We have currently lack of resources but I hope you will find some answers there.

Regards,

Pavel

0 Pavel Botev over 12 years ago in reply to Pavel Botev

TI__Guru**** 170625 points

Daniel,

I see that our BIOS team helped to resolve the syslink assertion issue, in the below thread:

http://e2e.ti.com/support/embedded/bios/f/355/p/263741/929090.aspx

But, this is not resolving the DSP power off issue.

For DSP power off, could you try the following:

1. Modify ti-ezsdk_dm814x-evm_5_05_02_00/component-sources/syslink_2_20_02_20/packages/ti/syslink/family/common/ti81xx/ti81xxdsp/Dm8168DspPwr.c file as:

/*!
* @brief      Function to power off the slave processor.
*
*              Turn the IVA power domain off. To ensure a clean power-off
*              transition, the IVA subsystem must first be turned on so that
*              the DSP can initiate an autonomous power-off transition.
*
* @param      handle    Handle to the PwrMgr instance
* @param      force     Indicates whether power-off is to be forced
*
* @sa         DM8168DSPPWR_on
*/
Int DM8168DSPPWR_off (PwrMgr_Handle handle, Bool force)
{

.....

/* assert DSP standby, removed to fix DSP internal memory load, -rams */

//REG(object->controlVA + DSP_IDLE_CFG) |= 0x8000;

REG(object->controlVA + DSP_IDLE_CFG) &= 0xFFFFFFCF; // DSP_IDLE_CFG[5:4] STBYMODE = 0x0 -> Force-standby mode

/* Disable GEM clocks */
            if(object->dspClkHandle) {
                ClockOps_disable(object->clockHandle, object->dspClkHandle);
                ClockOps_put(object->clockHandle, object->dspClkHandle);
            }

2. Build new syslink.ko file

~/ti-ezsdk_dm814x-evm_5_05_02_00$ make syslink

3. Replace the existing syslink.ko file with the newly generated syslink.ko file

If using MMC/SD card file system, the old syslink.ko file is located at /media/ROOTFS/lib/modules/2.6.37/kernel/drivers/dsp/

The new syslink.ko file is located at ti-ezsdk_dm814x-evm_5_05_02_00/component-sources/syslink_2_20_02_20/packages/ti/syslink/bin/TI814X/

4. Run the system

root@dm814x-evm:/usr/share/ti/rpe# firmware_loader 0 dm81xx_c6xdsp_debug.xe674 stop
FIRMWARE: I2cInit will be done by M3
FIRMWARE: Memory map bin file not passed
Usage : firmware_loader <Processor Id> <Location of Firmware> <start|stop> [-mmap <memory_map_file>] [-i2c <0|1>]
===Mandatory arguments===
<Processor Id>         0: DSP, 1: Video-M3, 2: Vpss-M3
<Location of Firmware> firmware binary file
<start|stop>           to start/stop the firmware
===Optional arguments===
-mmap                  input memory map bin file name
-i2c                   0: i2c init not done by M3, 1(default): i2c init done by M3
FIRMWARE: isI2cInitRequiredOnM3: 1
FIRMWARE: Default memory configuration is used
Firmware Loader debugging not configured
Default FL_DEBUG: warning
Allowed FL_DEBUG levels: error, warning, info, debug, log
MemCfg: DCMM (Dynamically Configurable Memory Map) Version : 2.1.2.1
FIRMWARE: 0 stop Successful
root@dm814x-evm:/usr/share/ti/rpe# devmem2 0x4814061C
/dev/mem opened.
Memory mapped at address 0x4027d000.
Read at address 0x4814061C (0x4027d61c): 0x00000008
root@dm814x-evm:/usr/share/ti/rpe# devmem2 0x48180A04
/dev/mem opened.
Memory mapped at address 0x402ff000.
Read at address 0x48180A04 (0x402ffa04): 0x00000037
root@dm814x-evm:/usr/share/ti/rpe# devmem2 0x48180A10 w 0x0
/dev/mem opened.
Memory mapped at address 0x40275000.
Read at address 0x48180A10 (0x40275a10): 0x00000003
Write at address 0x48180A10 (0x40275a10): 0x00000000, readback 0x00000000
root@dm814x-evm:/usr/share/ti/rpe# devmem2 0x48180A04
/dev/mem opened.
Memory mapped at address 0x4025c000.
Read at address 0x48180A04 (0x4025ca04): 0x00000000
root@dm814x-evm:/usr/share/ti/rpe#

The new step here is devmem2 0x48180A10 w 0x0, after it DSP is power off.

Best regards,
Pavel

0 Daniel70334 over 12 years ago in reply to Pavel Botev

Expert 1745 points

Pavel,

Pavel Botev said:

I see that our BIOS team helped to resolve the syslink assertion issue, in the below thread:

Yes, the BIOS team was able to give me a patch so that the RPE+firmware_loader does not conflict with OMX. Thanks!

Pavel Botev said:

For DSP power off, could you try the following: ...

I added the extra line to syslink, and tried it with the extra "devmem2 0x48180A10 w 0x0" step. The DSP did indeed go to a powered down state, which is good. However, firmware_loader hanged up when I tried to come back on again. (It seems to give up after four or five minutes.) Here's what I got:

# cd /usr/share/ti/rpe/
#
# firmware_loader 0 dm81xx_c6xdsp_debug.xe674 stop
FIRMWARE: I2cInit will be done by M3
FIRMWARE: Memory map bin file not passed
FIRMWARE: isI2cInitRequiredOnM3: 1
FIRMWARE: Default memory configuration is used
Firmware Loader debugging not configured
Default FL_DEBUG: warning
Allowed FL_DEBUG levels: error, warning, info, debug, log
MemCfg: DCMM (Dynamically Configurable Memory Map) Version : 2.1.2.1
--- DSP_IDLE_CFG[5:4] STBYMODE = 0x0 -> Force-standby mode ---
FIRMWARE: [ MessageQ_unregisterHeap(3) returned 0(S_SUCCESS) ]
FIRMWARE: 0 stop Successful
#
# devmem2 0x48180A04 # Read PM_ACTIVE_PWRSTST
/dev/mem opened.
Memory mapped at address 0x403ff000.
Value at address 0x48180A04 (0x403ffa04): 0x37
#
# devmem2 0x48180A10 wr 0
/dev/mem opened.
Memory mapped at address 0x403b3000.
Value at address 0x48180A10 (0x403b3a10): 0x3
Written 0x0; readback 0x0
#
# devmem2 0x48180A04 # Read PM_ACTIVE_PWRSTST
/dev/mem opened.
Memory mapped at address 0x403fb000.
Value at address 0x48180A04 (0x403fba04): 0x0
#
# time firmware_loader 0 ./dm81xx_c6xdsp_debug.xe674 start
FIRMWARE: I2cInit will be done by M3
FIRMWARE: Memory map bin file not passed
FIRMWARE: isI2cInitRequiredOnM3: 1
FIRMWARE: Default memory configuration is used
Firmware Loader debugging not configured
Default FL_DEBUG: warning
Allowed FL_DEBUG levels: error, warning, info, debug, log
MemCfg: DCMM (Dynamically Configurable Memory Map) Version : 2.1.2.1
FIRMWARE: Ipc_CONTROLCMD_STARTCALLBACK Error: ProcMgr status 0xffffffff
FIRMWARE: Could not start: -1
Command exited with non-zero status 255
real 5m 0.77s
user 0m 0.00s
sys 1m 0.25s

Are you able to restart the DSP with the syslink mod?

Dan -

0 Pavel Botev over 12 years ago in reply to Daniel70334

TI__Guru**** 170625 points

Daniel,

Daniel70334 said:
Are you able to restart the DSP with the syslink mod?

No, I have the same hang up as you.

Can you try to modify the Dm8168DspPwr.c file as:

/*!
* @brief      Function to power on the slave processor.
*
*              Power on the IVA subsystem, hold the DSP and SEQ in reset, and
*              release IVA2_RST. This is a hostile reset of the IVA. If the IVA
*              is already powered on, then it must be powered off in order to
*              terminate all current activity and initiate a power-on-reset
*              transition to bring the IVA to a know good state.
*
* @param      handle    Handle to the PwrMgr instance
*
* @sa         DM8168DSPPWR_off
*/
Int DM8168DSPPWR_on (PwrMgr_Handle handle)
{

......

/* Warm Reset to access Internal RAM of DSP - to access internal RAM */
            //REG((object->prcmVA) + RM_ACTIVE_RSTCTRL) = 0x01;
        REG(object->controlVA + DSP_IDLE_CFG) |= 0x00000020; // [5:4] STBYMODE = 0x2 -> Smart-standby mode

        }

....

Then create new syslink.ko file and use it. This is working on my side:

dm814x-evm login: root
root@dm814x-evm:~# cd /usr/share/ti/rpe/
root@dm814x-evm:/usr/share/ti/rpe# firmware_loader 0 dm81xx_c6xdsp_debug.xe674 start
FIRMWARE: I2cInit will be done by M3
FIRMWARE: Memory map bin file not passed
Usage : firmware_loader <Processor Id> <Location of Firmware> <start|stop> [-mmap <memory_map_file>] [-i2c <0|1>]
===Mandatory arguments===
<Processor Id>         0: DSP, 1: Video-M3, 2: Vpss-M3
<Location of Firmware> firmware binary file
<start|stop>           to start/stop the firmware
===Optional arguments===
-mmap                  input memory map bin file name
-i2c                   0: i2c init not done by M3, 1(default): i2c init done by M3
FIRMWARE: isI2cInitRequiredOnM3: 1
FIRMWARE: Default memory configuration is used
Firmware Loader debugging not configured
Default FL_DEBUG: warning
Allowed FL_DEBUG levels: error, warning, info, debug, log
MemCfg: DCMM (Dynamically Configurable Memory Map) Version : 2.1.2.1
FIRMWARE: 0 start Successful
root@dm814x-evm:/usr/share/ti/rpe# firmware_loader 0 dm81xx_c6xdsp_debug.xe674 stop
FIRMWARE: I2cInit will be done by M3
FIRMWARE: Memory map bin file not passed
Usage : firmware_loader <Processor Id> <Location of Firmware> <start|stop> [-mmap <memory_map_file>] [-i2c <0|1>]
===Mandatory arguments===
<Processor Id>         0: DSP, 1: Video-M3, 2: Vpss-M3
<Location of Firmware> firmware binary file
<start|stop>           to start/stop the firmware
===Optional arguments===
-mmap                  input memory map bin file name
-i2c                   0: i2c init not done by M3, 1(default): i2c init done by M3
FIRMWARE: isI2cInitRequiredOnM3: 1
FIRMWARE: Default memory configuration is used
Firmware Loader debugging not configured
Default FL_DEBUG: warning
Allowed FL_DEBUG levels: error, warning, info, debug, log
MemCfg: DCMM (Dynamically Configurable Memory Map) Version : 2.1.2.1
FIRMWARE: 0 stop Successful
root@dm814x-evm:/usr/share/ti/rpe# devmem2 0x4814061C
/dev/mem opened.
Memory mapped at address 0x402dd000.
Read at address 0x4814061C (0x402dd61c): 0x00000008
root@dm814x-evm:/usr/share/ti/rpe# devmem2 0x48180A04
/dev/mem opened.
Memory mapped at address 0x40229000.
Read at address 0x48180A04 (0x40229a04): 0x00000037
root@dm814x-evm:/usr/share/ti/rpe# devmem2 0x48180A10 w 0x0
/dev/mem opened.
Memory mapped at address 0x4034b000.
Read at address 0x48180A10 (0x4034ba10): 0x00000003
Write at address 0x48180A10 (0x4034ba10): 0x00000000, readback 0x00000000
root@dm814x-evm:/usr/share/ti/rpe# devmem2 0x48180A04
/dev/mem opened.
Memory mapped at address 0x402d0000.
Read at address 0x48180A04 (0x402d0a04): 0x00000000
root@dm814x-evm:/usr/share/ti/rpe# firmware_loader 0 dm81xx_c6xdsp_debug.xe674 start
FIRMWARE: I2cInit will be done by M3
FIRMWARE: Memory map bin file not passed
Usage : firmware_loader <Processor Id> <Location of Firmware> <start|stop> [-mmap <memory_map_file>] [-i2c <0|1>]
===Mandatory arguments===
<Processor Id>         0: DSP, 1: Video-M3, 2: Vpss-M3
<Location of Firmware> firmware binary file
<start|stop>           to start/stop the firmware
===Optional arguments===
-mmap                  input memory map bin file name
-i2c                   0: i2c init not done by M3, 1(default): i2c init done by M3
FIRMWARE: isI2cInitRequiredOnM3: 1
FIRMWARE: Default memory configuration is used
Firmware Loader debugging not configured
Default FL_DEBUG: warning
Allowed FL_DEBUG levels: error, warning, info, debug, log
MemCfg: DCMM (Dynamically Configurable Memory Map) Version : 2.1.2.1
FIRMWARE: 0 start Successful
root@dm814x-evm:/usr/share/ti/rpe# devmem2 0x48180A04
/dev/mem opened.
Memory mapped at address 0x402f3000.
Read at address 0x48180A04 (0x402f3a04): 0x00000037

Best regards,
Pavel

0 Daniel70334 over 12 years ago in reply to Pavel Botev

Expert 1745 points

Pavel,

Yes, adding your second mod to syslink allowed me to power down the DSP (after doing devmem2 0x48180A10 wr 0), and successfully wake it up again. Thanks!

One quick followup: when I power up the DSP again, should I restore the 3 to 0x48180A10 (RM_ACTIVE_RSTCTRL)? It seems to work okay without doing so, but I wanted to double check.

Thanks a lot,

Dan -

0 Pavel Botev over 12 years ago in reply to Daniel70334

TI__Guru**** 170625 points

Daniel,

No, I do not think you should restore the 0x3 to the RM_ACTIVE_RSTCTRL register manually. If doing so, you will initiate new DSP reset assertion. This is what we have in the DM814x TRM:

2.7.23 C674x DSP Power-On Reset Sequence

The POR sequence is:
• The PRCM module releases GEM_POR when the reset manager counter (PRM_RSTTIME[14:10]RSTTIME2) reaches its limit.
• The MPU software clears the RM_ACTIVE_RSTCTRL[1] GEM_SW_RST bit in the PRCM module register to release the DSP, MMU, and CACHE interface from reset.
• Once the reset manager counter (PRM_RSTTIME[14:10] RSTTIME2) expires, the PRCM module releases the GEM_GRST signal.
On deassertion of the GEM_GRST signal, the C674x subsystem starts the initialization sequence. During the initialization sequence all the internal registers inside the C674x subsystem are properly reset and the reset for the DSP, MMU, and CACHE interface completes.
The MPU software must configure the MMU once the MMU is out of reset. After the MMU is configured, the MPU software clears the RM_ACTIVE_RSTCTRL[0] GEM_LRST bit in the PRCM module register.

The PRCM module releases GEM_LRST, which causes the DSP to start booting.

2.7.24 C674x DSP Warm Reset Sequence

The sequence is:
1. The MPU software sets the RM_ACTIVE_RSTCTRL[1] GEM_SW_RST and RM_ACTIVE_RSTCTRL[0] GEM_LRST bits.
2. The PRCM module asserts the GEM_GRST and GEM_LRST reset signals.GEM_POR remains deasserted in this case.
3. The MPU software re-enables the C674x DSP Clocks and clears the RM_ACTIVE_RSTCTRL[1] GEM_SW_RST bit in the PRCM module register to reset the DSP, MMU, and CACHE interface. The DSP subsystem starts the partial initialization sequence for the warm reset.
4. The MPU software clears the RM_ACTIVE_RSTCTRL[0] GEM_LRST bit in the PRCM module register.
5. The PRCM module releases GEM_LRST, which causes the DSP to start booting.

BR
Pavel

Processors

Processors forum

dm814x low power modes?