| Message ID | 1698052857-6918-1-git-send-email-quic_zhenhuah@quicinc.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | soc/arm64: qcom: add initial version of memory dump | expand |
On 23/10/2023 11: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. How does it relate to minidump? > > User then get full dump using PCAT and can parse out these informations. > > 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. I don't think so (or you miss yamllint). $ git checkout v6.6-rc1 $ b4 am... $ dt_binding_chec qcom,mem-dump.yaml:5:10: [error] string value is redundantly quoted with any quotes (quoted-strings) Best regards, Krzysztof
On 2023/10/23 17:25, Krzysztof Kozlowski wrote: > On 23/10/2023 11: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. > > How does it relate to minidump? Minidump is used for dumping *software* related data/information. While the memory dump is used to communicate with firmware to dump *hardware* related information. > >> >> User then get full dump using PCAT and can parse out these informations. >> >> 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. > > I don't think so (or you miss yamllint). > > $ git checkout v6.6-rc1 > $ b4 am... > $ dt_binding_chec Apologize for this. I actually run it but seems some mistakes here, will be more careful next time. > > qcom,mem-dump.yaml:5:10: [error] string value is redundantly quoted with > any quotes (quoted-strings) > > > Best regards, > Krzysztof > Thanks, Zhenhua
On 23/10/2023 14:18, Zhenhua Huang wrote: > > > On 2023/10/23 17:25, Krzysztof Kozlowski wrote: >> On 23/10/2023 11: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. >> >> How does it relate to minidump? > > Minidump is used for dumping *software* related data/information. While > the memory dump is used to communicate with firmware to dump *hardware* > related information. I would argue then you should integrate both things... Best regards, Krzysztof
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? > 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. Exposing all of the user's data.. Is this enabled by default? > > 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. Is that only something that works on engineering / prototype devices? > User then get full dump using PCAT and can parse out these informations. Is PCAT open-source, or at least freely available? > > Dump id and size are provided by bootconfig. The expected format of a > bootconfig file is as follows:- Is it the same bootconfig that Google invented? Wasn't that just key=val? > 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. That's sorta ancient, especially since you're likely looking to get this merged in 6.8.. -next would probably be a better target. Konrad
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 >
On 2023/10/23 22:31, Caleb Connolly wrote: > > > 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. > Oh.. I saw PCAT is introduced in doc of RB5 development kit so tried with it as well. I will investigate more on this. Thanks. > 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 >> >
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. > >> 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. > Exposing all of the user's data.. Is this enabled by default? In theory it can be controlled by static bool download_mode = IS_ENABLED(CONFIG_QCOM_SCM_DOWNLOAD_MODE_DEFAULT); in driver qcom_scm.c. But from my local test on RB5, it can always enter into download mode seems. > >> >> 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. > Is that only something that works on engineering / prototype devices? > >> User then get full dump using PCAT and can parse out these informations. > Is PCAT open-source, or at least freely available? I see it is introduced in doc of development-kit for RB5, but in another mail Caleb mentioned it's still needing to sign up... which I need to further investigate. > >> >> Dump id and size are provided by bootconfig. The expected format of a >> bootconfig file is as follows:- > Is it the same bootconfig that Google invented? Wasn't that just key=val? Seems not same, the author is not from google :) it's kernel XBC(extra boot config): lib/bootconfig.c > >> 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. > That's sorta ancient, especially since you're likely looking to get > this merged in 6.8.. -next would probably be a better target. Sure, Thanks. Will verify in -next. > > Konrad Thanks, Zhenhua
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
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. 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