Hi Eric,
On 10/02/2015 18:19, Eric Nelson wrote:
Hi Stefano,
On 02/05/2015 11:49 AM, Stefano Babic wrote:
Hi Eric,
On 05/02/2015 19:22, Eric Nelson wrote:
Certainly, but it seems wrong to make a decision about where and how this might get passed to an O/S in code.
If we want to generalize it, I'd be inclined to add commands to query (into a variable) and clear the reset cause.
That would still require this patch though.
I do not think there should be a command. The cause must be directly associated to the variable, and the reset cause cleared.
I posted a couple of additional options and received no comment from you.
Sorry for that.
Neither of them works as-is because of the ordering of events (print_cpuinfo() is called before restoring the environment), so your suggestion would require an additional call at startup which currently doesn't exist across i.MX boards.
Right, I know. For that reason I suggested to you to save the result somewhere but not into a variable, at least not at the time print_cpuinfo() is called.
I think we can split the issue into two parts:
- detecting the reset reason. It makes absolutely sense to check the reason as soon as possible to avoid to miss an event, and resetting the cause is also a must. This is what current code does, and it is correct that the reason is read by the bootloader and not by the OS. In this way, we do not miss events and we know the last reason.
- we need to propagate this information to the OS in a way the OS can understand. Anyway, this does not mean that the OS must reread from the srsr register.
I admit, I do not know the interface with WinCE - I cannot help a lot for that. But assume we can have something similar we have with Linux. If we want to go on with a U-Boot variable, it is not required that the variable is assigned at the moment the reason is read. I think there are some other example in U-Boot (maybe "dieid#" for TI soc ?), where the variable is assigned later.
I do not think that resetting the flags in arch_preboot_os() is a good idea. This is a hack, and passing parameters has nothing to do with turning off peripherals.
The primary argument against the original patch was that bits **could** accumulate. In practice, I believe this to be a bit of a red herring, since two bits cover essentially all of the normal conditions:
bit 0 - power on bit 4 - watchdog
Let's say that my board has an issue (maybe hardware, maybe not..) and after a first reset, the board resets twice. It can be a problem with power supply, can be something different. First time bits are on, and if I do not clear the bits, I cannot know the reson when it happens again.
The watchdog flag is set with reboot under Linux and reset in U-Boot, so we could re-work the switch statement to do the right thing.
I slightly disagree. You are perfectly right when everything works as it should work.
In fact, it appears broken now because it has 0x11 displaying "POR", when I believe that should be "WDOG".
I do not know now, but of course reset reason have priorities. If "POR" is set, it has advantage on "WDOG". But if after a WDOG the POR bit is set, it is another issue, not related to this one.
Other bits could conceivably accumulate, but I don't see the value of worrying about cases like "JTAG_RESET".
The reason we're pursuing this at all is because we'd like to know the difference between a restart caused by power interruption and a system lockup, and we'd like to do this under Linux or Windows Embedded.
Agree, but I do not think we reach the goal simply clearing the bits and hoping to have always the good case. Multiple reset in U-Boot (and I see a lot of them...) are then hidden (not the reset, but the cause, of course !).
I understand the goal, we have to find a suitable ways to pass the information to the OS, that is.
Best regards, Stefano