Message-ID: <47542dbb-8cf3-6eae-a38e-910d38bd960b@quicinc.com>
Date:   Fri, 24 Feb 2023 16:10:42 +0530
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.8.0
Subject: Re: [RFC PATCH 0/6] Add basic Minidump kernel driver support
Content-Language: en-US
To:     Brian Masney <bmasney@redhat.com>
CC:     <agross@kernel.org>, <andersson@kernel.org>,
        <konrad.dybcio@linaro.org>, <keescook@chromium.org>,
        <tony.luck@intel.com>, <gpiccoli@igalia.com>,
        <catalin.marinas@arm.com>, <will@kernel.org>,
        <linux-arm-msm@vger.kernel.org>,
        <linux-remoteproc@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <linux-hardening@vger.kernel.org>,
        <linux-arm-kernel@lists.infradead.org>
References: <1676978713-7394-1-git-send-email-quic_mojha@quicinc.com>
 <Y/deHzijzvuvCJ2M@x1>
From:   Mukesh Ojha <quic_mojha@quicinc.com>
In-Reply-To: <Y/deHzijzvuvCJ2M@x1>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

Thanks Brian for your interest in this series.

On 2/23/2023 6:07 PM, Brian Masney wrote:
> On Tue, Feb 21, 2023 at 04:55:07PM +0530, Mukesh Ojha wrote:
>> Minidump is a best effort mechanism to collect useful and predefined data
>> for first level of debugging on end user devices running on Qualcomm SoCs.
>> It is built on the premise that System on Chip (SoC) or subsystem part of
>> SoC crashes, due to a range of hardware and software bugs. Hence, the
>> ability to collect accurate data is only a best-effort. The data collected
>> could be invalid or corrupted, data collection itself could fail, and so on.
>>
>> Qualcomm devices in engineering mode provides a mechanism for generating
>> full system ramdumps for post mortem debugging. But in some cases it's
>> however not feasible to capture the entire content of RAM. The minidump
>> mechanism provides the means for selecting which snippets should be
>> included in the ramdump.
>>
>> The core of minidump feature is part of Qualcomm's boot firmware code.
>> It initializes shared memory (SMEM), which is a part of DDR and
>> allocates a small section of SMEM to minidump table i.e also called
>> global table of content (G-ToC). Each subsystem (APSS, ADSP, ...) has
>> their own table of segments to be included in the minidump and all get
>> their reference from G-ToC. Each segment/region has some details like
>> name, physical address and it's size etc. and it could be anywhere
>> scattered in the DDR.
>>
>> Existing upstream Qualcomm remoteproc driver[1] already supports minidump
>> feature for remoteproc instances like ADSP, MODEM, ... where predefined
>> selective segments of subsystem region can be dumped as part of
>> coredump collection which generates smaller size artifacts compared to
>> complete coredump of subsystem on crash.
>>
>> [1]
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/remoteproc/qcom_common.c#n142
>>
>> In addition to managing and querying the APSS minidump description,
>> the Linux driver maintains a ELF header in a segment. This segment
>> gets updated with section/program header whenever a new entry gets
>> registered.
>
> I'd like to test this series plus your series that sets the multiple
> download modes.

Sure, you are welcome, but for that you need a device running with 
Qualcomm SoC and if it has a upstream support.

Also, testing of this patch needs some minimal out of tree patches and
i can help you with that.

> Can you include documentation about how to actually use
> this new feature?

Will surely do, Since this is still RFC, and i am doubtful on the path 
of it in documentation directory.

  Also the information that you provided above is really
> useful. I think that should also go in the documentation file as well.
> 
> I already have a reliable way to make a board go BOOM and go into
> ramdump mode.

That's very nice to hear; but again if you can specify your target 
specification.

-Mukesh
> 
> Brian
>