* How /sys/firmware/fdt getting created @ 2019-10-29 14:32 prabhakar.pkin 2019-10-30 7:12 ` [edk2-devel] " Ard Biesheuvel 0 siblings, 1 reply; 15+ messages in thread From: prabhakar.pkin @ 2019-10-29 14:32 UTC (permalink / raw) To: devel 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) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [edk2-devel] How /sys/firmware/fdt getting created 2019-10-29 14:32 How /sys/firmware/fdt getting created prabhakar.pkin @ 2019-10-30 7:12 ` Ard Biesheuvel 2019-10-30 7:36 ` Prabhakar Kushwaha 0 siblings, 1 reply; 15+ messages in thread From: Ard Biesheuvel @ 2019-10-30 7:12 UTC (permalink / raw) To: Prabhakar Kushwaha; +Cc: edk2-devel-groups-io 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) > > > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [edk2-devel] How /sys/firmware/fdt getting created 2019-10-30 7:12 ` [edk2-devel] " Ard Biesheuvel @ 2019-10-30 7:36 ` Prabhakar Kushwaha 2019-10-30 7:44 ` Ard Biesheuvel 0 siblings, 1 reply; 15+ messages in thread From: Prabhakar Kushwaha @ 2019-10-30 7:36 UTC (permalink / raw) To: Ard Biesheuvel; +Cc: edk2-devel-groups-io 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) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [edk2-devel] How /sys/firmware/fdt getting created 2019-10-30 7:36 ` Prabhakar Kushwaha @ 2019-10-30 7:44 ` Ard Biesheuvel 2019-10-30 8:16 ` Prabhakar Kushwaha 0 siblings, 1 reply; 15+ messages in thread From: Ard Biesheuvel @ 2019-10-30 7:44 UTC (permalink / raw) To: Prabhakar Kushwaha; +Cc: edk2-devel-groups-io 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? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [edk2-devel] How /sys/firmware/fdt getting created 2019-10-30 7:44 ` Ard Biesheuvel @ 2019-10-30 8:16 ` Prabhakar Kushwaha 2019-10-31 10:07 ` Laszlo Ersek 2019-10-31 20:29 ` Bhupesh Sharma 0 siblings, 2 replies; 15+ messages in thread From: Prabhakar Kushwaha @ 2019-10-30 8:16 UTC (permalink / raw) To: Ard Biesheuvel; +Cc: edk2-devel-groups-io, naresh.bhat, kexec 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [edk2-devel] How /sys/firmware/fdt getting created 2019-10-30 8:16 ` Prabhakar Kushwaha @ 2019-10-31 10:07 ` Laszlo Ersek 2019-10-31 12:16 ` Leif Lindholm 2019-10-31 20:29 ` Bhupesh Sharma 1 sibling, 1 reply; 15+ messages in thread From: Laszlo Ersek @ 2019-10-31 10:07 UTC (permalink / raw) To: devel, prabhakar.pkin, Ard Biesheuvel; +Cc: naresh.bhat, kexec, Leif Lindholm +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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [edk2-devel] How /sys/firmware/fdt getting created 2019-10-31 10:07 ` Laszlo Ersek @ 2019-10-31 12:16 ` Leif Lindholm 2019-10-31 18:55 ` dann frazier [not found] ` <15D2D0302F8A1888.21389@groups.io> 0 siblings, 2 replies; 15+ messages in thread From: Leif Lindholm @ 2019-10-31 12:16 UTC (permalink / raw) To: Laszlo Ersek Cc: devel, prabhakar.pkin, Ard Biesheuvel, naresh.bhat, dann.frazier 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 > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [edk2-devel] How /sys/firmware/fdt getting created 2019-10-31 12:16 ` Leif Lindholm @ 2019-10-31 18:55 ` dann frazier [not found] ` <15D2D0302F8A1888.21389@groups.io> 1 sibling, 0 replies; 15+ messages in thread From: dann frazier @ 2019-10-31 18:55 UTC (permalink / raw) To: Leif Lindholm Cc: Laszlo Ersek, devel, prabhakar.pkin, Ard Biesheuvel, naresh.bhat 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 > > ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <15D2D0302F8A1888.21389@groups.io>]
* Re: [edk2-devel] How /sys/firmware/fdt getting created [not found] ` <15D2D0302F8A1888.21389@groups.io> @ 2019-10-31 20:34 ` dann frazier 2019-11-01 4:47 ` Prabhakar Kushwaha 0 siblings, 1 reply; 15+ messages in thread From: dann frazier @ 2019-10-31 20:34 UTC (permalink / raw) To: Leif Lindholm Cc: Laszlo Ersek, devel, prabhakar.pkin, Ard Biesheuvel, naresh.bhat 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 > > > > > > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [edk2-devel] How /sys/firmware/fdt getting created 2019-10-31 20:34 ` dann frazier @ 2019-11-01 4:47 ` Prabhakar Kushwaha 2019-11-01 16:25 ` dann frazier 0 siblings, 1 reply; 15+ messages in thread From: Prabhakar Kushwaha @ 2019-11-01 4:47 UTC (permalink / raw) To: dann frazier Cc: Leif Lindholm, Laszlo Ersek, edk2-devel-groups-io, Ard Biesheuvel, Naresh Bhat 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [edk2-devel] How /sys/firmware/fdt getting created 2019-11-01 4:47 ` Prabhakar Kushwaha @ 2019-11-01 16:25 ` dann frazier 2019-11-04 4:11 ` Prabhakar Kushwaha 0 siblings, 1 reply; 15+ messages in thread From: dann frazier @ 2019-11-01 16:25 UTC (permalink / raw) To: Prabhakar Kushwaha Cc: Leif Lindholm, Laszlo Ersek, edk2-devel-groups-io, Ard Biesheuvel, Naresh Bhat 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [edk2-devel] How /sys/firmware/fdt getting created 2019-11-01 16:25 ` dann frazier @ 2019-11-04 4:11 ` Prabhakar Kushwaha 0 siblings, 0 replies; 15+ messages in thread From: Prabhakar Kushwaha @ 2019-11-04 4:11 UTC (permalink / raw) To: dann frazier Cc: Leif Lindholm, Laszlo Ersek, edk2-devel-groups-io, Ard Biesheuvel, Naresh Bhat, Ganapatrao Prabhakerrao Kulkarni 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [edk2-devel] How /sys/firmware/fdt getting created 2019-10-30 8:16 ` Prabhakar Kushwaha 2019-10-31 10:07 ` Laszlo Ersek @ 2019-10-31 20:29 ` Bhupesh Sharma 2019-11-01 4:51 ` Prabhakar Kushwaha 1 sibling, 1 reply; 15+ messages in thread From: Bhupesh Sharma @ 2019-10-31 20:29 UTC (permalink / raw) To: Prabhakar Kushwaha Cc: Ard Biesheuvel, Naresh Bhat, edk2-devel-groups-io, kexec mailing list 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [edk2-devel] How /sys/firmware/fdt getting created 2019-10-31 20:29 ` Bhupesh Sharma @ 2019-11-01 4:51 ` Prabhakar Kushwaha 2019-11-01 5:46 ` Bhupesh Sharma 0 siblings, 1 reply; 15+ messages in thread From: Prabhakar Kushwaha @ 2019-11-01 4:51 UTC (permalink / raw) To: Bhupesh Sharma Cc: Ard Biesheuvel, Naresh Bhat, edk2-devel-groups-io, kexec mailing list 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [edk2-devel] How /sys/firmware/fdt getting created 2019-11-01 4:51 ` Prabhakar Kushwaha @ 2019-11-01 5:46 ` Bhupesh Sharma 0 siblings, 0 replies; 15+ messages in thread From: Bhupesh Sharma @ 2019-11-01 5:46 UTC (permalink / raw) To: Prabhakar Kushwaha Cc: Ard Biesheuvel, Naresh Bhat, edk2-devel-groups-io, kexec mailing list 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2019-11-04 4:11 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-10-29 14:32 How /sys/firmware/fdt getting created prabhakar.pkin 2019-10-30 7:12 ` [edk2-devel] " Ard Biesheuvel 2019-10-30 7:36 ` Prabhakar Kushwaha 2019-10-30 7:44 ` Ard Biesheuvel 2019-10-30 8:16 ` Prabhakar Kushwaha 2019-10-31 10:07 ` Laszlo Ersek 2019-10-31 12:16 ` Leif Lindholm 2019-10-31 18:55 ` dann frazier [not found] ` <15D2D0302F8A1888.21389@groups.io> 2019-10-31 20:34 ` dann frazier 2019-11-01 4:47 ` Prabhakar Kushwaha 2019-11-01 16:25 ` dann frazier 2019-11-04 4:11 ` Prabhakar Kushwaha 2019-10-31 20:29 ` Bhupesh Sharma 2019-11-01 4:51 ` Prabhakar Kushwaha 2019-11-01 5:46 ` Bhupesh Sharma
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox