On Tue, Jul 17, 2018 at 02:13:42AM +0530, Bhupesh Sharma wrote: > Hi Akashi, > > On 07/09/2018 12:41 PM, AKASHI Takahiro wrote: > > Bhupesh, Simon, > > > > #I'm afraid that I gonna rehash the old discussion. > > > > Looking into ppc's kexec-tools code, I found that ppc version of > > this tool has a similar feature and it saves a new dtb into a file, > > named "debug.dtb." > > See save_fixed_up_dtb() in kexec/arch/ppc/fixup_dtb.c > > > > Even if it is a debug feature, we'd better go in the same way > > (if possible). > > Thanks for sharing the same. > > I had a look earlier also at the ppc - "debug.dtb" code in kexec-tools, but > this is again fails to fulfill the same purpose that we are trying to > resolve for early primary kernel crash(es) on arm64 machines, because of > which we are not able to reach the command prompt with the primary kernel > itself. > > We would need to either reach the command prompt to dump out/save the > "debug.dtb" file when we are running the primary kernel (which is > unfortunately not always possible wit latest kernels on some of the arm64 > machines), or use some initramfs scriptware to dump out the same to some > secondary storage device (nfs server or usb stick). > > So, I would still suggest to stick with the approach I proposed for now (and > we can take a similar approach as ppc for arm64 later on) once we have > kexec, kdump and other user-space utilities (which rely on the kexec kernel > framework) working stably on arm64 machines (with latest upstream kernels). That sounds like a reasonable argument to me. Akashi, what do you think? _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
