mbox series

[0/3] soc: qcom: Add download mode support for QTI platforms

Message ID cover.1628757036.git.saiprakash.ranjan@codeaurora.org
Headers show
Series soc: qcom: Add download mode support for QTI platforms | expand

Message

Sai Prakash Ranjan Aug. 12, 2021, 9:17 a.m. UTC
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.

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

Comments

Trilok Soni Aug. 13, 2021, 4:31 a.m. UTC | #1
Stephen,

On 8/12/2021 5:16 PM, 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
>>   create mode 100644 drivers/soc/qcom/download_mode.c

Some discussion by Elliot on the PSCI_SYSTEM_RESET2 and vendor bits was 
done here. You may want to check.

https://lkml.org/lkml/2020/2/24/1137

---Trilok Soni
Sai Prakash Ranjan Aug. 16, 2021, 10:38 a.m. UTC | #2
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 
cmdline
*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 
android
as well and it doesn't need any of your additional changes to kernel.

Thanks,
Sai

>> 
>> 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
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel