summaryrefslogtreecommitdiffstats
path: root/Documentation/user/reboot-mode.rst
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/user/reboot-mode.rst')
-rw-r--r--Documentation/user/reboot-mode.rst20
1 files changed, 13 insertions, 7 deletions
diff --git a/Documentation/user/reboot-mode.rst b/Documentation/user/reboot-mode.rst
index 507d6feb01..1929a67e0b 100644
--- a/Documentation/user/reboot-mode.rst
+++ b/Documentation/user/reboot-mode.rst
@@ -10,7 +10,7 @@ that boot should happen from a different boot medium.
Likewise, many bootloaders reuse such registers, or if unavailable,
non-volatile memory to determine whether the OS requested a special
-reboot mode, e.g. rebooting into an USB recovery mode. This is
+reboot mode, e.g. rebooting into a USB recovery mode. This is
common on Android systems.
barebox implements the upstream device tree bindings for
@@ -29,9 +29,10 @@ User API
Devices registered with the reboot mode API gain two parameters:
- ``$dev_of_reboot_mode.prev`` (read-only): The reboot mode that was
- set previous to barebox startup
+ set previously to barebox startup.
- ``$dev_of_reboot_mode.next``: The next reboot mode, for when the
- system is reset
+ system is reset. Its initial value after startup is 0 which corresponds
+ to ``normal`` by default.
The reboot mode driver core use the alias name if available to name
the device. By convention, this should end with ``.reboot_mode``, e.g.::
@@ -46,19 +47,24 @@ Reboot mode providers have priorities. The provider with the highest
priority has its parameters aliased as ``$global.system.reboot_mode.prev``
and ``$global.system.reboot_mode.next``. After executing the init scripts,
barebox startup will ``source /env/bmode/${global.system.reboot_mode.prev}``
-if available.
+if available. Example usage::
+
+ gpr.reboot_mode=serial reset -w
Reset
=====
Reboot modes can be stored on a syscon wrapping general purpose registers
-that survives warm resets. If the system instead did reset via an external
+that survive warm resets. If the system instead did reset via an external
power management IC, the registers may lose their value.
If such reboot mode storage is used, users must take care to use the correct
-reset provider. In barebox, multiple reset providers may co-exist. They
+reset provider. In barebox, multiple reset providers may co-exist. The
``reset`` command allows listing and choosing a specific reboot mode.
+For communication with the SoC's BootROM, a warm reset can be triggered
+with ``reset -w`` if a suitable reset handler has been registered.
+
Disambiguation
==============
@@ -86,7 +92,7 @@ as the reboot mode.
For cases, where the communication instead happens between barebox and an OS,
they can be completely different, e.g. ``$bootsource`` may say barebox was
booted from ``spi-nor``, while the reboot mode describes that barebox should
-boot the Kernel off an USB flash drive.
+boot the Kernel off a USB flash drive.
Comparison to barebox state
---------------------------