[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fc0bbd15-209e-412d-a132-6aac2e871c71@quicinc.com>
Date: Tue, 24 Oct 2023 07:25:03 -0700
From: Jeff Johnson <quic_jjohnson@...cinc.com>
To: Zhenhua Huang <quic_zhenhuah@...cinc.com>,
Konrad Dybcio <konrad.dybcio@...aro.org>, <agross@...nel.org>,
<andersson@...nel.org>, <robh+dt@...nel.org>,
<krzysztof.kozlowski+dt@...aro.org>, <conor+dt@...nel.org>
CC: <linux-arm-msm@...r.kernel.org>, <devicetree@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <kernel@...cinc.com>,
<quic_tingweiz@...cinc.com>
Subject: Re: [PATCH v1 0/5] soc/arm64: qcom: add initial version of memory
dump
On 10/24/2023 3:10 AM, Zhenhua Huang wrote:
>
>
> On 2023/10/23 21:50, Konrad Dybcio wrote:
>> On 23.10.2023 11:20, Zhenhua Huang wrote:
>>> Qualcomm memory dump driver is to cooperate with firmware, providing the
>> Firmware == The hypervisor? The TZ? Some uncore chip?
>
> It's part of bootloader which also needs to cooperate with TZ. After
> system crash and warm reset, system enters debug mode which needs the
> dump table.
When you re-spin can you be clear about for which firmware this is
applicable? On a Qualcomm SoC there are multiple integrated peripherals
with their own firmware, so it is important to clarify which ones can
utilize this framework.
/jeff
Powered by blists - more mailing lists