Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
Message-ID: <092c7a54-edb9-4ff5-8c35-a936461111df@linaro.org>
Date:   Mon, 23 Oct 2023 15:31:53 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 0/5] soc/arm64: qcom: add initial version of memory
 dump
Content-Language: en-US
To:     Zhenhua Huang <quic_zhenhuah@quicinc.com>, agross@kernel.org,
        andersson@kernel.org, konrad.dybcio@linaro.org, robh+dt@kernel.org,
        krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org
Cc:     linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org, kernel@quicinc.com,
        quic_tingweiz@quicinc.com
References: <1698052857-6918-1-git-send-email-quic_zhenhuah@quicinc.com>
From:   Caleb Connolly <caleb.connolly@linaro.org>
In-Reply-To: <1698052857-6918-1-git-send-email-quic_zhenhuah@quicinc.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 23/10/2023 10:20, Zhenhua Huang wrote:
> Qualcomm memory dump driver is to cooperate with firmware, providing the
> hints(id and size) of storing useful debugging information into pre-allocated
> memory. Firmware then does the real data capture. The debugging information
> includes cache contents, internal memory, registers. 
> 
> The driver dynamically reserves memory and provides the hints(dump id and size)
> following specified protocols with firmware. After crash and warm reboot,
> firmware scans these information and stores contents into reserved memory
> accordingly. Firmware then enters into full dump mode which dumps whole DDR
> to host through USB.
> 
> User then get full dump using PCAT and can parse out these informations.

PCAT is a proprietary tool that requires signing up to qualcomm.com and
installing the Qualcomm Package Manager to access. It also relies on
another tool (QUTS) to actually interact with the board.

Shouldn't we have a FOSS (or at the very least OSS) tool that can be
used to interact with these memory dumps?
> 
> Dump id and size are provided by bootconfig. The expected format of a
> bootconfig file is as follows:-
> memory_dump_config {
> 	<node name> {
> 		id = <id of HW component>
> 		size = <dump size of HW component>
> 	}
> }
> 
> for example:
> memory_dump_config {
>         c0_context_dump {
> 		id = 0
> 		size = 0x800
>         }
> }
> 
> Test based on 6.6-rc1.
> 
> Zhenhua Huang (5):
>   dt-bindings: soc: qcom: Add memory_dump driver bindings
>   dt-bindings: sram: qcom,imem: document sm8250
>   soc: qcom: memory_dump: Add memory dump driver
>   arm64: defconfig: enable Qcom Memory Dump driver
>   arm64: dts: qcom: sm8250: Add memory dump node
> 
>  .../bindings/soc/qcom/qcom,mem-dump.yaml           |  42 ++
>  .../devicetree/bindings/sram/qcom,imem.yaml        |  45 ++
>  MAINTAINERS                                        |   7 +
>  arch/arm64/boot/dts/qcom/sm8250.dtsi               |  31 ++
>  arch/arm64/configs/defconfig                       |   1 +
>  drivers/soc/qcom/Kconfig                           |  11 +
>  drivers/soc/qcom/Makefile                          |   1 +
>  drivers/soc/qcom/memory_dump.c                     | 540 +++++++++++++++++++++
>  8 files changed, 678 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,mem-dump.yaml
>  create mode 100644 drivers/soc/qcom/memory_dump.c
> 

-- 
// Caleb (they/them)