Hi Rob,
Reviving an old thread -- "rock" and "hard place" come to mind.
On Fri, Aug 19, 2016 at 08:26:41AM -0500, Rob Herring wrote:
> On Tue, Aug 09, 2016 at 10:57:47AM +0900, AKASHI Takahiro wrote:
> > From: James Morse <james.morse at arm.com>
> > +linux,usable-memory-range
> > +-------------------------
> > +
> > +This property (currently used only on arm64) holds the memory range,
> > +the base address and the size, which can be used as system ram on
> > +the *current* kernel. Note that, if this property is present, any memory
> > +regions under "memory" nodes in DT blob or ones marked as "conventional
> > +memory" in EFI memory map should be ignored.
> > +e.g.
> > +
> > +/ {
> > + chosen {
> > + linux,usable-memory-range = <0x9 0xf0000000 0x0 0x10000000>;
> > + };
> > +};
>
> I've read the discussion on this. I think you should use the existing
> linux,usable-memory property in the memory nodes. If UEFI systems don't
> have memory nodes, then you can find an UEFI way to describe this. DT is
> not the dumping ground for what doesn't fit in UEFI. How do x86 systems
> work?
Having looked at the proposals, I'm personally much keener on the approach
above (modulo naming and wording) than trying to bolt memory nodes onto a UEFI
system, or using reserved-memory to describe the inverse of the allowable
range.
I completely agree that we want one solution for DT-only and DT+UEFI.
While those approaches reuse existing infrastructure, they end up creating more
work, and I believe that they create more scope for painful problems. As kdump
is already a constrained case, I think that it's reasonable to have a
linux-specific property as above.
I also think we need to figure out how we expect this to work for the
kexec_file_load case, as that has a criticial impact on the above (e.g. what's
preferable out of cmdline options vs dt properties).
Can we try to sync at connect to discuss this?
Thanks,
Mark.
