HDVICP & HDVPSS fails to start after watchdog reset kickoff

Hello,

Did you follow this guide:

http://processors.wiki.ti.com/index.php?title=TI81XX_PSP_WDT_Support#Board_Modification

More to that, according to DM816x TRM, Table 18-28. Reset Sources Overview, MPU WD reset is NOT source for the DSS_M3_PWRN_RST (HDVPSS), IVAHD0_PWRN_RST (HDVICP2_0), IVAHD1_PWRN_RST (HDVICP2_1), IVAHD2_PWRN_RST (HDVICP2_2)

The Watchdog reset is Warm reset: it is a partial reset which doesn’t affect all the logic in a given entity.

Warm reset types are not necessarily applied globally within each receiving entity. A module may use a warm reset to reset a subset of its logic. This is often done to speed-up reset recovery time, that is, the time to transition to a safe operating state, compared to the time required upon receipt of a cold reset.

For SW reset, check DM816x TRM, section 18.5.8 HDVICP2 Software Warm Reset Sequence

BR,

Pavel

Hi Pavel,

Thank you for your quick response.

Coming to http://processors.wiki.ti.com/index.php?title=TI81XX_PSP_WDT_Support#Board_Modification. We can't use WD_OUT now as it is not floated on our custom board. Since boards are already in field. How we can achieve cold reset of the device including M3 cores (same like power_on_reset or reset button press)?

when we use ./watchdog -t 12 apps.

Thanks

Sada

You can try with the PRM_RSTCTRL[1] RST_GLOBAL_COLD_SW - when set to 0x1 - Asserts a global COLD software reset. The software must ensure the SDRAM is properly put in sef-refresh mode before applying this reset.

Also pay attention to the PRM_RSTTIME[7:0] RSTTIME1 and PRM_RSTST[0] GLOBAL_COLD_RST bits.

Cold (POR - Power On Reset) reset: it affects all the logic in a given entity
Global reset: it affects the entire device

Software reset: it is initiated by software

18.5.3 Global Power-On (Cold) Reset

The PRCM is required internally to generate the global power-on reset used by the domain Reset Managers from three cold reset sources: SYS_PWRN_RST, ICEPICK_POR_RST, GLOBAL_COLD_SW_RST.

Source GLOBAL_COLD_SW_RST is a PRM internally generated one. Activation is triggered upon setting PRM memory-mapped register bit, PRM_RSTCTRL.GLOBAL_COLD_SW_RST. This bit is self-clearing, it is automatically cleared by the hardware.

The PRCM must stall the release of the global power-on reset until after de-assertion of all cold reset sources and until after receiving indication that the voltage domains, have all ramped to their operating levels and until after receiving an indication that the system clock is running and is stable. The PRCM implements a counter after all of these indications have occurred to provide a delay before releasing internal global power on reset signals. This requires use of a PM FW Reset Manager. The "always-on" 27 MHz clock must run the RM's stall-period timer. The max count is provided by PRM register PRM_RSTTIME.RSTTIME1 bit-field. During device power-up, this mechanism enforces the system requirement of a running 27 MHz clock.

BR,

Pavel

Hello, Sada,

Could you give me more information about CONFIG_SOFT_WATCHDOG?

We have the same problem after watchdog reset, M3 firmware cant be loaded properly.

Hi Pavel,

According to hardware modify for WTD_OUT  , the watchdog reset process is cold reset  and it will be fully reset not partial reset?

So we could load M3 firmware properly after watchdog reset?

Any help will be highly appreciate!

thank you very much!

Steven

Hello,

Could someone give me some clue?

thanks a lot!!

Regards,

Steven

Hello,

I have change the kernel configure

CONFIG_SOFT_WATCHDOG=y
# CONFIG_OMAP_WATCHDOG is not set

watchdog reset is ok now!

thank you!

Steven

Hi, we really need to use the hardware watchdog since the software watchdog is not reliable enough for our mission-critical system.

How do you reset the HDVICP? We are trying to follow section 18.5.8 in the TRM but we haven't found success.

This is what we are doing in Linux before loading the HDVPSS and HDVICP firmware:

Here we go. The TRM says to do this:

Before asserting the software reset to the HDVICP2, the MPU software must ensure that:
a) The HDVICP2 sequencer CPUs are in IDLE state (CM_IVAHDi_IVAHD_CLKCTRL[17:16] IDLEST).
b) The HDVICP2 is in STANDBY state CM_IVAHDi_IVAHD_CLKCTRL[[18] STBYST).
c) The functional clock to the HDVICP2 has been gated by the PRCM module (CM_IVAHDi_CLKSTCTRL[8] CLKACTIVITY_IVAHD_CLK).

The software reset sequence occurs when the MPU software:
1. Sets the RM_IVAHDi_RSTCTRL[2] RST3, RM_IVAHDi_RSTCTRL[1] RST2, and RM_IVAHDi_RSTCTRL[0] RST1 bits. This causes the PRCM module to assert the IVAHDi_RST, IVAHDi_SEQ1_RST, and IVAHDi_SEQ2_RST resets to the HDVICP2. IVAHDi_PWRN_RST remains
deasserted.
2. Enables the functional clock to the HDVICP2.
3. clears the RM_IVAHDi_RSTCTRL[2] RST3 and RM_IVAHDi_RSTCTRL[0] RST1 bits. This causes the PRCM module to release the IVAHDi_RST and IVAHDi_SEQ1_RST resets to the HDVICP2.
4. clears the RM_IVAHDi_RSTCTRL[1] RST2 bit. This releases the IVAHDi_SEQ2_RST reset to the Sequencer2 CPU.


And my take on all this which would be worth checking on:

a) & b)
devmem2 0x48180620 word
devmem2 0x48180720 word
devmem2 0x48180820 word
Check bits 0-1 and check they are 0x0 as this means the module is disabled. For the moment I'm guessing that if the module is disabled, you needn't worry about the state of the HDVICP.
If these bits aren't 0x0, presumably you have to check bits 16-17 and ensure they are equal to 0x2 (???) and also check that bit 18 is set.

c)
devmem2 0x48180600 halfword
devmem2 0x48180700 halfword
devmem2 0x48180800 halfword
Check that bit 8 is unset.

1.
devmem2 0x48180C10 byte 7
devmem2 0x48180D10 byte 7
devmem2 0x48180E10 byte 7

2.
devmem2 0x48180620 byte 2
devmem2 0x48180720 byte 2
devmem2 0x48180820 byte 2

3.
devmem2 0x48180C10 byte 2
devmem2 0x48180D10 byte 2
devmem2 0x48180E10 byte 2

4.
devmem2 0x48180C10 byte 0
devmem2 0x48180D10 byte 0
devmem2 0x48180E10 byte 0

Please could someone from TI tell me what I'm doing wrong and how I can reset the HDVICP?

Thanks,
Ralph

Okay, that didn't work. In fact, writing the registers in U-Boot didn't work.

I only got this working by checking for warm boot at _the very start_ of the boot process in assembler function "reset" in "start.S" and doing a cold reset if a warm reset was detected. :-D

Ralph