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

[mark.rutland@arm.com (Mark Rutland)]

On Wed, Feb 08, 2017 at 04:43:04PM +0900, AKASHI, Takahiro wrote:
> On Tue, Feb 07, 2017 at 07:55:59PM +0000, Mark Rutland wrote:

> > (a) The userspace kexec-tools kdump code should take /#address-cells and
> >     /#size-cells into account when inserting the linux,elfcorehdr and
> >     linux,usable-memory-range properties. There can be DTs for 64 bit
> >     platforms where these are not 2.
> >     
> >     Takahiro-san, from looking at your kexec-tools repo, this is not
> >     currently the case. Could you address that?
> 
> Yup, I will, but if this is the case,
> we might need to think about another case where /#address-cells and /#size-cells
> are <1> but the range of crash dump kernel can be still 64-bit wide since
> the system memory information comes from ACPI table (not DT).

That should only happen on an ACPI system for which the vendor has also
provided a DT in the FW, and also chose to use /#address-cells = <1>
and/or /#size-cells = <1>. We could log a warning and give up in this
case.

In the Purely DT case it shouldn't be a problem, since that would imply
all memory is within 32 bits.

... the other option Ard suggested was that we make these properties
always take 64-bit address and size values, and don't use #address-cells
or #size-cells at all when parsing them. I wasn't keen on this since the
properties would be reg-like, but potentially different in size. Maybe
that is the better option, though. :/

> Therefore, the properties in this case should look like:
> / {
>     #address-cells = <1>;
>     #size-cells = <1>;
>     chosen {
>          ...
>          linux,usable-memory-range {
>              #address-cells = <2>;
>              #size-cells = <2>; may be omitted if possible
>              reg = < ... >;
>          }
>          linux,elfcorehdr {
>              #address-cells = <2>;
>              #size-cells = <2>; may be omitted if possible
>              reg = < ... >;
>          }
>          ...
>     }
> }
> 
> Is this what you meant?
> (Obviously, I will have to modify the kernel patches as well.)

No; I was assuming we'd only change the userspace code, not the binding
or the kernel parsing.

If nothing else, the root /#address-cells and /#size-cells would have to
be widened to handle the translation, so the above alone is not
sufficient.

Thanks,
Mark.