LKML Archive on
help / color / mirror / Atom feed
From: Sai Prakash Ranjan <>
To: Stephen Boyd <>,
	Trilok Soni <>,
Cc: Andy Gross <>,
	Bjorn Andersson <>,
	Rob Herring <>,,,,,
	Rajendra Nayak <>,
	Sibi Sankar <>
Subject: Re: [PATCH 0/3] soc: qcom: Add download mode support for QTI platforms
Date: Mon, 16 Aug 2021 16:08:52 +0530	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 2021-08-13 05:46, Stephen Boyd wrote:
> Quoting Sai Prakash Ranjan (2021-08-12 02:17:39)
>> Collecting ramdumps on QTI platforms mainly require two things,
>> SDI (System Debug Image) enabled firmware and kernel support to
>> configure download mode cookies and SDI settings. Ramdumps can
>> be collected once the system enters the download mode. To enter
>> download mode, magic values or cookies need to be set in IMEM
>> which is used by firmware to decide to enter download mode or not.
>> Download mode cookies remain the same across targets and SDI disable
>> register needs to be set or SDI needs to be disabled in case of normal
>> reboot since ramdumps are supposed to be for crash debugging and
>> not for every reboot. This series adds the kernel support required
>> to enter download mode.
> I don't recall if we discussed this on the list, but I'd really prefer
> that we don't make kernel changes to support this beyond implementing
> PSCI SYSTEM_RESET2 support and then some sort of vendor specific (or if
> ARM is willing to update the spec then ARM specific) reset command on
> panic reboot paths. The idea is to set the cookie in the bootloader
> before the kernel is booted, then any insta-reboots/watchdogs would go
> into download mode, no special init code required to lay down the 
> cookie
> or clear it on normal reboot. The normal reboot PSCI call would clear
> the cookie in the firmware, in case something goes wrong after the
> kernel hands off control to PSCI, and then panics that want to go into
> download mode would make the SYSTEM_RESET2 reboot call into PSCI that
> sets the cookie.
> Maybe it could be a linux specific psci number or maybe we could
> configure the reboot call in the psci node to be this specific number 
> so
> that it can be different based on the firmware implementation if
> consolidating around a single number doesn't work. Either way, that all
> seems manageable and we can keep these cookie details out of the kernel
> and the reboot/panic paths.

Alright, I think we can probably make it work without much/any changes
in kernel. So following what you said, we can just implement
PSCI_SYSTEM_RESET2 in firmware to enter the download mode having cookies
already set by default and the cookie is cleared when we have a normal
reboot via PSCI_SYSTEM_RESET. For panic reboot, we already have a 
*reboot=panic_warm* to identify panic reboots and can call into
PSCI_SYSTEM_RESET2. I have just tested and it works fine if we have
psci_system_reset2_supported as true.

@Trilok/@Elliot, you can check if above works for your usecases in 
as well and it doesn't need any of your additional changes to kernel.


>> Currently this series doesn't add support for android targets where
>> a couple of SCM calls are required to set/unset the download mode
>> cookies and SDI configuration but can be easily added gradually to
>> the same driver, so as of now only chrome platforms are supported
>> and tested.
>> Sai Prakash Ranjan (3):
>>   soc: qcom: Add download mode support
>>   dt-bindings: msm: Add QTI download mode support binding
>>   arm64: dts: qcom: sc7180: Add IMEM, pil info and download mode 
>> region
>>  .../bindings/arm/msm/qcom,dload-mode.yaml     |  53 ++++++
>>  MAINTAINERS                                   |   7 +
>>  arch/arm64/boot/dts/qcom/sc7180.dtsi          |  21 +++
>>  drivers/soc/qcom/Kconfig                      |  10 ++
>>  drivers/soc/qcom/Makefile                     |   1 +
>>  drivers/soc/qcom/download_mode.c              | 152 
>> ++++++++++++++++++
>>  6 files changed, 244 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/arm/msm/qcom,dload-mode.yaml
>>  create mode 100644 drivers/soc/qcom/download_mode.c
> _______________________________________________
> linux-arm-kernel mailing list

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
of Code Aurora Forum, hosted by The Linux Foundation

      parent reply	other threads:[~2021-08-16 10:39 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-12  9:17 Sai Prakash Ranjan
2021-08-12  9:17 ` [PATCH 1/3] soc: qcom: Add download mode support Sai Prakash Ranjan
2021-08-12  9:17 ` [PATCH 2/3] dt-bindings: msm: Add QTI download mode support binding Sai Prakash Ranjan
2021-08-17 21:28   ` Rob Herring
2021-08-18  3:36     ` Sai Prakash Ranjan
2021-08-12  9:17 ` [PATCH 3/3] arm64: dts: qcom: sc7180: Add IMEM, pil info and download mode region Sai Prakash Ranjan
2021-09-27 22:56   ` (subset) " Bjorn Andersson
2021-08-13  0:16 ` [PATCH 0/3] soc: qcom: Add download mode support for QTI platforms Stephen Boyd
2021-08-13  4:31   ` Trilok Soni
2021-08-16 10:38   ` Sai Prakash Ranjan [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH 0/3] soc: qcom: Add download mode support for QTI platforms' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).