How /sys/firmware/fdt getting created

How /sys/firmware/fdt getting created

[prabhakar.pkin]

Hi All,

I am working on Ubuntu-18.04 with UEFI on ARM64(64 bit) platform. The
UEFI used is having ACPI tables.

I am trying to understand where and how /sys/firmware/fdt is getting
created. is it created by UEFI or grub and passed to Linux?

below is the dts format of /sys/firmware/fdt.

/dts-v1/;

/ {

	chosen {
		linux,uefi-mmap-desc-ver = <0x1>;
		linux,uefi-mmap-desc-size = <0x30>;
		linux,uefi-mmap-size = <0xcc0>;
		linux,uefi-mmap-start = <0x0 0xeda13018>;
		linux,uefi-system-table = <0x0 0xfafd0018>;
		bootargs = "BOOT_IMAGE=/boot/vmlinuz-5.4.0-rc4+
root=UUID=798a858c-4f20-4b99-aa40-99bff9394093 ro crashkernel=2G
console=ttyAMA0";
		linux,initrd-end = <0x0 0xeb381a34>;
		linux,initrd-start = <0x0 0xdd5f5000>;
	};
};

also, under what scenario/config fields is getting added fdt.
	#size-cells = <0x02>;
	#address-cells = <0x02>;

--prabhakar (pk)

Re: [edk2-devel] How /sys/firmware/fdt getting created

[Ard Biesheuvel]

On Tue, 29 Oct 2019 at 18:17, Prabhakar Kushwaha
<prabhakar.pkin@gmail.com> wrote:
>
> Hi All,
>
> I am working on Ubuntu-18.04 with UEFI on ARM64(64 bit) platform. The
> UEFI used is having ACPI tables.
>
> I am trying to understand where and how /sys/firmware/fdt is getting
> created. is it created by UEFI or grub and passed to Linux?
>

Neither. It is created by Linux itself.



> below is the dts format of /sys/firmware/fdt.
>
> /dts-v1/;
>
> / {
>
>         chosen {
>                 linux,uefi-mmap-desc-ver = <0x1>;
>                 linux,uefi-mmap-desc-size = <0x30>;
>                 linux,uefi-mmap-size = <0xcc0>;
>                 linux,uefi-mmap-start = <0x0 0xeda13018>;
>                 linux,uefi-system-table = <0x0 0xfafd0018>;
>                 bootargs = "BOOT_IMAGE=/boot/vmlinuz-5.4.0-rc4+
> root=UUID=798a858c-4f20-4b99-aa40-99bff9394093 ro crashkernel=2G
> console=ttyAMA0";
>                 linux,initrd-end = <0x0 0xeb381a34>;
>                 linux,initrd-start = <0x0 0xdd5f5000>;
>         };
> };
>
> also, under what scenario/config fields is getting added fdt.
>         #size-cells = <0x02>;
>         #address-cells = <0x02>;
>
> --prabhakar (pk)
>
> 
>

Re: [edk2-devel] How /sys/firmware/fdt getting created

[Prabhakar Kushwaha]

On Wed, Oct 30, 2019 at 12:43 PM Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
>
> On Tue, 29 Oct 2019 at 18:17, Prabhakar Kushwaha
> <prabhakar.pkin@gmail.com> wrote:
> >
> > Hi All,
> >
> > I am working on Ubuntu-18.04 with UEFI on ARM64(64 bit) platform. The
> > UEFI used is having ACPI tables.
> >
> > I am trying to understand where and how /sys/firmware/fdt is getting
> > created. is it created by UEFI or grub and passed to Linux?
> >
>
> Neither. It is created by Linux itself.
>
>
>

Thanks Ard,

Can you please point me the code where it is getting created.
I want to add below in /sys/firmware/fdt.

#size-cells = <0x02>;
#address-cells = <0x02>;

--prabhakar (pk)

Re: [edk2-devel] How /sys/firmware/fdt getting created

[Ard Biesheuvel]

On Wed, 30 Oct 2019 at 08:36, Prabhakar Kushwaha
<prabhakar.pkin@gmail.com> wrote:
>
> On Wed, Oct 30, 2019 at 12:43 PM Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
> >
> > On Tue, 29 Oct 2019 at 18:17, Prabhakar Kushwaha
> > <prabhakar.pkin@gmail.com> wrote:
> > >
> > > Hi All,
> > >
> > > I am working on Ubuntu-18.04 with UEFI on ARM64(64 bit) platform. The
> > > UEFI used is having ACPI tables.
> > >
> > > I am trying to understand where and how /sys/firmware/fdt is getting
> > > created. is it created by UEFI or grub and passed to Linux?
> > >
> >
> > Neither. It is created by Linux itself.
> >
> >
> >
>
> Thanks Ard,
>
> Can you please point me the code where it is getting created.
> I want to add below in /sys/firmware/fdt.
>
> #size-cells = <0x02>;
> #address-cells = <0x02>;
>

Actually, in your case it is GRUB not the kernel that creates the FDT.
It does this to pass the initrd information.

So if you want to add these properties, you should add them there.

Can you explain why doing this is necessary?

Re: [edk2-devel] How /sys/firmware/fdt getting created

[Prabhakar Kushwaha]

On Wed, Oct 30, 2019 at 1:14 PM Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
>
> On Wed, 30 Oct 2019 at 08:36, Prabhakar Kushwaha
> <prabhakar.pkin@gmail.com> wrote:
> >
> > On Wed, Oct 30, 2019 at 12:43 PM Ard Biesheuvel
> > <ard.biesheuvel@linaro.org> wrote:
> > >
> > > On Tue, 29 Oct 2019 at 18:17, Prabhakar Kushwaha
> > > <prabhakar.pkin@gmail.com> wrote:
> > > >
> > > > Hi All,
> > > >
> > > > I am working on Ubuntu-18.04 with UEFI on ARM64(64 bit) platform. The
> > > > UEFI used is having ACPI tables.
> > > >
> > > > I am trying to understand where and how /sys/firmware/fdt is getting
> > > > created. is it created by UEFI or grub and passed to Linux?
> > > >
> > >
> > > Neither. It is created by Linux itself.
> > >
> > >
> > >
> >
> > Thanks Ard,
> >
> > Can you please point me the code where it is getting created.
> > I want to add below in /sys/firmware/fdt.
> >
> > #size-cells = <0x02>;
> > #address-cells = <0x02>;
> >
>
> Actually, in your case it is GRUB not the kernel that creates the FDT.
> It does this to pass the initrd information.
>
> So if you want to add these properties, you should add them there.
>
> Can you explain why doing this is necessary?

I am trying to test kexec -p (kdump feature) on CentOS-release
7.7.1908 and Ubuntu-18.04 distributions.

 "kexec -p" command show error on Ubuntu. While no error on CentOS

CentOS:
$ kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
-r`.img --reuse-cmdline
$    ==> No error

Ubuntu
$ kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initrd.img-`uname
-r` --reuse-cmdline
$ kexec: elfcorehdr doesn't fit cells-size.
$ kexec: setup_2nd_dtb failed.
$ kexec: load failed.
$ Cannot load /boot/vmlinuz-5.4.0-rc4+

Note: Both CentOS and Ubuntu has Linux-5.4-rc4 tag.

When i debugged further reason for Ubuntu error is due to
address-cells and size-cells as "1"
log from kexec tool :-
load_crashdump_segments: elfcorehdr 0x7f7cbfc000-0x7f7cbff7ff
read_1st_dtb: found name =dtb_sys  /sys/firmware/fdt
get_cells_size: #address-cells:1 #size-cells:1

On CentOS both values are "2".
log from kexec tool :-
load_crashdump_segments: elfcorehdr 0xbf98bf0000-0xbf98bf33ff
read_1st_dtb: found nmae=dtb_sys /sys/firmware/fdt
get_cells_size: #address-cells:2 #size-cells:2

Note: Kexec tool read values from /sys/firmware/fdt.

I am trying to figure out why 2 distributions showing different values.

--pk

Re: [edk2-devel] How /sys/firmware/fdt getting created

[Laszlo Ersek]

+Leif, comment at bottom

On 10/30/19 09:16, Prabhakar Kushwaha wrote:
> On Wed, Oct 30, 2019 at 1:14 PM Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
>>
>> On Wed, 30 Oct 2019 at 08:36, Prabhakar Kushwaha
>> <prabhakar.pkin@gmail.com> wrote:
>>>
>>> On Wed, Oct 30, 2019 at 12:43 PM Ard Biesheuvel
>>> <ard.biesheuvel@linaro.org> wrote:
>>>>
>>>> On Tue, 29 Oct 2019 at 18:17, Prabhakar Kushwaha
>>>> <prabhakar.pkin@gmail.com> wrote:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> I am working on Ubuntu-18.04 with UEFI on ARM64(64 bit) platform. The
>>>>> UEFI used is having ACPI tables.
>>>>>
>>>>> I am trying to understand where and how /sys/firmware/fdt is getting
>>>>> created. is it created by UEFI or grub and passed to Linux?
>>>>>
>>>>
>>>> Neither. It is created by Linux itself.
>>>>
>>>>
>>>>
>>>
>>> Thanks Ard,
>>>
>>> Can you please point me the code where it is getting created.
>>> I want to add below in /sys/firmware/fdt.
>>>
>>> #size-cells = <0x02>;
>>> #address-cells = <0x02>;
>>>
>>
>> Actually, in your case it is GRUB not the kernel that creates the FDT.
>> It does this to pass the initrd information.
>>
>> So if you want to add these properties, you should add them there.
>>
>> Can you explain why doing this is necessary?
> 
> I am trying to test kexec -p (kdump feature) on CentOS-release
> 7.7.1908 and Ubuntu-18.04 distributions.
> 
>  "kexec -p" command show error on Ubuntu. While no error on CentOS
> 
> CentOS:
> $ kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
> -r`.img --reuse-cmdline
> $    ==> No error
> 
> Ubuntu
> $ kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initrd.img-`uname
> -r` --reuse-cmdline
> $ kexec: elfcorehdr doesn't fit cells-size.
> $ kexec: setup_2nd_dtb failed.
> $ kexec: load failed.
> $ Cannot load /boot/vmlinuz-5.4.0-rc4+
> 
> Note: Both CentOS and Ubuntu has Linux-5.4-rc4 tag.
> 
> When i debugged further reason for Ubuntu error is due to
> address-cells and size-cells as "1"
> log from kexec tool :-
> load_crashdump_segments: elfcorehdr 0x7f7cbfc000-0x7f7cbff7ff
> read_1st_dtb: found name =dtb_sys  /sys/firmware/fdt
> get_cells_size: #address-cells:1 #size-cells:1
> 
> On CentOS both values are "2".
> log from kexec tool :-
> load_crashdump_segments: elfcorehdr 0xbf98bf0000-0xbf98bf33ff
> read_1st_dtb: found nmae=dtb_sys /sys/firmware/fdt
> get_cells_size: #address-cells:2 #size-cells:2
> 
> Note: Kexec tool read values from /sys/firmware/fdt.
> 
> I am trying to figure out why 2 distributions showing different values.

http://git.savannah.gnu.org/cgit/grub.git/commit/?id=347210a5d5ce655b95315f320faa515afb723c11

Ubuntu probably ships a grub version that lacks this commit.

(The commit was first released as part of upstream grub-2.04. I have no
idea what version of grub is shipped in the CentOS distro you mention
above -- it could be based upon upstream 2.04, or the upstream patch may
have been backported to CentOS.)

Thanks
Laszlo

Re: [edk2-devel] How /sys/firmware/fdt getting created

[Leif Lindholm]

On Thu, Oct 31, 2019 at 11:07:52AM +0100, Laszlo Ersek wrote:
> +Leif, comment at bottom

Thanks Laszlo. +Dann, -kexec.

> On 10/30/19 09:16, Prabhakar Kushwaha wrote:
> >> So if you want to add these properties, you should add them there.
> >>
> >> Can you explain why doing this is necessary?
> > 
> > I am trying to test kexec -p (kdump feature) on CentOS-release
> > 7.7.1908 and Ubuntu-18.04 distributions.
> > 
> >  "kexec -p" command show error on Ubuntu. While no error on CentOS
> > 
> > CentOS:
> > $ kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
> > -r`.img --reuse-cmdline
> > $    ==> No error
> > 
> > Ubuntu
> > $ kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initrd.img-`uname
> > -r` --reuse-cmdline
> > $ kexec: elfcorehdr doesn't fit cells-size.
> > $ kexec: setup_2nd_dtb failed.
> > $ kexec: load failed.
> > $ Cannot load /boot/vmlinuz-5.4.0-rc4+
> > 
> > Note: Both CentOS and Ubuntu has Linux-5.4-rc4 tag.
> > 
> > When i debugged further reason for Ubuntu error is due to
> > address-cells and size-cells as "1"
> > log from kexec tool :-
> > load_crashdump_segments: elfcorehdr 0x7f7cbfc000-0x7f7cbff7ff
> > read_1st_dtb: found name =dtb_sys  /sys/firmware/fdt
> > get_cells_size: #address-cells:1 #size-cells:1
> > 
> > On CentOS both values are "2".
> > log from kexec tool :-
> > load_crashdump_segments: elfcorehdr 0xbf98bf0000-0xbf98bf33ff
> > read_1st_dtb: found nmae=dtb_sys /sys/firmware/fdt
> > get_cells_size: #address-cells:2 #size-cells:2
> > 
> > Note: Kexec tool read values from /sys/firmware/fdt.
> > 
> > I am trying to figure out why 2 distributions showing different values.
> 
> http://git.savannah.gnu.org/cgit/grub.git/commit/?id=347210a5d5ce655b95315f320faa515afb723c11
> 
> Ubuntu probably ships a grub version that lacks this commit.

Yes, it came after the 18.04 release.
Dann: given that 18.04 is LTS, would it be reasonable to cherry-pick
this grub patch? I would consider the behaviour without it to be a
bug.

/
    Leif

> (The commit was first released as part of upstream grub-2.04. I have no
> idea what version of grub is shipped in the CentOS distro you mention
> above -- it could be based upon upstream 2.04, or the upstream patch may
> have been backported to CentOS.)
> 
> Thanks
> Laszlo
> 

Re: [edk2-devel] How /sys/firmware/fdt getting created

[dann frazier]

On Thu, Oct 31, 2019 at 6:16 AM Leif Lindholm <leif.lindholm@linaro.org> wrote:
>
> On Thu, Oct 31, 2019 at 11:07:52AM +0100, Laszlo Ersek wrote:
> > +Leif, comment at bottom
>
> Thanks Laszlo. +Dann, -kexec.
>
> > On 10/30/19 09:16, Prabhakar Kushwaha wrote:
> > >> So if you want to add these properties, you should add them there.
> > >>
> > >> Can you explain why doing this is necessary?
> > >
> > > I am trying to test kexec -p (kdump feature) on CentOS-release
> > > 7.7.1908 and Ubuntu-18.04 distributions.
> > >
> > >  "kexec -p" command show error on Ubuntu. While no error on CentOS
> > >
> > > CentOS:
> > > $ kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
> > > -r`.img --reuse-cmdline
> > > $    ==> No error
> > >
> > > Ubuntu
> > > $ kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initrd.img-`uname
> > > -r` --reuse-cmdline
> > > $ kexec: elfcorehdr doesn't fit cells-size.
> > > $ kexec: setup_2nd_dtb failed.
> > > $ kexec: load failed.
> > > $ Cannot load /boot/vmlinuz-5.4.0-rc4+
> > >
> > > Note: Both CentOS and Ubuntu has Linux-5.4-rc4 tag.
> > >
> > > When i debugged further reason for Ubuntu error is due to
> > > address-cells and size-cells as "1"
> > > log from kexec tool :-
> > > load_crashdump_segments: elfcorehdr 0x7f7cbfc000-0x7f7cbff7ff
> > > read_1st_dtb: found name =dtb_sys  /sys/firmware/fdt
> > > get_cells_size: #address-cells:1 #size-cells:1
> > >
> > > On CentOS both values are "2".
> > > log from kexec tool :-
> > > load_crashdump_segments: elfcorehdr 0xbf98bf0000-0xbf98bf33ff
> > > read_1st_dtb: found nmae=dtb_sys /sys/firmware/fdt
> > > get_cells_size: #address-cells:2 #size-cells:2
> > >
> > > Note: Kexec tool read values from /sys/firmware/fdt.
> > >
> > > I am trying to figure out why 2 distributions showing different values.
> >
> > http://git.savannah.gnu.org/cgit/grub.git/commit/?id=347210a5d5ce655b95315f320faa515afb723c11
> >
> > Ubuntu probably ships a grub version that lacks this commit.
>
> Yes, it came after the 18.04 release.
> Dann: given that 18.04 is LTS, would it be reasonable to cherry-pick
> this grub patch? I would consider the behaviour without it to be a
> bug.

Leif,

  Likely - I'll run some tests and get back to you...

 -dann

> /
>     Leif
>
> > (The commit was first released as part of upstream grub-2.04. I have no
> > idea what version of grub is shipped in the CentOS distro you mention
> > above -- it could be based upon upstream 2.04, or the upstream patch may
> > have been backported to CentOS.)
> >
> > Thanks
> > Laszlo
> >

Re: [edk2-devel] How /sys/firmware/fdt getting created

[Bhupesh Sharma]

Hi Prabhakar,

On Wed, Oct 30, 2019 at 1:47 PM Prabhakar Kushwaha
<prabhakar.pkin@gmail.com> wrote:
>
> On Wed, Oct 30, 2019 at 1:14 PM Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
> >
> > On Wed, 30 Oct 2019 at 08:36, Prabhakar Kushwaha
> > <prabhakar.pkin@gmail.com> wrote:
> > >
> > > On Wed, Oct 30, 2019 at 12:43 PM Ard Biesheuvel
> > > <ard.biesheuvel@linaro.org> wrote:
> > > >
> > > > On Tue, 29 Oct 2019 at 18:17, Prabhakar Kushwaha
> > > > <prabhakar.pkin@gmail.com> wrote:
> > > > >
> > > > > Hi All,
> > > > >
> > > > > I am working on Ubuntu-18.04 with UEFI on ARM64(64 bit) platform. The
> > > > > UEFI used is having ACPI tables.
> > > > >
> > > > > I am trying to understand where and how /sys/firmware/fdt is getting
> > > > > created. is it created by UEFI or grub and passed to Linux?
> > > > >
> > > >
> > > > Neither. It is created by Linux itself.
> > > >
> > > >
> > > >
> > >
> > > Thanks Ard,
> > >
> > > Can you please point me the code where it is getting created.
> > > I want to add below in /sys/firmware/fdt.
> > >
> > > #size-cells = <0x02>;
> > > #address-cells = <0x02>;
> > >
> >
> > Actually, in your case it is GRUB not the kernel that creates the FDT.
> > It does this to pass the initrd information.
> >
> > So if you want to add these properties, you should add them there.
> >
> > Can you explain why doing this is necessary?
>
> I am trying to test kexec -p (kdump feature) on CentOS-release
> 7.7.1908 and Ubuntu-18.04 distributions.
>
>  "kexec -p" command show error on Ubuntu. While no error on CentOS
>
> CentOS:
> $ kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
> -r`.img --reuse-cmdline
> $    ==> No error
>
> Ubuntu
> $ kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initrd.img-`uname
> -r` --reuse-cmdline
> $ kexec: elfcorehdr doesn't fit cells-size.
> $ kexec: setup_2nd_dtb failed.
> $ kexec: load failed.
> $ Cannot load /boot/vmlinuz-5.4.0-rc4+
>
> Note: Both CentOS and Ubuntu has Linux-5.4-rc4 tag.
>
> When i debugged further reason for Ubuntu error is due to
> address-cells and size-cells as "1"
> log from kexec tool :-
> load_crashdump_segments: elfcorehdr 0x7f7cbfc000-0x7f7cbff7ff
> read_1st_dtb: found name =dtb_sys  /sys/firmware/fdt
> get_cells_size: #address-cells:1 #size-cells:1
>
> On CentOS both values are "2".
> log from kexec tool :-
> load_crashdump_segments: elfcorehdr 0xbf98bf0000-0xbf98bf33ff
> read_1st_dtb: found nmae=dtb_sys /sys/firmware/fdt
> get_cells_size: #address-cells:2 #size-cells:2
>
> Note: Kexec tool read values from /sys/firmware/fdt.
>
> I am trying to figure out why 2 distributions showing different values.

There are a couple of things I can suggest:

1. Try to see if it is a kexec-tools specific issue or is the kernel
itself passed an incorrectly fixed DTB (by grub?) with incorrect
#address-cells and #size-cells values (in the past I have seen
kexec-tools sometimes reports incorrect #address-cells and #size-cells
values, but they should be fixed in the newer kexec-tools versions):

a). Can you check the kexec-tools version and share the same:
$ kexec -v

b). Using 'dtc' tool, you can confirm if it reports a correct
#address-cells and #size-cells values:
# dtc -I dtb -O dts /sys/firmware/fdt | grep cells | less

For e.g on my fedora arm64 system, it reports:
    #address-cells = <0x2>;
    #size-cells = <0x2>;

2a). If its not a kexec-tools specific issue, it is most probably a
bootloader (grub?) issue in your case:

For e.g. I use the following grub2 on my Fedora arm64 board:
<https://github.com/rhboot/grub2>
and <https://github.com/rhboot/grub2/blob/master/grub-core/loader/efi/fdt.c#L34>
contains the changes to send the correct #address-cells and
#size-cells values to Linux (and hence user-space tools like
kexec-tools later).

I believe the same grub2 is used (backported) for CentOS, so things
should be fine there.

2b). I see that the latest devel branch of ubuntu grub2
(<https://code.launchpad.net/ubuntu/+source/grub2>) also contains this
fix, but I am not sure which grub2 version you have on your ubuntu
machine.

But you can do some debugging on the same by stopping the boot process
on the grub prompt and debugging grub further to check the version and
fixes done in fdt there. See
<https://help.ubuntu.com/community/Grub2/Troubleshooting> for details.

Hope this helps.

Thanks,
Bhupesh

Re: [edk2-devel] How /sys/firmware/fdt getting created

[dann frazier]

On Thu, Oct 31, 2019 at 12:55:10PM -0600, dann frazier wrote:
> On Thu, Oct 31, 2019 at 6:16 AM Leif Lindholm <leif.lindholm@linaro.org> wrote:
> >
> > On Thu, Oct 31, 2019 at 11:07:52AM +0100, Laszlo Ersek wrote:
> > > +Leif, comment at bottom
> >
> > Thanks Laszlo. +Dann, -kexec.
> >
> > > On 10/30/19 09:16, Prabhakar Kushwaha wrote:
> > > >> So if you want to add these properties, you should add them there.
> > > >>
> > > >> Can you explain why doing this is necessary?
> > > >
> > > > I am trying to test kexec -p (kdump feature) on CentOS-release
> > > > 7.7.1908 and Ubuntu-18.04 distributions.
> > > >
> > > >  "kexec -p" command show error on Ubuntu. While no error on CentOS
> > > >
> > > > CentOS:
> > > > $ kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
> > > > -r`.img --reuse-cmdline
> > > > $    ==> No error
> > > >
> > > > Ubuntu
> > > > $ kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initrd.img-`uname
> > > > -r` --reuse-cmdline
> > > > $ kexec: elfcorehdr doesn't fit cells-size.
> > > > $ kexec: setup_2nd_dtb failed.
> > > > $ kexec: load failed.
> > > > $ Cannot load /boot/vmlinuz-5.4.0-rc4+
> > > >
> > > > Note: Both CentOS and Ubuntu has Linux-5.4-rc4 tag.
> > > >
> > > > When i debugged further reason for Ubuntu error is due to
> > > > address-cells and size-cells as "1"
> > > > log from kexec tool :-
> > > > load_crashdump_segments: elfcorehdr 0x7f7cbfc000-0x7f7cbff7ff
> > > > read_1st_dtb: found name =dtb_sys  /sys/firmware/fdt
> > > > get_cells_size: #address-cells:1 #size-cells:1
> > > >
> > > > On CentOS both values are "2".
> > > > log from kexec tool :-
> > > > load_crashdump_segments: elfcorehdr 0xbf98bf0000-0xbf98bf33ff
> > > > read_1st_dtb: found nmae=dtb_sys /sys/firmware/fdt
> > > > get_cells_size: #address-cells:2 #size-cells:2
> > > >
> > > > Note: Kexec tool read values from /sys/firmware/fdt.
> > > >
> > > > I am trying to figure out why 2 distributions showing different values.
> > >
> > > http://git.savannah.gnu.org/cgit/grub.git/commit/?id=347210a5d5ce655b95315f320faa515afb723c11
> > >
> > > Ubuntu probably ships a grub version that lacks this commit.
> >
> > Yes, it came after the 18.04 release.
> > Dann: given that 18.04 is LTS, would it be reasonable to cherry-pick
> > this grub patch? I would consider the behaviour without it to be a
> > bug.
> 
> Leif,
> 
>   Likely - I'll run some tests and get back to you...

Can you help me understand the scenario in which the above patch is
required? I tested an 18.04 VM w/ AAVMF (ACPI-mode), and kexec -p
worked fine. I also verified that 18.04 does not carry the above patch.

  -dann

> 
> > /
> >     Leif
> >
> > > (The commit was first released as part of upstream grub-2.04. I have no
> > > idea what version of grub is shipped in the CentOS distro you mention
> > > above -- it could be based upon upstream 2.04, or the upstream patch may
> > > have been backported to CentOS.)
> > >
> > > Thanks
> > > Laszlo
> > >
> 
> 
> 

Re: [edk2-devel] How /sys/firmware/fdt getting created

[Prabhakar Kushwaha]

On Fri, Nov 1, 2019 at 2:04 AM dann frazier <dann.frazier@canonical.com> wrote:
>
> On Thu, Oct 31, 2019 at 12:55:10PM -0600, dann frazier wrote:
> > On Thu, Oct 31, 2019 at 6:16 AM Leif Lindholm <leif.lindholm@linaro.org> wrote:
> > >
> > > On Thu, Oct 31, 2019 at 11:07:52AM +0100, Laszlo Ersek wrote:
> > > > +Leif, comment at bottom
> > >
> > > Thanks Laszlo. +Dann, -kexec.
> > >
> > > > On 10/30/19 09:16, Prabhakar Kushwaha wrote:
> > > > >> So if you want to add these properties, you should add them there.
> > > > >>
> > > > >> Can you explain why doing this is necessary?
> > > > >
> > > > > I am trying to test kexec -p (kdump feature) on CentOS-release
> > > > > 7.7.1908 and Ubuntu-18.04 distributions.
> > > > >
> > > > >  "kexec -p" command show error on Ubuntu. While no error on CentOS
> > > > >
> > > > > CentOS:
> > > > > $ kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
> > > > > -r`.img --reuse-cmdline
> > > > > $    ==> No error
> > > > >
> > > > > Ubuntu
> > > > > $ kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initrd.img-`uname
> > > > > -r` --reuse-cmdline
> > > > > $ kexec: elfcorehdr doesn't fit cells-size.
> > > > > $ kexec: setup_2nd_dtb failed.
> > > > > $ kexec: load failed.
> > > > > $ Cannot load /boot/vmlinuz-5.4.0-rc4+
> > > > >
> > > > > Note: Both CentOS and Ubuntu has Linux-5.4-rc4 tag.
> > > > >
> > > > > When i debugged further reason for Ubuntu error is due to
> > > > > address-cells and size-cells as "1"
> > > > > log from kexec tool :-
> > > > > load_crashdump_segments: elfcorehdr 0x7f7cbfc000-0x7f7cbff7ff
> > > > > read_1st_dtb: found name =dtb_sys  /sys/firmware/fdt
> > > > > get_cells_size: #address-cells:1 #size-cells:1
> > > > >
> > > > > On CentOS both values are "2".
> > > > > log from kexec tool :-
> > > > > load_crashdump_segments: elfcorehdr 0xbf98bf0000-0xbf98bf33ff
> > > > > read_1st_dtb: found nmae=dtb_sys /sys/firmware/fdt
> > > > > get_cells_size: #address-cells:2 #size-cells:2
> > > > >
> > > > > Note: Kexec tool read values from /sys/firmware/fdt.
> > > > >
> > > > > I am trying to figure out why 2 distributions showing different values.
> > > >
> > > > http://git.savannah.gnu.org/cgit/grub.git/commit/?id=347210a5d5ce655b95315f320faa515afb723c11
> > > >
> > > > Ubuntu probably ships a grub version that lacks this commit.
> > >
> > > Yes, it came after the 18.04 release.
> > > Dann: given that 18.04 is LTS, would it be reasonable to cherry-pick
> > > this grub patch? I would consider the behaviour without it to be a
> > > bug.
> >
> > Leif,
> >
> >   Likely - I'll run some tests and get back to you...
>
> Can you help me understand the scenario in which the above patch is
> required? I tested an 18.04 VM w/ AAVMF (ACPI-mode), and kexec -p
> worked fine. I also verified that 18.04 does not carry the above patch.
>

This issue is only visible when crashkernel region reserved beyond 4GB
by kernel.
I reproduced this issue by providing "crashkernel=2G" in bootargs.

if kernel is not reserving memory due to crashkernel region
overlapping with "reserved regions", you can apply below patch.
https://patchwork.kernel.org/patch/10144305/

Update: When I migrated ubuntu grub to 2.05 this issue is gone.

--pk

Re: [edk2-devel] How /sys/firmware/fdt getting created

[Prabhakar Kushwaha]

Hi Bhupesh,

On Fri, Nov 1, 2019 at 1:59 AM Bhupesh Sharma <bhsharma@redhat.com> wrote:
>
> Hi Prabhakar,
>
> On Wed, Oct 30, 2019 at 1:47 PM Prabhakar Kushwaha
> <prabhakar.pkin@gmail.com> wrote:
> >
> > On Wed, Oct 30, 2019 at 1:14 PM Ard Biesheuvel
> > <ard.biesheuvel@linaro.org> wrote:
> > >
> > > On Wed, 30 Oct 2019 at 08:36, Prabhakar Kushwaha
> > > <prabhakar.pkin@gmail.com> wrote:
> > > >
> > > > On Wed, Oct 30, 2019 at 12:43 PM Ard Biesheuvel
> > > > <ard.biesheuvel@linaro.org> wrote:
> > > > >
> > > > > On Tue, 29 Oct 2019 at 18:17, Prabhakar Kushwaha
> > > > > <prabhakar.pkin@gmail.com> wrote:
> > > > > >
> > > > > > Hi All,
> > > > > >
> > > > > > I am working on Ubuntu-18.04 with UEFI on ARM64(64 bit) platform. The
> > > > > > UEFI used is having ACPI tables.
> > > > > >
> > > > > > I am trying to understand where and how /sys/firmware/fdt is getting
> > > > > > created. is it created by UEFI or grub and passed to Linux?
> > > > > >
> > > > >
> > > > > Neither. It is created by Linux itself.
> > > > >
> > > > >
> > > > >
> > > >
> > > > Thanks Ard,
> > > >
> > > > Can you please point me the code where it is getting created.
> > > > I want to add below in /sys/firmware/fdt.
> > > >
> > > > #size-cells = <0x02>;
> > > > #address-cells = <0x02>;
> > > >
> > >
> > > Actually, in your case it is GRUB not the kernel that creates the FDT.
> > > It does this to pass the initrd information.
> > >
> > > So if you want to add these properties, you should add them there.
> > >
> > > Can you explain why doing this is necessary?
> >
> > I am trying to test kexec -p (kdump feature) on CentOS-release
> > 7.7.1908 and Ubuntu-18.04 distributions.
> >
> >  "kexec -p" command show error on Ubuntu. While no error on CentOS
> >
> > CentOS:
> > $ kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
> > -r`.img --reuse-cmdline
> > $    ==> No error
> >
> > Ubuntu
> > $ kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initrd.img-`uname
> > -r` --reuse-cmdline
> > $ kexec: elfcorehdr doesn't fit cells-size.
> > $ kexec: setup_2nd_dtb failed.
> > $ kexec: load failed.
> > $ Cannot load /boot/vmlinuz-5.4.0-rc4+
> >
> > Note: Both CentOS and Ubuntu has Linux-5.4-rc4 tag.
> >
> > When i debugged further reason for Ubuntu error is due to
> > address-cells and size-cells as "1"
> > log from kexec tool :-
> > load_crashdump_segments: elfcorehdr 0x7f7cbfc000-0x7f7cbff7ff
> > read_1st_dtb: found name =dtb_sys  /sys/firmware/fdt
> > get_cells_size: #address-cells:1 #size-cells:1
> >
> > On CentOS both values are "2".
> > log from kexec tool :-
> > load_crashdump_segments: elfcorehdr 0xbf98bf0000-0xbf98bf33ff
> > read_1st_dtb: found nmae=dtb_sys /sys/firmware/fdt
> > get_cells_size: #address-cells:2 #size-cells:2
> >
> > Note: Kexec tool read values from /sys/firmware/fdt.
> >
> > I am trying to figure out why 2 distributions showing different values.
>
> There are a couple of things I can suggest:
>
> 1. Try to see if it is a kexec-tools specific issue or is the kernel
> itself passed an incorrectly fixed DTB (by grub?) with incorrect
> #address-cells and #size-cells values (in the past I have seen
> kexec-tools sometimes reports incorrect #address-cells and #size-cells
> values, but they should be fixed in the newer kexec-tools versions):
>
> a). Can you check the kexec-tools version and share the same:
> $ kexec -v
>
> b). Using 'dtc' tool, you can confirm if it reports a correct
> #address-cells and #size-cells values:
> # dtc -I dtb -O dts /sys/firmware/fdt | grep cells | less
>
> For e.g on my fedora arm64 system, it reports:
>     #address-cells = <0x2>;
>     #size-cells = <0x2>;
>
> 2a). If its not a kexec-tools specific issue, it is most probably a
> bootloader (grub?) issue in your case:
>
> For e.g. I use the following grub2 on my Fedora arm64 board:
> <https://github.com/rhboot/grub2>
> and <https://github.com/rhboot/grub2/blob/master/grub-core/loader/efi/fdt.c#L34>
> contains the changes to send the correct #address-cells and
> #size-cells values to Linux (and hence user-space tools like
> kexec-tools later).
>
> I believe the same grub2 is used (backported) for CentOS, so things
> should be fine there.
>
> 2b). I see that the latest devel branch of ubuntu grub2
> (<https://code.launchpad.net/ubuntu/+source/grub2>) also contains this
> fix, but I am not sure which grub2 version you have on your ubuntu
> machine.
>

Ubuntu 18.04 has grub 2.02. When i migrated to grub 2.05, this issue
is not there.
Most probably the patch which is mentioned by Laszlo done the fix.

http://git.savannah.gnu.org/cgit/grub.git/commit/?id=347210a5d5ce655b95315f320faa515afb723c11

Thanks
--pk

Re: [edk2-devel] How /sys/firmware/fdt getting created

[Bhupesh Sharma]

Hi Prabhakar,


On Fri, Nov 1, 2019 at 10:22 AM Prabhakar Kushwaha
<prabhakar.pkin@gmail.com> wrote:
>
> Hi Bhupesh,
>
> On Fri, Nov 1, 2019 at 1:59 AM Bhupesh Sharma <bhsharma@redhat.com> wrote:
> >
> > Hi Prabhakar,
> >
> > On Wed, Oct 30, 2019 at 1:47 PM Prabhakar Kushwaha
> > <prabhakar.pkin@gmail.com> wrote:
> > >
> > > On Wed, Oct 30, 2019 at 1:14 PM Ard Biesheuvel
> > > <ard.biesheuvel@linaro.org> wrote:
> > > >
> > > > On Wed, 30 Oct 2019 at 08:36, Prabhakar Kushwaha
> > > > <prabhakar.pkin@gmail.com> wrote:
> > > > >
> > > > > On Wed, Oct 30, 2019 at 12:43 PM Ard Biesheuvel
> > > > > <ard.biesheuvel@linaro.org> wrote:
> > > > > >
> > > > > > On Tue, 29 Oct 2019 at 18:17, Prabhakar Kushwaha
> > > > > > <prabhakar.pkin@gmail.com> wrote:
> > > > > > >
> > > > > > > Hi All,
> > > > > > >
> > > > > > > I am working on Ubuntu-18.04 with UEFI on ARM64(64 bit) platform. The
> > > > > > > UEFI used is having ACPI tables.
> > > > > > >
> > > > > > > I am trying to understand where and how /sys/firmware/fdt is getting
> > > > > > > created. is it created by UEFI or grub and passed to Linux?
> > > > > > >
> > > > > >
> > > > > > Neither. It is created by Linux itself.
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > Thanks Ard,
> > > > >
> > > > > Can you please point me the code where it is getting created.
> > > > > I want to add below in /sys/firmware/fdt.
> > > > >
> > > > > #size-cells = <0x02>;
> > > > > #address-cells = <0x02>;
> > > > >
> > > >
> > > > Actually, in your case it is GRUB not the kernel that creates the FDT.
> > > > It does this to pass the initrd information.
> > > >
> > > > So if you want to add these properties, you should add them there.
> > > >
> > > > Can you explain why doing this is necessary?
> > >
> > > I am trying to test kexec -p (kdump feature) on CentOS-release
> > > 7.7.1908 and Ubuntu-18.04 distributions.
> > >
> > >  "kexec -p" command show error on Ubuntu. While no error on CentOS
> > >
> > > CentOS:
> > > $ kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
> > > -r`.img --reuse-cmdline
> > > $    ==> No error
> > >
> > > Ubuntu
> > > $ kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initrd.img-`uname
> > > -r` --reuse-cmdline
> > > $ kexec: elfcorehdr doesn't fit cells-size.
> > > $ kexec: setup_2nd_dtb failed.
> > > $ kexec: load failed.
> > > $ Cannot load /boot/vmlinuz-5.4.0-rc4+
> > >
> > > Note: Both CentOS and Ubuntu has Linux-5.4-rc4 tag.
> > >
> > > When i debugged further reason for Ubuntu error is due to
> > > address-cells and size-cells as "1"
> > > log from kexec tool :-
> > > load_crashdump_segments: elfcorehdr 0x7f7cbfc000-0x7f7cbff7ff
> > > read_1st_dtb: found name =dtb_sys  /sys/firmware/fdt
> > > get_cells_size: #address-cells:1 #size-cells:1
> > >
> > > On CentOS both values are "2".
> > > log from kexec tool :-
> > > load_crashdump_segments: elfcorehdr 0xbf98bf0000-0xbf98bf33ff
> > > read_1st_dtb: found nmae=dtb_sys /sys/firmware/fdt
> > > get_cells_size: #address-cells:2 #size-cells:2
> > >
> > > Note: Kexec tool read values from /sys/firmware/fdt.
> > >
> > > I am trying to figure out why 2 distributions showing different values.
> >
> > There are a couple of things I can suggest:
> >
> > 1. Try to see if it is a kexec-tools specific issue or is the kernel
> > itself passed an incorrectly fixed DTB (by grub?) with incorrect
> > #address-cells and #size-cells values (in the past I have seen
> > kexec-tools sometimes reports incorrect #address-cells and #size-cells
> > values, but they should be fixed in the newer kexec-tools versions):
> >
> > a). Can you check the kexec-tools version and share the same:
> > $ kexec -v
> >
> > b). Using 'dtc' tool, you can confirm if it reports a correct
> > #address-cells and #size-cells values:
> > # dtc -I dtb -O dts /sys/firmware/fdt | grep cells | less
> >
> > For e.g on my fedora arm64 system, it reports:
> >     #address-cells = <0x2>;
> >     #size-cells = <0x2>;
> >
> > 2a). If its not a kexec-tools specific issue, it is most probably a
> > bootloader (grub?) issue in your case:
> >
> > For e.g. I use the following grub2 on my Fedora arm64 board:
> > <https://github.com/rhboot/grub2>
> > and <https://github.com/rhboot/grub2/blob/master/grub-core/loader/efi/fdt.c#L34>
> > contains the changes to send the correct #address-cells and
> > #size-cells values to Linux (and hence user-space tools like
> > kexec-tools later).
> >
> > I believe the same grub2 is used (backported) for CentOS, so things
> > should be fine there.
> >
> > 2b). I see that the latest devel branch of ubuntu grub2
> > (<https://code.launchpad.net/ubuntu/+source/grub2>) also contains this
> > fix, but I am not sure which grub2 version you have on your ubuntu
> > machine.
> >
>
> Ubuntu 18.04 has grub 2.02. When i migrated to grub 2.05, this issue
> is not there.
> Most probably the patch which is mentioned by Laszlo done the fix.
>
> http://git.savannah.gnu.org/cgit/grub.git/commit/?id=347210a5d5ce655b95315f320faa515afb723c11

That's good news. I am also glad its not a kexec-tools issues which I
need to fix :)
Thanks for sharing the update.

Regards,
Bhupesh

Re: [edk2-devel] How /sys/firmware/fdt getting created

[dann frazier]

On Fri, Nov 01, 2019 at 10:17:30AM +0530, Prabhakar Kushwaha wrote:
> On Fri, Nov 1, 2019 at 2:04 AM dann frazier <dann.frazier@canonical.com> wrote:
> >
> > On Thu, Oct 31, 2019 at 12:55:10PM -0600, dann frazier wrote:
> > > On Thu, Oct 31, 2019 at 6:16 AM Leif Lindholm <leif.lindholm@linaro.org> wrote:
> > > >
> > > > On Thu, Oct 31, 2019 at 11:07:52AM +0100, Laszlo Ersek wrote:
> > > > > +Leif, comment at bottom
> > > >
> > > > Thanks Laszlo. +Dann, -kexec.
> > > >
> > > > > On 10/30/19 09:16, Prabhakar Kushwaha wrote:
> > > > > >> So if you want to add these properties, you should add them there.
> > > > > >>
> > > > > >> Can you explain why doing this is necessary?
> > > > > >
> > > > > > I am trying to test kexec -p (kdump feature) on CentOS-release
> > > > > > 7.7.1908 and Ubuntu-18.04 distributions.
> > > > > >
> > > > > >  "kexec -p" command show error on Ubuntu. While no error on CentOS
> > > > > >
> > > > > > CentOS:
> > > > > > $ kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
> > > > > > -r`.img --reuse-cmdline
> > > > > > $    ==> No error
> > > > > >
> > > > > > Ubuntu
> > > > > > $ kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initrd.img-`uname
> > > > > > -r` --reuse-cmdline
> > > > > > $ kexec: elfcorehdr doesn't fit cells-size.
> > > > > > $ kexec: setup_2nd_dtb failed.
> > > > > > $ kexec: load failed.
> > > > > > $ Cannot load /boot/vmlinuz-5.4.0-rc4+
> > > > > >
> > > > > > Note: Both CentOS and Ubuntu has Linux-5.4-rc4 tag.
> > > > > >
> > > > > > When i debugged further reason for Ubuntu error is due to
> > > > > > address-cells and size-cells as "1"
> > > > > > log from kexec tool :-
> > > > > > load_crashdump_segments: elfcorehdr 0x7f7cbfc000-0x7f7cbff7ff
> > > > > > read_1st_dtb: found name =dtb_sys  /sys/firmware/fdt
> > > > > > get_cells_size: #address-cells:1 #size-cells:1
> > > > > >
> > > > > > On CentOS both values are "2".
> > > > > > log from kexec tool :-
> > > > > > load_crashdump_segments: elfcorehdr 0xbf98bf0000-0xbf98bf33ff
> > > > > > read_1st_dtb: found nmae=dtb_sys /sys/firmware/fdt
> > > > > > get_cells_size: #address-cells:2 #size-cells:2
> > > > > >
> > > > > > Note: Kexec tool read values from /sys/firmware/fdt.
> > > > > >
> > > > > > I am trying to figure out why 2 distributions showing different values.
> > > > >
> > > > > http://git.savannah.gnu.org/cgit/grub.git/commit/?id=347210a5d5ce655b95315f320faa515afb723c11
> > > > >
> > > > > Ubuntu probably ships a grub version that lacks this commit.
> > > >
> > > > Yes, it came after the 18.04 release.
> > > > Dann: given that 18.04 is LTS, would it be reasonable to cherry-pick
> > > > this grub patch? I would consider the behaviour without it to be a
> > > > bug.
> > >
> > > Leif,
> > >
> > >   Likely - I'll run some tests and get back to you...
> >
> > Can you help me understand the scenario in which the above patch is
> > required? I tested an 18.04 VM w/ AAVMF (ACPI-mode), and kexec -p
> > worked fine. I also verified that 18.04 does not carry the above patch.
> >
> 
> This issue is only visible when crashkernel region reserved beyond 4GB
> by kernel.
> I reproduced this issue by providing "crashkernel=2G" in bootargs.

Prabhakar,

Thanks. I was able to reproduce w/ crashkernel=1G@4G.

In order to get this addressed in 18.04 we'll need a LP bug to track
it - would you mind filing one at
https://bugs.launchpad.net/ubuntu/+source/grub2 and subscribing me
(lpid dannf) to it?

  -dann

> 
> if kernel is not reserving memory due to crashkernel region
> overlapping with "reserved regions", you can apply below patch.
> https://patchwork.kernel.org/patch/10144305/
> 
> Update: When I migrated ubuntu grub to 2.05 this issue is gone.
> 
> --pk

Re: [edk2-devel] How /sys/firmware/fdt getting created

[Prabhakar Kushwaha]

Dear Dann Frazier,

On Fri, Nov 1, 2019 at 9:55 PM dann frazier <dann.frazier@canonical.com> wrote:
>
> On Fri, Nov 01, 2019 at 10:17:30AM +0530, Prabhakar Kushwaha wrote:
> > On Fri, Nov 1, 2019 at 2:04 AM dann frazier <dann.frazier@canonical.com> wrote:
> > >
> > > On Thu, Oct 31, 2019 at 12:55:10PM -0600, dann frazier wrote:
> > > > On Thu, Oct 31, 2019 at 6:16 AM Leif Lindholm <leif.lindholm@linaro.org> wrote:
> > > > >
> > > > > On Thu, Oct 31, 2019 at 11:07:52AM +0100, Laszlo Ersek wrote:
> > > > > > +Leif, comment at bottom
> > > > >
> > > > > Thanks Laszlo. +Dann, -kexec.
> > > > >
> > > > > > On 10/30/19 09:16, Prabhakar Kushwaha wrote:
> > > > > > >> So if you want to add these properties, you should add them there.
> > > > > > >>
> > > > > > >> Can you explain why doing this is necessary?
> > > > > > >
> > > > > > > I am trying to test kexec -p (kdump feature) on CentOS-release
> > > > > > > 7.7.1908 and Ubuntu-18.04 distributions.
> > > > > > >
> > > > > > >  "kexec -p" command show error on Ubuntu. While no error on CentOS
> > > > > > >
> > > > > > > CentOS:
> > > > > > > $ kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
> > > > > > > -r`.img --reuse-cmdline
> > > > > > > $    ==> No error
> > > > > > >
> > > > > > > Ubuntu
> > > > > > > $ kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initrd.img-`uname
> > > > > > > -r` --reuse-cmdline
> > > > > > > $ kexec: elfcorehdr doesn't fit cells-size.
> > > > > > > $ kexec: setup_2nd_dtb failed.
> > > > > > > $ kexec: load failed.
> > > > > > > $ Cannot load /boot/vmlinuz-5.4.0-rc4+
> > > > > > >
> > > > > > > Note: Both CentOS and Ubuntu has Linux-5.4-rc4 tag.
> > > > > > >
> > > > > > > When i debugged further reason for Ubuntu error is due to
> > > > > > > address-cells and size-cells as "1"
> > > > > > > log from kexec tool :-
> > > > > > > load_crashdump_segments: elfcorehdr 0x7f7cbfc000-0x7f7cbff7ff
> > > > > > > read_1st_dtb: found name =dtb_sys  /sys/firmware/fdt
> > > > > > > get_cells_size: #address-cells:1 #size-cells:1
> > > > > > >
> > > > > > > On CentOS both values are "2".
> > > > > > > log from kexec tool :-
> > > > > > > load_crashdump_segments: elfcorehdr 0xbf98bf0000-0xbf98bf33ff
> > > > > > > read_1st_dtb: found nmae=dtb_sys /sys/firmware/fdt
> > > > > > > get_cells_size: #address-cells:2 #size-cells:2
> > > > > > >
> > > > > > > Note: Kexec tool read values from /sys/firmware/fdt.
> > > > > > >
> > > > > > > I am trying to figure out why 2 distributions showing different values.
> > > > > >
> > > > > > http://git.savannah.gnu.org/cgit/grub.git/commit/?id=347210a5d5ce655b95315f320faa515afb723c11
> > > > > >
> > > > > > Ubuntu probably ships a grub version that lacks this commit.
> > > > >
> > > > > Yes, it came after the 18.04 release.
> > > > > Dann: given that 18.04 is LTS, would it be reasonable to cherry-pick
> > > > > this grub patch? I would consider the behaviour without it to be a
> > > > > bug.
> > > >
> > > > Leif,
> > > >
> > > >   Likely - I'll run some tests and get back to you...
> > >
> > > Can you help me understand the scenario in which the above patch is
> > > required? I tested an 18.04 VM w/ AAVMF (ACPI-mode), and kexec -p
> > > worked fine. I also verified that 18.04 does not carry the above patch.
> > >
> >
> > This issue is only visible when crashkernel region reserved beyond 4GB
> > by kernel.
> > I reproduced this issue by providing "crashkernel=2G" in bootargs.
>
> Prabhakar,
>
> Thanks. I was able to reproduce w/ crashkernel=1G@4G.
>
> In order to get this addressed in 18.04 we'll need a LP bug to track
> it - would you mind filing one at
> https://bugs.launchpad.net/ubuntu/+source/grub2 and subscribing me
> (lpid dannf) to it?
>

I raised https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1851190
for the same.

I did not find your name in "subscribing someone else" option. So I
request you to subscribe to your name.

Thanks
--pk