from Revision C2.2 of the SRM, Section 5.13:
"When pressed and released, causes a full power on reset of the
BeagleBoard. It should be noted that currently, the reset will not
work when the Linux kernel is running. To reset the board from the
kernel operation, a power cycle is required."
i was just now running android and the RESET button seemed to work
just fine. am i misreading the above?
rday
You are right… the reset button works with most recent linux kernels…
> i was just now running android and the RESET button seemed to work
> just fine. am i misreading the above?
You are right... the reset button works with most recent linux kernels...
Does anybody know why it wouldnt work? The switch is connected directly to
SYS_nRESPWRON, which AFAIK is an unmask able reset input on the OMAP?
The only reason I see why it potentially would fail is, that TWL4030 might
not be reset by this (I don't know if nRESWARM is driven by OMAP in response
to the SYS_nRESPWRON signal?) causing the following ROM code/Linux boot to
fail by TWL4030 being in another state than expected?
Does anybody know if this is/was the reason?
Søren
here's an explanation i got via email from gerald coley, i hope he
doesn't mind me sharing it:
"The reset pin only works on power up. After that, the SW must set it
up to generate an interrupt to cause a reset. UBoot takes care of this
now. In the early days, the reset pin did not work because the Kernel
was not setup correctly. That has now been fixed. I will make a note
to fix the wording on the next revision of the SRM."
rday
The pin is not a RESET pin after power up. It is a GPIO pin. This allows the SW to save off registers or whatever else it wants to do before going through a reset. It is not a RESET pin. This is why in the early days of Beagle, you could not reset the board after the kernel was loaded because the Kernel was broken. If it were a RESET pin, then the SW would not have been able to break it.
Gerald
Hi Gerald,
I guess you might be right on this, but I dare to challenge you since - in case you are right - I don’t understand the system in detail and I can’t find anything about it in the TRM/DM LJ
I do remember something about a “reset” signal being muxed to a GPIO for exactly the purpose you described, but I however though this is/was sys_nreswarm (and not sys_nrespwron), which as well have a Reset button connected to it on several of the examples in the TRM. I.e. figure 4-12 and 4.23?
On Beagle the Reset Switch is connected to sys_nrespwron and called “Cold Reset”. AFAIK this is two different “resets”-signals serving two different purposes. One being warm/normal (sys_nreswarm) – Another being cold/power on/emergency (sys_nrespwron) – Right?
According to the TRM assertion of sys_nrespwron will assert the sys_nreswarm pin (In case the ball is muxed to GPIO I though do not know if this signal will ever actually reach the sys_nreswarm net?). In this case TWL4030 might not receive the reset – Alternatively TWL4030 might not be configured for handling the reset correctly thereby breaking the system. Software will therefore indeed be able to break the functionality (making the ROM-code crash during the successive boot or even before this) even though the switch is a hard reset signal on the OMAP, since the TWL4030 chip isn’t being configured/reset correctly.
To summarize, I have not been able to figure out how sys_nrespwron can be muxed to a GPIO – From the documentation it seems, that it’s a normal cold RESET signal (for the OMAP) which can’t be changed. sys_nreswarm on the other hand can be muxed to GPIO_30, which have sleep wakeup capability making the system able to save/do various stuff before shutting down/resetting.
Best regards and thanks in advance
Søren
All I can say is that if the reset was a reset all the time, please explain to me in detail, why the reset did not work with Linux running, in the first reelase of the Beagle linux Kernel? I have never heard of SW that could stop a HW reset.
I await your detailed explanation.
Gerald
I totally agree, it’s pretty hard for SW to stop a HW-reset-signal. What SW however easily can do is stop the successive boot in case the complete system isn’t reset by the HW-reset-signal and the SW isn’t written to handle this scenario. As already stated in details below I think this is what was going on, since I couldn’t (and still can’t) find any information that sys_nrespwron should be anything else than a normal HW-reset-signal on the OMAP. That however might not automatically imply TWL4030 being correctly reset as well, which in my imagination is what caused the problems, but I don’t know for sure.
Instead of discussing about what might and what might not have been going on, let’s try to find out what was causing the problem in the old days, since I (as stated) currently don’t understand the explanation you believe in. J
Can anybody remember what was actually happening when pressing the reset switch in the old days? Would the current Linux session stop running/crash, or would absolute nothing happen? The only bug report I have been able to find is http://code.google.com/p/beagleboard/issues/detail?id=2 reported by Khasim, which unfortunately doesn’t state what’s happening – Just that xloader doesn’t come up after pressing the reset button.
Does anybody remember which Linux revision was used for testing at that time?
Best regards
Søren
If you read the TRM carefully, it says that the SYS_RESPWRON pin handles the reset of the device at “power up”. What we are talking about here is not at power up. Look at Table 4.8 of the full TRM. I believe the status of the pin can be read by the SW in the PRCM module. I think you should be able to confirm this by looking in the current code to see how the reset is currently implemented.
As to the TPS65950, the reset pin is an output only, so that will not reset the TPS65950. There is a TEST.RESET pin that could be used for that purpose, but it will not reset the power state machine in the device.
In essence, the system design is based upon a SW based reset for all of the various devices as required by the application. This keeps SW in control. Other than a power on reset, there is no way to force a full HW reset of the OMAP3530 nor the TPS65950. This is the reason that we have cases where unless a power cycle is done, certain issues cannot by cleared. On a reset, the SW must take care of setting up or resetting the HW.
Gerald
Hi Gerald,
If you read the TRM carefully, it says that the SYS_RESPWRON pin handles the reset of the device at “power up”.
What we are talking about here is not at power up. Look at Table 4.8 of the full TRM.
I think this is exactly what I have been doing, and I can’t find anything pointing in other direction than what I’m trying to describe. I however spend yet another couple of hours this evening checking if I should have missed anything, but still without luck. The only description I can find in the OMAP3 documentation (mainly TRM and DM) with respect to sys_nrespwron is, that it’s intended to be held low during initial cold reset of the board during power up.
Other than this, the TRM/DM leaves this pin “untouched” and doesn’t give any examples of what happens in case this is held low after a “power on” sequence (i.e. the situation happening on Beagle when the user presses the reset switch). My bet is, that it’s acting as a cold/hard reset for OMAP3, which isn’t from a SW point of view “coordinated” with TPS65950 thereby possible causing the system to crash/halt/deadlock.
As stated the examples in the TRM have the user reset button attached to sys_nreswarm sand not to sys_nrespwron, as it is on Beagle.
I believe the status of the pin can be read by the SW in the PRCM module.
And I believe it can’t J – At least I have not been able to find any information indicating that this should be possible. You can after a reset read the reset reason, but this is after the reset happened, and not prior to it. With respect to the sys_nreswarm it will however be possible (due to the GPIO_30 muxing option) – Secondly you can read the level of this signal in TPS65950 as well…
I think you should be able to confirm this by looking in the current code to see how the reset is currently implemented.
Which is exactly why I asked what to look for, since I don’t intent to start searching several thousand lines of code without knowing what I’m looking for. J Does anybody have any pointer to (non)-working Linux builds in order for us to figure out that’s exactly going on in this case and what was changed in order to make the reset button work?
As to the TPS65950, the reset pin is an output only, so that will not reset the TPS65950.
You are right that nrespwron is an output only pin on TPS95950, but I was referring to nreswarm, which is an input pin, which dependent on TPS65950 programming might cause a different degree of reset/reinitialization of the TPS65950. (See section 5.3.2.1 of the TPS65950 TRM)
In the overall picture I think we agree that SW (might) have a huge influence on what happens during a reset of an OMAP3 based system (OMAP3 and TPS65950). The main/only point where we disagree is if the sys_nrespwron reset can be masked on OMAP3 or not?
Best regards
Søren
I totally agree, it’s pretty hard for SW to stop a HW-reset-signal. What SW however easily can do is stop the successive boot in case the complete system isn’t reset by the HW-reset-signal and the SW isn’t written to handle this scenario. As already stated in details below I think this is what was going on, since I couldn’t (and still can’t) find any information that sys_nrespwron should be anything else than a normal HW-reset-signal on the OMAP. That however might not automatically imply TWL4030 being correctly reset as well, which in my imagination is what caused the problems, but I don’t know for sure.
Instead of discussing about what might and what might not have been going on, let’s try to find out what was causing the problem in the old days, since I (as stated) currently don’t understand the explanation you believe in. J
Can anybody remember what was actually happening when pressing the reset switch in the old days? Would the current Linux session stop running/crash, or would absolute nothing happen? The only bug report I have been able to find is http://code.google.com/p/beagleboard/issues/detail?id=2 reported by Khasim, which unfortunately doesn’t state what’s happening – Just that xloader doesn’t come up after pressing the reset button.
Does anybody remember which Linux revision was used for testing at that time?
Best regards
Søren
I agree that all references to this pin are only talked about as a power on reset function.
If the SW cannot read this pin or detect that it has been pressed and it cannot force a reeset of the TSP65950 as it is an output only, then why does prressing it cause a reset? While it may be nice to go back in time and run old code, would it not make more sense just to see how it works today?
Gerald
Here is where the issue was listed. It is the first one on the list.
http://code.google.com/p/beagleboard/issues/list
Gerald
If the SW cannot read this pin or detect that it has been pressed and it cannot force a reeset of the TSP65950
as it is an output only, then why does prressing it cause a reset?
I think the following is happening on Beagle in case of a successful reset:
User presses Reset Button
OMAP3 issues a hard/cold resets causing sys_nreswarm to go low (according to TRM chapter 4.3.2)
sys_nreswarm causes TPS65950 to initiate the programmed power transitions for warm-reset
While it may be nice to go back in time and
run old code, would it not make more sense just to see how it works today?
Agree – As such I don’t have any interest going back, expect in case it could help us to understand what changed/happened in order to get the reset functionality working. As stated earlier I think the reason why it didn’t work in the beginning was related to step 3 above not being executed correctly due to a for now “unknown” reason (pinmux, power transitions programming, TPS65950 configuration or similar?)
In case you agree that the above sequence might be what is happening, and that the reset in the old days might have not worked due to something going wrong in (or close to) step 3 I think we pretty much agree and can close the case for now – At least until it shows up in ½ a year, that this wasn’t the full/valid truth anyway J
Best regards and thanks for a fruitful discussion
Søren
Hi Gerald,
If you read the TRM carefully, it says that the SYS_RESPWRON pin handles the reset of the device at “power up”.
What we are talking about here is not at power up. Look at Table 4.8 of the full TRM.
I think this is exactly what I have been doing, and I can’t find anything pointing in other direction than what I’m trying to describe. I however spend yet another couple of hours this evening checking if I should have missed anything, but still without luck. The only description I can find in the OMAP3 documentation (mainly TRM and DM) with respect to sys_nrespwron is, that it’s intended to be held low during initial cold reset of the board during power up.
Other than this, the TRM/DM leaves this pin “untouched” and doesn’t give any examples of what happens in case this is held low after a “power on” sequence (i.e. the situation happening on Beagle when the user presses the reset switch). My bet is, that it’s acting as a cold/hard reset for OMAP3, which isn’t from a SW point of view “coordinated” with TPS65950 thereby possible causing the system to crash/halt/deadlock.
As stated the examples in the TRM have the user reset button attached to sys_nreswarm sand not to sys_nrespwron, as it is on Beagle.
I believe the status of the pin can be read by the SW in the PRCM module.
And I believe it can’t J – At least I have not been able to find any information indicating that this should be possible. You can after a reset read the reset reason, but this is after the reset happened, and not prior to it. With respect to the sys_nreswarm it will however be possible (due to the GPIO_30 muxing option) – Secondly you can read the level of this signal in TPS65950 as well…
I think you should be able to confirm this by looking in the current code to see how the reset is currently implemented.
Which is exactly why I asked what to look for, since I don’t intent to start searching several thousand lines of code without knowing what I’m looking for. J Does anybody have any pointer to (non)-working Linux builds in order for us to figure out that’s exactly going on in this case and what was changed in order to make the reset button work?
As to the TPS65950, the reset pin is an output only, so that will not reset the TPS65950.
You are right that nrespwron is an output only pin on TPS95950, but I was referring to nreswarm, which is an input pin, which dependent on TPS65950 programming might cause a different degree of reset/reinitialization of the TPS65950. (See section 5.3.2.1 of the TPS65950 TRM)
In the overall picture I think we agree that SW (might) have a huge influence on what happens during a reset of an OMAP3 based system (OMAP3 and TPS65950). The main/only point where we disagree is if the sys_nrespwron reset can be masked on OMAP3 or not?
Best regards
Søren
I totally agree, it’s pretty hard for SW to stop a HW-reset-signal. What SW however easily can do is stop the successive boot in case the complete system isn’t reset by the HW-reset-signal and the SW isn’t written to handle this scenario. As already stated in details below I think this is what was going on, since I couldn’t (and still can’t) find any information that sys_nrespwron should be anything else than a normal HW-reset-signal on the OMAP. That however might not automatically imply TWL4030 being correctly reset as well, which in my imagination is what caused the problems, but I don’t know for sure.
Instead of discussing about what might and what might not have been going on, let’s try to find out what was causing the problem in the old days, since I (as stated) currently don’t understand the explanation you believe in. J
Can anybody remember what was actually happening when pressing the reset switch in the old days? Would the current Linux session stop running/crash, or would absolute nothing happen? The only bug report I have been able to find is http://code.google.com/p/beagleboard/issues/detail?id=2 reported by Khasim, which unfortunately doesn’t state what’s happening – Just that xloader doesn’t come up after pressing the reset button.
Does anybody remember which Linux revision was used for testing at that time?
Best regards
Søren
I can agree with this. But, the main point in all this is that this pin is not your classical HW reset pin. So as long as everyone understands this, I am happy.
Gerald