[RESEND PATCH 1/2] dt-ops: Add helper API to dump fdt blob
james.morse at arm.com
Tue Mar 27 06:31:26 PDT 2018
Hi Akashi, Bhupesh,
On 27/03/18 10:04, AKASHI Takahiro wrote:
> On Mon, Mar 26, 2018 at 02:29:31PM +0530, Bhupesh Sharma wrote:
>> On Tue, Mar 20, 2018 at 12:36 AM, Bhupesh Sharma <bhsharma at redhat.com> wrote:
>>> On Mon, Mar 19, 2018 at 8:15 PM, AKASHI Takahiro
>>> <takahiro.akashi at linaro.org> wrote:
>>>> On Mon, Mar 19, 2018 at 04:05:38PM +0530, Bhupesh Sharma wrote:
>>>>> At several occasions it would be useful to dump the fdt
>>>>> blob being passed to the second (kexec/kdump) kernel
>>>>> when '-d' flag is specified while invoking kexec/kdump.
>>>> Why not just save binary data to a file and interpret it
>>>> with dtc command?
I'd prefer this too. It would also let us debug any issue where kexec-tools
produces an invalid DTB. It also lets us test booting the kernel from firmware
with that DTB.
>>> Well, there are a couple of reasons for that which can be understood
>>> from a system which is in a production environment (for e.g. I have
>>> worked on one arm64 system in the past which used a yocto based
>>> distribution in which kexec -p was launched with a -d option as a part
>>> of initial ramfs scriptware):
and panics before you get an interactive prompt or persistent storage? I think
this would be a pretty niche use-case. You could always base64-dump the dtb to
stdout from your script.
>>> - In a production environment, installing and executing tools like dtc
>>> (which might not have been installed by default via 'yum' or 'apt-get
>>> install' or other means is not only an additional step, but we might
>>> not get a chance to run it even if it is installed if we have a early
>>> crash in kdump itself (for e.g. consider the 'acpi table access' issue
>>> in the arm64 crashkernel we discussed some time back
Wouldn't it be possible to transfer the dumped DTB file off the machine before
the behaviour that brings the machine down? Kdump always requires a setup step
to load the kdump kernel/dtb. You have to decide to add the debug flags at this
point. I don't see how choosing to save the modified-DTB would be any different.
I assume the flow here is: do thingX, the kernel crashes. Enable kdump, do
thingX, kdump fails to boot. Enable kdump-debug. Do thingX...
>>> a) In such a case the primary kernel has already crashed, so we had no
>>> opportunity to run a dtc interpreter there and the kdump kernel itself
>>> has crashed in a very early boot phase. So we didn't get a chance to
>>> execute 'dtc' on the kdump kernel command prompt (if the kdump scripts
>>> are configured not to reboot the primary again).
Transfer it off the machine, save it somewhere persistent or print it to stdout
>>> b) Also when an early arm64 kdump crash is reported by a customer, we
>>> usually only have access to the primary and secondary console log
>>> which also might include the 'kexec -p -d' log messages, which can
>>> point us to a discrepancy in dtc nodes like 'linux,usable-memory"
>>> which might have caused a early crashkernel crash.
>>> Personally, so-far I have found this dtb dumping facility of use in
>>> debugging atleast a couple of arm64 crashkernel crash/panic issues.
>>> Till the arm64 kexec/kdump implementation matures further, I feel this
>>> dumping facility is of good use to ease crashkernel panic debugs.
>> Ping. Do you have any further comments on it?
> While I don't think dumping fdt is so useful as "kexec -d" option
> outputs enough information for me, you can go ahead.
More information about the kexec