Per the latest Overo signals document, this is connected to OMAP ball AH25, which, according to the DM3730 datasheet, is sys_nrespwron. On the Chestnut board, this is connected to ground via a pushbutton switch. Now the TPS65950 Design-In Guide
cautions against using nrespwron for resetting the system. From Section 188.8.131.52 (Resetting the System):
"NRESPWRON is an output from TPS65950 that at initial power-on de-asserts and takes OMAP out of reset. This reset must not be used to reset OMAP asynchronously. If an external circuit is used to assert NRESPWRON to reset OMAP, then this assertion causes OMAP to reset and it may cause the platform to be unstable."
"To avoid the above behavior it is recommended that OMAP and TPS65950 be reset using the warm reset feature on both devices. OMAP warm reset can be configured as an input. If external logic drives the warm reset low on both OMAP and TPS65950, then both devices would be reset without abnormal behavior."
Is this a bug on the Gumstix COMs? Could use of N_MANUAL_RESET cause possible stability problems because it has been connected to sys_nrespwron? Or is it in fact connected to NRESWARM/sys_nreswarm and it is the Gumstix documentation that is incorrect?
This is not used anywhere on the Chestnut board. For a battery-operated device, would it be sufficient to add a switch to ground on this, to start the system? Is PWRON pulled up to VBAT on the COM module?
Could someone from Gumstix please comment?