| Message ID | cover.1628757036.git.saiprakash.ranjan@codeaurora.org |
|---|---|
| Headers | show |
| Series | soc: qcom: Add download mode support for QTI platforms | expand |
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
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