[RESEND PATCH 1/2] dt-ops: Add helper API to dump fdt blob

[Bhupesh Sharma]

Hi Dave,

On Mon, Apr 16, 2018 at 1:43 PM, Dave Young <dyoung at redhat.com> wrote:
> Hi Bhupesh,
>
> On 04/03/18 at 07:28pm, Bhupesh Sharma wrote:
>> Hi James,
>>
>> Sorry for the delay, I had a long weekend last week.
>>
>> On Tue, Mar 27, 2018 at 7:01 PM, James Morse <james.morse at arm.com> wrote:
>> > 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.
>>
>> I captured the use case where it is not possible to do so. I have seen
>> primary kernel crash before we can get to the command prompt to save
>> the dtb blob. Since the arm64 crashkernel still seems to have issues
>> itself while booting on acpi enabled machines (see
>> <https://www.spinics.net/lists/arm-kernel/msg616632.html>), so we are
>> trying to debug a problem which has two undefined variables :)
>>
>> >>>> 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.
>>
>> That is pretty basic case on several new arm64 development boards
>> (e.g. qualcomm, huawei etc) where we are debugging issues in primary
>> kernel boot (and we are not even able to reach the command prompt).
>>
>> If the crashkernel crashes even before the primary kernel does because
>> of the issues in the way DTB is passed to the crashkernel (which can
>> include wrong DTB fields), we better have mechanisms to track the same
>> rather than adding debug prints to the kernels.
>
> In this case, since userspace always need to run 'kexec -l', there
> should be chance to save dtb and dump them in scripts if needed.
> If this is doable in scripts I also tend not to add the code in kexec-tools.

Perhaps you missed my latest email which explained the use case better
(please see [1]).
Please note that I am talking about the 'kexec -p' or the kdump use
case rather than the 'kexec -l' or the warm reboot to the second
kernel.

In several cases its useful if we are not able to reach the command
prompt to just modify the scriptware to launch 'kexec -p' when the
ramfs starts up so that we can catch crashes which happen before the
primary kernel reaches the command prompt. For example, on freescale
boards I found this scriptware mechanism quite useful on yocto based
distributions, as you can be porting a new upstream kernel on the
board and thus is not very stable while booting and the crashkernel
also has issues which causes it to crash. In such cases although we
see a panic message from the crashkernel it is very difficult to
deduce that it was because of some wrongly fixed up dtb property.

Getting a debug log which contains the dtb dump is very useful in
above cases for debugging.

Also saving the dtb requires 'dtc' tool to be installed which is an
additional dependency.

Since we have debug facility/messages already available when we
execute 'kexec -p' with '-d' flag we can use the dtb dumps from the
tool to debug crashes than happen in the crashkernel also because of
wrong dtb fields fixed up by 'kexec-tools'. I was loathe to keep this
patch locally and apply to the upstream 'kexec-tools' when debugging
these issues as I think it makes sense to improve our debugging
capabilities if we know there are issues around the same.

Ok, let me resend this patch with a cover letter this time to explain
the use case better and also to capture the dtb logs.

[1] https://marc.info/?l=kexec&m=152382169120505&w=2