AM5728 EVM PORz

I'm sorry, I forgot to reply to your post.

The reset circuit on the AM572x GP EVM is required to support a use case where Linux can turn off power. The advisory indicates there is a way to use the PMIC to resolve the problem described in the advisory, but the PMIC cannot be used to generate the reset when the product needs to support a configuration that allows Linux to turn off power.

I have asked someone that understands the details of this to update the advisory such that it describes both use cases and provide a workaround for each use case.

Does your product need to be able to turn itself off? If so, you need to include the reset circuit used on the AM572x GP EVM.

Regards,
Paul

We are in the process of updating Advisory i862 to provide more information. The updated Silicon Errata should be published in a few days. Meanwhile, I have inserted text from a draft of the updated advisory below.

Hopefully this helps answer your question.

Regards,
Paul

********

i862 Reset Should Use PORz

 

CRITICALITY High

 

DESCRIPTION

 

Power-on-reset (porz SoC input) is the only 100% reliable reset source. If any reset source other than porz is used, there is a chance the SoC may hang during boot after the reset source is de-asserted. Examples of other reset sources include software resets (global cold, global warm), hardware exception resets (Watchdog, Thermal Shutdown, Security violations), or the Warm Reset input (resetn SoC input). Entry into reset will be successful with these reset sources, but code execution may hang if reset is initiated by any reset source other than porz.

 

Two examples: A watchdog reset will indicate a runaway code event has occurred by resetting the SoC and asserting rstoutn. A thermal shutdown reset (TSHUT) will reset the SoC and assert rstoutn which prevents the SoC from overheating. However, code execution my hang when the SoC attempts to reboot from any source other than porz (including a watchdog and thermal shutdown reset).

 

Power-On-Reset (porz SoC input) is 100% reliable and will always recover the SoC from a hung state.

 

WORKAROUND

 

PORz should be used for all reset occurrences.

 

Two recommended implementations are provided below. Note: All reset sources will assert reset to the system via the SoC rstoutn output. This allows external visibility to software or watchdog resets, which would otherwise be invisible to components outside of the SoC. Both recommended implementations will use the rstoutn output.

 

Implementation 1:  PMIC asserts porz when rstoutn is connected to PMIC NRESWARM input

 

-        When the rstoutn output from the SoC is connected to the external PMIC's NRESWARM input, the PMIC companion device approved for use with the SoC can be configured to detect the rstoutn/NRESWARM assertion and assert porz/RESET_OUT. All PMIC companion devices which have been approved for the SoC implement this feature. The feature is bootstrap selectable via one of the PMIC's BOOT pin(s). Refer to PMIC User Guide for additional details. Note: This implementation option has no added cost to the customer since the SoC must be used with one of the approved PMIC devices.

 

-        To implement the workaround:

• Connect the rstoutn output from the SoC to the PMIC's NRESWARM input (and to any other components that need to reset when the SoC undergoes a reset). Note: When the rstoutn output is operating in 3.3V mode, a 3.3 volt to 1.8 volt level translator will be required to level shift the rstoutn output connected to the PMIC’s NRESWARM input to 1.8 volts.
• Pull-up the appropriate PMIC BOOTx pin, to configure the PMIC’s RESET_OUT to assert porz on warm reset.
• The PMIC’s POWERHOLD (GPIO7) input must be pulled high.

 

-        Example use cases for this implementation include:

• A switch connected to the PMIC’s POWERHOLD input is used to turn the board on/off.
• The PMIC applies power to the SoC as soon as the board is powered when the POWERHOLD input is tied high to an always-on supply LDOVRTC_OUT.
• The PMIC applies power to the SoC once the PWRON input is pulled low by pressing a normally open push-button switch when the POWERHOLD input is pulled high by one of the supplies enabled during device start-up.

 

-        The side effects/risks of this implementation include:

• This implementation does not allow software to shut down the PMIC outputs that power the SoC. Only the PMIC RESET_IN can shut down the PMIC outputs while POWERHOLD is pulled high.
• Risk of exceeding the 200 hour limit defined by Advisory i863, if the PMIC applies power with eMMC in contention longer than 200 hours.

 

 

Implementation 2:  Additional circuit implemented that generates porz without PMIC support

 

-        This implementation enables software shutdown of the PMIC since the PMIC’s POWERHOLD input remains low during operation.

 

-        To implement the workaround:

• Pull-down the appropriate PMIC’s BOOTx input.
• Use an external circuit that generates a finite length active low pulse to porz when the circuit detects the assertion of rstoutn. This feedback path from rstoutn through the pulse generating circuit to porz insures any reset source other than porz generates a valid reset for the SoC.

 

-        Example use cases for this implementation include:

• A normally open push button switch (on the system board) connected to the PMIC’s PWRON input is used to initiate PMIC applying power to the device.
• Software writes to the PMIC registers to power off the device.

 

-        The benefits/side effects of this implementation include:

• Reduces the risk described in Advisory i863.  This implementation will automatically shut-off power to the SoC seven seconds after the PMIC’s PWRON event unless software writes to appropriate registers to remove contention from the eMMC signals before writing to appropriate PMIC registers that allows the SoC to remain powered.

 

Other implementations are also possible. For instance, an external watchdog timer could be implemented to assert porz when the SoC becomes unresponsive.

 

 

In general, any valid workaround that generates a porz whenever any reset is initiated has the following side effects:

 

• Reset status information is lost in PRM_RSTSTAT register.
  • Visibility into the cause of the last reset is lost. To maintain some visibility software may be able to store information in PMIC BACKUP or other PMIC registers.
  • Ethernet Reset isolation feature is not supported.
  • Boot device reordering on warm reset is not supported.

 

The workaround has the advantage of guaranteeing the entire SoC is in a known good and consistent state for every reboot. For example, there are no software residual effects due to watchdog warm reset.

 

 

REVISIONS IMPACTED SR 1.1, 2.0