The Technical Reference Manual (TPS65930/TPS65920 OMAP™ Power-Management and System Companion Devices) describes a number of example power-up / reset sequence examples to be used with OMAP processors. Newer versions of the upstream Linux kernel appear to implement one of these sequences as a generic example.
See this for an example patch: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/251571.html
In our design using a DM3730 but an older kernel we have now implemented a similar reset sequence because we experiencing boot problems after a warm (software) reset or one triggered by the TPS watchdog. Our sequence looks like this (my comments added):
{ MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_OFF), 2 }, /* Triton off */
{ MSG_SINGULAR(DEV_GRP_P1, 0x0f, RES_STATE_WRST), 15 }, /* VDD1 warm reset */
{ MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_WRST), 15 }, /* VDD2 warm reset */
{ MSG_SINGULAR(DEV_GRP_P1, 0x07, RES_STATE_WRST), 96 }, /* VPLL1 warm reset */
{ MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2 }, /* HFCLKOUT active */
{ MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_ACTIVE), 2 }, /* Triton active */
Although we can observe the power supply rails and can confirm that we have implemented this sequence correctly we still see occasional hangups after a reset. What we see is that the sys_nrespwron signal (CPU input) is pulled active and is subsequently released. But the sys_nreswarm signal (used as an output from the CPU as input to the TPS) very occasionally remains in the active state instead of going inactive. The system will then not boot.
My questions are:
(1) Is the example really to be used as a generic reset sequence and, specifically, is it valid for OMAP DM3730 CPUs?
(2) The used sequence brings a vast improvement for us; would it make sense to experiment with the length of the delays within the sequence to try to improve things even more?
(3) What other suggestions to improve the sequence (for OMAP DM3730) can be made?
Thankyou very much in advance for your help.