Re: [PATCH] efi/libstub/arm*: Set default address and size cells values for an empty dtb

[Mark Rutland <mark.rutland@arm.com>]

On Tue, Feb 07, 2017 at 01:24:53PM -0600, Timur Tabi wrote:
> On Tue, Feb 7, 2017 at 12:15 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> >
> >> In cases where a device tree is not provided (ie ACPI based system), an
> >> empty fdt is generated by efistub.  Sets the address and size cell values
> >> in a generated fdt to support 64 bit addressing.
> >>
> >> This enables kexec/kdump on Qualcomm Technologies QDF24XX platforms as those
> >> utilities will read the address/size values from the fdt, and such values
> >> may exceed the range provided by the 32 bit default.
> >
> > The description here doesn't state why this is a problem for ACPI.
> 
> The patch description could use some work.  It's a problem for ACPI
> because EFI-based systems call typically fdt_create_empty_tree(),
> which is where the problem lies.
> 
> The bug is that fdt_create_empty_tree() literally creates an empty
> tree.  By default if a node is missing #address-cells and #size-cells
> properties, then it's assume that both values are equal to 1, i.e.
> 32-bit addresses.

Sure, I understand this.

> When update_fdt() in drivers/firmware/efi/libstub/fdt.c creates an
> empty tree, it then proceeds to inject 64-bit addresses into that
> tree.  When kdump tries to process the address properties, it reads
> the wrong values because it thinks they are all 32-bit addresses.

This is *not* true.

The EFI stub only injects values which are always defined to be 64 bits
in width.

In Takahiro-san's arm64/kdump branch, the userspace kdump code doesn't
parse properties out of the DT.

In fact, it simply assumes that the kdump-specific properties always
have 64 bits of address, and 64-bits of size, and inserts these
sized accordingly.

The kdump kernel, however, tries to use /#address-cells and
/#size-cells. That is where I assume things go wrong.

There is no upstream kdump code for arm64.

Thanks,
Mark.