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
