[qcom-next] reset edl command support - #106
Merged
varada-qcom merged 11 commits intoAug 12, 2026
Merged
Conversation
varada-qcom
approved these changes
Aug 11, 2026
balajiselvanathan
force-pushed
the
reset-edl-rebootmode
branch
from
August 12, 2026 04:57
5c91127 to
c41c6e9
Compare
The reboot-mode framework currently stores a single u32 magic value per mode and parses exactly one cell from each "mode-*" device tree property. That is sufficient for the existing backing-store users (nvmem, gpio, rtc), but a PSCI SYSTEM_RESET2 vendor reset is described by up to three 32-bit cells: <reset_type[, cookie_hi[, cookie_lo]]>, matching the reboot-mode binding for the psci "reboot-mode" subnode. Restructure struct reboot_mode_mode to hold an array of up to REBOOT_MODE_MAX_MAGIC (3) cells plus a cell count, and make dm_reboot_mode_pre_probe() length-aware so it reads 1 to 3 cells from each property. dm_reboot_mode_update() now matches the backing-store value against magic[0]. Existing single-cell modes (e.g. nvmem "mode-bootloader = <0x02>") parse to magic[0] = 0x02, count = 1 and keep matching exactly as before, so there is no functional change for current users. Signed-off-by: Balaji Selvanathan <balaji.selvanathan@oss.qualcomm.com>
The reboot-mode framework so far only reads a value from a backing store
on boot (get/set) and maps it to an environment variable. Triggering a
reset into a specific mode on demand - e.g. rebooting a Qualcomm SoC into
EDL via a PSCI SYSTEM_RESET2 vendor reset - needs a different approach.
Add an trigger() op to struct reboot_mode_ops. It takes the
decoded magic cells for a mode and resets the system immediately; on
success it does not return. Backing-store drivers (nvmem, gpio, rtc)
leave it NULL and are unaffected.
Add two uclass helpers built on top of it:
- reboot_mode_request(name) looks up a mode by name across all
UCLASS_REBOOT_MODE devices and, if the owning device can trigger,
resets into it. Returns -ENOENT if no triggerable mode matches.
- reboot_mode_list() enumerates every triggerable mode registered with
the framework, so a command can present the available modes to the
user rather than hard-coding them.
Signed-off-by: Balaji Selvanathan <balaji.selvanathan@oss.qualcomm.com>
Add a PSCI backend for the reboot-mode framework that triggers a SYSTEM_RESET2 vendor-specific reset described by a "mode-*" property under a "reboot-mode" subnode of the PSCI device tree node (for example "mode-edl = <0x80000000 0x00000001>" to enter Qualcomm EDL/download mode). All device tree parsing and name matching already live in the reboot-mode uclass; this driver only turns a decoded set of magic cells into a firmware call. U-Boot's psci_system_reset2() client takes only a 32-bit cookie and ORs in PSCI_RESET2_TYPE_VENDOR itself, so the trigger folds the low cells into a cookie and rejects a 3-cell mode whose cookie_hi is non-zero rather than silently truncating it. psci_bind() binds the driver to the "reboot-mode" subnode when CONFIG_REBOOT_MODE_PSCI is enabled, using device_bind_driver_to_node(). Signed-off-by: Balaji Selvanathan <balaji.selvanathan@oss.qualcomm.com>
Teach the "reset" command to trigger the reset modes registered with the reboot-mode framework in addition to the existing cold and warm resets: reset cold reset (unchanged) reset -w warm reset (unchanged) reset -<mode> reset into a mode declared in the device tree reset -l list the available reset modes For example "reset -edl" enters Qualcomm EDL/download mode when the psci device tree node carries a "reboot-mode" subnode with "mode-edl = <0x80000000 0x00000001>". The command never parses the magic values itself; it strips the leading '-' and hands the mode name to reboot_mode_request(), so the values stay in the device tree and are not hardcoded per SoC. An unknown mode prints the registered modes rather than silently falling through to a cold reset. Signed-off-by: Balaji Selvanathan <balaji.selvanathan@oss.qualcomm.com>
Add a "reboot-mode" subnode under the psci node in the monaco-evk, talos-evk and lemans-evk U-Boot device tree overlays, declaring "mode-edl" so that "reset -edl" enters Qualcomm EDL/download mode via a PSCI SYSTEM_RESET2 vendor reset. The magic value <0x80000000 0x00000001> is reset_type = 0x80000000 (vendor bit set) with a cookie of 1. The subnode lives in the U-Boot-private *-u-boot.dtsi overlays and tracks the in-flight Linux psci.yaml "reboot-mode" binding; it will be adjusted if that binding changes before it lands. Signed-off-by: Balaji Selvanathan <balaji.selvanathan@oss.qualcomm.com>
Enable CONFIG_REBOOT_MODE_PSCI so "reset -edl" can trigger a PSCI SYSTEM_RESET2 vendor reset via the reboot-mode framework. The DM_REBOOT_MODE uclass is already enabled here for the nvmem-backed fastboot reboot-reason path; the PSCI backend is DT-gated, so it only activates on boards whose psci node has a "reboot-mode" subnode. Signed-off-by: Balaji Selvanathan <balaji.selvanathan@oss.qualcomm.com>
Add a trigger-only reboot-mode backend and two device tree modes to the
sandbox test tree, then cover the new trigger path:
- reboot_mode_request() fires the owning device's trigger op with the
correct magic cells for both a 2-cell and a 1-cell mode;
- an unknown mode, and a backing-store-only mode (gpio/rtc), both return
-ENOENT because they are not triggerable;
- reboot_mode_list() enumerates only the triggerable modes and hides the
backing-store modes.
Signed-off-by: Balaji Selvanathan <balaji.selvanathan@oss.qualcomm.com>
Document the "reset -<mode>" and "reset -l" forms and explain that named reset modes are declared in the device tree (a "reboot-mode" subnode of the psci node) rather than hardcoded per SoC. Describe the 1-to-3 cell mode-<name> encoding and note that U-Boot's 32-bit PSCI cookie means a 3-cell mode with a non-zero cookie_hi is rejected rather than truncated. Signed-off-by: Balaji Selvanathan <balaji.selvanathan@oss.qualcomm.com>
REBOOT_MODE_ENV_UPDATE updated the reboot-mode env variable from only the first reboot-mode device found at last stage init. Now that a board can register more than one reboot-mode device -- a backing-store device (nvmem/gpio/rtc) for the fastboot reboot reason and a trigger-only PSCI device for "reset -edl" -- relying on the first device is fragile: if the trigger-only PSCI device sorts first it has no get() op, so the nvmem reboot reason would never reach the environment. Iterate every UCLASS_REBOOT_MODE device instead. dm_reboot_mode_update() already returns -ENOSYS for a device with no get() op, so trigger-only backends are skipped harmlessly regardless of probe order, and every backing-store device gets a chance to update the env variable. Signed-off-by: Balaji Selvanathan <balaji.selvanathan@oss.qualcomm.com>
Add a "reboot-mode" subnode under the psci node in the qcs6490-rb3gen2 U-Boot device tree overlay, declaring "mode-edl" so that "reset -edl" enters Qualcomm EDL/download mode via a PSCI SYSTEM_RESET2 vendor reset. The magic value <0x80000000 0x00000001> is reset_type = 0x80000000 (vendor bit set) with a cookie of 1. Signed-off-by: Balaji Selvanathan <balaji.selvanathan@oss.qualcomm.com>
Add a U-Boot device tree overlay for shikra-cqs-evk carrying a "reboot-mode" subnode under the psci node, declaring "mode-edl" so that "reset -edl" enters Qualcomm EDL/download mode via a PSCI SYSTEM_RESET2 vendor reset. The magic value <0x80000000 0x00000001> is reset_type = 0x80000000 (vendor bit set) with a cookie of 1. No shikra U-Boot overlay existed before, so this created shikra-cqs-evk-u-boot.dtsi; it is picked up automatically by the build via the CONFIG_DEFAULT_DEVICE_TREE basename match. Signed-off-by: Balaji Selvanathan <balaji.selvanathan@oss.qualcomm.com>
balajiselvanathan
force-pushed
the
reset-edl-rebootmode
branch
from
August 12, 2026 05:51
d89a4d4 to
1b777fb
Compare
| for (i = 1; i < count; i++) | ||
| cookie = (cookie << 32) | magic[i]; | ||
|
|
||
| if (psci_features(ARM_PSCI_1_1_FN64_SYSTEM_RESET2) != |
There was a problem hiding this comment.
why not move this check above
|
|
||
| config REBOOT_MODE_PSCI | ||
| bool "Use PSCI SYSTEM_RESET2 vendor resets as reboot modes" | ||
| depends on DM_REBOOT_MODE && ARM_SMCCC |
There was a problem hiding this comment.
shouldnt this depend on ARM64 as well
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This series contains series of patches to support reset -edl command by parsing edl mode values from DT instead of hardcoding in the psci driver.
Upstream link: https://lore.kernel.org/u-boot/20260811-b4-reset-edl-rebootmode-v1-0-2e15adc156a3@oss.qualcomm.com/