Our selftest will soon test the actual runtime reset function rather than the boot time one. For this, we need to ensure that the runtime version actually succeeds on x86 to keep our travis tests work. So this patch implements an x86 runtime reset function. It is missing shutdown functionality today, but OSs usually implement that via ACPI and this function does more than the stub from before, so it's at least an improvement. Eventually we will want to have full DM functionality in runtime services. But this fixes a travis failure and doesn't clutter the code too heavily, so we should pull it in without the amazing new RTS DM framework. Signed-off-by: Alexander Graf <agraf@suse.de>
If U-Boot is started from SPL or TPL, then those earlier phases deal with the reset cause. On real hardware this cause may be lost once it is read. Emulate that behaviour in sandbox by reporting a warm reset when a previous phase has run since start-up. Signed-off-by: Simon Glass <sjg@chromium.org>
When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be bound before relocation. However due to a bug in the DM core, the flag only takes effect when devices are statically declared via U_BOOT_DEVICE(). This bug has been fixed recently by commit "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in lists_bind_fdt()", but with the fix, it has a side effect that all existing drivers that declared DM_FLAG_PRE_RELOC flag will be bound before relocation now. This may expose potential boot failure on some boards due to insufficient memory during the pre-relocation stage. To mitigate this potential impact, the following changes are implemented: - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver only supports configuration from device tree (OF_CONTROL) - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device is statically declared via U_BOOT_DEVICE() - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for drivers that support both statically declared devices and configuration from device tree Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
We have a method to return the last reset as a string for humans, but not a method that allows it to be used programmatically. Add a new method that returns the last reset as an enum. Signed-off-by: Simon Glass <sjg@chromium.org>
Some comments are incorrect or missing pieces. Fix these and use logging to print the error. Signed-off-by: Simon Glass <sjg@chromium.org>
Add a sysreset driver for the MPC83xx platform. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mario Six <mario.six@gdsys.cc>
Add some tests for sysreset_get_status. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mario Six <mario.six@gdsys.cc>
It's useful to have the reset status of the SoC printed out during reset (e.g. to learn whether the reset was caused by software or a watchdog). As a first step to implement this, add a get_status method to the sysreset class, which enables the caller to get printable information about the reset status (akin to get_desc in the CPU uclass). Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mario Six <mario.six@gdsys.cc>
Devices from the TI K3 family of SoCs like the AM654x contain a Device Management and Security Controller (SYSFW) that manages the low-level device control (like clocks, resets etc) for the various hardware modules present on the SoC. These device control operations are provided to the host processor OS through a communication protocol called the TI System Control Interface (TI SCI) protocol. This patch adds a system reset driver that communicates to the system controller over the TI SCI protocol for allowing to perform a system- wide SoC reset. Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>