diff options
author | Juergen Borleis <jbe@pengutronix.de> | 2015-06-16 14:02:24 +0200 |
---|---|---|
committer | Sascha Hauer <s.hauer@pengutronix.de> | 2015-06-17 08:19:03 +0200 |
commit | 307e64672b94eaecc18fa6b4475b57b1638ae387 (patch) | |
tree | 5d9e68c7eaa8e59d38692d3a091873c617c912f7 /Documentation | |
parent | a3a17dfd5a2c5df9626c844dcbef3bb2e9cce14c (diff) | |
download | barebox-307e64672b94eaecc18fa6b4475b57b1638ae387.tar.gz barebox-307e64672b94eaecc18fa6b4475b57b1638ae387.tar.xz |
Documentation: add some info about the reset reason framework
Signed-off-by: Juergen Borleis <jbe@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/user/reset-reason.rst | 47 | ||||
-rw-r--r-- | Documentation/user/user-manual.rst | 1 |
2 files changed, 48 insertions, 0 deletions
diff --git a/Documentation/user/reset-reason.rst b/Documentation/user/reset-reason.rst new file mode 100644 index 0000000000..26d37f86dd --- /dev/null +++ b/Documentation/user/reset-reason.rst @@ -0,0 +1,47 @@ +.. _reset_reason: + +Reset Reason +------------ + +To handle a device in a secure and safe manner many applications are using +a watchdog or other ways to reset a system to bring it back into life if it +hangs or crashes somehow. + +In these cases the hardware restarts and runs the bootloader again. Depending on +the root cause of the hang or crash, the bootloader sometimes should not just +re-start the main system again. Maybe it should do some kind of recovery instead. +For example it should wait for another update (for the case the cause of a +crash is a failed update) or should start into a fall back system instead. + +In order to handle failing systems gracefully the bootloader needs the +information why it runs. This is called the "reset reason". It is provided by +the global variable ``system.reset`` and can be used in scripts via +``$global.system.reset``. + +The following values can help to detect the reason why the bootloader runs: + +* ``unknown``: the software wasn't able to detect the reset cause or there + isn't support for this feature at all. +* ``POR`` (Power On Reset): a cold start. The power of the system + was switched on. This is a regular state and nothing to worry about. +* ``RST`` (ReSeT): a warm start. The user has triggered a reset somehow. This + is a regular state and nothing to worry about. +* ``WDG`` (WatchDoG): also some kind of warm start, but triggered by a watchdog + unit. It depends on the application if this reason signals a regular state + and therefore nothing to worry about, or if this state was entered by a hanging + or crashed system and must implicitly be handled. +* ``WKE`` (WaKEup): a mixture of cold and warm start. The system is woken up + from some state of suspend. This is a regular state and nothing to worry + about. +* ``JTAG``: an external JTAG based debugger has triggered the reset. +* ``THERM`` (THERMal): some SoCs are able to detect if they got reset in + response to an overtemperature event. This can be a regular state and nothing + to worry about (the reset has brought the system back into a safe state) or + must implicitly be handled. +* ``EXT`` (EXTernal): some SoCs have special device pins for external reset + signals other than the ``RST`` one. Application specific how to handle this + state. + +It depends on your board/SoC and its features if the hardware is able to detect +these reset reasons. Most of the time only ``POR`` and ``RST`` are supported +but often ``WDG`` as well. diff --git a/Documentation/user/user-manual.rst b/Documentation/user/user-manual.rst index 3d68bbb9ae..1fc6883280 100644 --- a/Documentation/user/user-manual.rst +++ b/Documentation/user/user-manual.rst @@ -28,6 +28,7 @@ Contents: ubi booting-linux system-setup + reset-reason * :ref:`search` * :ref:`genindex` |