I guess to answer my own question: https://groups.google.com/forum/#!topic/beagleboard/ogyyRufIVVs The post by David Belohrad is very descriptive. Especially the part where grounding PWR_BTN will completely turn off the PMIC. Which a lot of people seem to be having issues with completely turning off their boards.
@Gerald
So hey where can I find good official documentation on SYS_RESETIN ? I’ve poured over the SRM, and the TRM, and have not really found any clear documentation on the subject matter. Also, what little the documentation does mention anything, names are confused between SYS_RESET, SYS_RESETIN, RESET_OUT, or RSTn . . . How does one make sense of all this ?
Schematic
Schematic may tell me that it is connected to the PMIC through a buffer, a button, and back out to another part I do not recognize offhand. But a schematic does not tell me how this pin is used, or processed within the OS. There is a lot of conflicting information out there so it is hard to get a “bead” on what’s going on.
a patch in the post form 2013 I found may lead to some pertinent information. But much has changed in the kernel since then . . .
In the AM3358 TRM. It is an interrupt input to the processor. The SW can cleanup before making it an output to reset the board. So, if the SW does not handle it, it does not reset anything.
Gerald
Section 8.1.7 of the TRM "Reset Management", with some additional
details in the data sheet (sprs717). It can be confusing, since the
physical reset pin (nRESETIN_OUT) is both an input and an output, but
the individual RESET_IN and RESET_OUT signals are "broken out" on-chip
and have various sources/destinations which are discussed individually
in the TRM.
Figure 8-20 "External System Reset" in the TRM (and the nearby related
text) might help.
In the AM3358 TRM. It is an interrupt input to the processor. The SW can cleanup before making it an output to reset the board. So, if the SW does not handle it, it does not reset anything.
Gerald
Thanks Gerald.
I kind of figured already that about the software aspect. I’m toggling the pin every 5 seconds ( 5, So I can check with a multi-meter ) from an external MCU. And the board just sits there like a dumb brick . . .no reaction.
AM3358 TRM ? Is that in addition to the AM335x TRM ? The latter here is what I’ve searched through. Which by the way for SYS_RESET no search hits in the whole 5k pages of document . . . That’s a bit frustrating. The SRM actually turned up several hits, but did not really discuss anything definitive. Then, as Charles pointed out after your post . . . I always forget about the datasheet . . . but forgot that TI loves spreading documentation out over several files . . .
AM335x is the TRM name. But I was afraid I would get jumped because that is not the processor used, instead it is the AM3358.
Look up AM3358 and select the TRM listed on that page.
Gerald
Section 8.1.7 of the TRM “Reset Management”, with some additional
details in the data sheet (sprs717). It can be confusing, since the
physical reset pin (nRESETIN_OUT) is both an input and an output, but
the individual RESET_IN and RESET_OUT signals are “broken out” on-chip
and have various sources/destinations which are discussed individually
in the TRM.Figure 8-20 “External System Reset” in the TRM (and the nearby related
text) might help
Thanks Charles.
But yeah, not only confusing, but frustrating ! But you’ve also managed to squelch a lot of confusion by just what you’ve written here. My next step was actually to watch /proc/interrupts, which actually I think I’m still going to do. In order to see if there are in fact any interrupts happening from all this pin toggling im doing.
AM335x is the TRM name. But I was afraid I would get jumped because that is not the processor used, instead it is the AM3358.
Look up AM3358 and select the TRM listed on that page.
Gerald
I don’t think anyone would get on your case over saying “AM335X”. But I was starting to wonder if there was an additional “tome” I was unaware of. I’ve actually had a copy of the TRM for years now on disk. Including the original with the PRU information in it 
Thanks for the information !
My next step was actually to watch /proc/interrupts, which actually I think I’m still going to do. In order to see if there are in fact any interrupts happening from all this pin toggling im doing.
No dice. But before I give up I’m going to switch form a TI kernel to a bone kernel and see if any of this changes. Because I know that tje reset btn works, and is sometimes especially useful after a Linux “halt”.