On Fri, Oct 24, 2014 at 12:10:58AM +0100, Geoff Levand wrote: > Device tree regions described by /memreserve/ entries are not available in > /proc/device-tree, and hence are not available to user space utilities that > use > /proc/device-tree. In order for these regions to be available, convert any > arm64 DTS files using /memreserve/ entries to use reserved-memory nodes.
The limitation here is in the kernel (and a partially in userspace), so modifying the dts files is a workaround rather than a fix. It's perfectly valid for people to remain using /memreserve/, so this isn't sufficient. There are also existing DTBs using /memreserve/ which we can't rely on being modified to use reserved-memory. I think we need to expose memreserves to userspace somehow, potentially along with other DTB header fields. Grant, ideas? Are other architectures not affected by this limitation? > This change is required for kexec re-boot to work properly when a user does > not > specify a second stage DTB via the kexec --dtb option. When the --dtb option > is > not specified kexec will prepare the second stage DTB using data from > /proc/device-tree. > > Signed-off-by: Geoff Levand <[email protected]> > --- > arch/arm64/boot/dts/foundation-v8.dts | 13 +++++++++++-- > arch/arm64/boot/dts/rtsm_ve-aemv8a.dts | 13 +++++++++++-- > 2 files changed, 22 insertions(+), 4 deletions(-) > > diff --git a/arch/arm64/boot/dts/foundation-v8.dts > b/arch/arm64/boot/dts/foundation-v8.dts > index 4a06090..2b76c2d 100644 > --- a/arch/arm64/boot/dts/foundation-v8.dts > +++ b/arch/arm64/boot/dts/foundation-v8.dts > @@ -6,8 +6,6 @@ > > /dts-v1/; > > -/memreserve/ 0x80000000 0x00010000; > - > / { > model = "Foundation-v8A"; > compatible = "arm,foundation-aarch64", "arm,vexpress"; > @@ -64,6 +62,17 @@ > <0x00000008 0x80000000 0 0x80000000>; > }; > > + reserved-memory { > + #address-cells = <2>; > + #size-cells = <2>; > + ranges; > + > + firmware-memory@0x80000000 { > + no-map; > + reg = <0x0 0x80000000 0x0 0x00010000>; > + }; > + }; > + For the spin-table code at present we currently permit cacheable mappings (that's part of the definition of /memreserve/), so it's not strictly necessary to have no-map. Until recently we accessed the cpu-release-addr through a cacheable mapping, and I don't know what other spin-table users (e.g. Xen) do. Linux should be able to handle this from now on, however. Thanks, Mark. > gic: interrupt-controller@2c001000 { > compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic"; > #interrupt-cells = <3>; > diff --git a/arch/arm64/boot/dts/rtsm_ve-aemv8a.dts > b/arch/arm64/boot/dts/rtsm_ve-aemv8a.dts > index 572005e..0f80807 100644 > --- a/arch/arm64/boot/dts/rtsm_ve-aemv8a.dts > +++ b/arch/arm64/boot/dts/rtsm_ve-aemv8a.dts > @@ -9,8 +9,6 @@ > > /dts-v1/; > > -/memreserve/ 0x80000000 0x00010000; > - > / { > model = "RTSM_VE_AEMv8A"; > compatible = "arm,rtsm_ve,aemv8a", "arm,vexpress"; > @@ -67,6 +65,17 @@ > <0x00000008 0x80000000 0 0x80000000>; > }; > > + reserved-memory { > + #address-cells = <2>; > + #size-cells = <2>; > + ranges; > + > + firmware-memory@0x80000000 { > + no-map; > + reg = <0x0 0x80000000 0x0 0x00010000>; > + }; > + }; > + > gic: interrupt-controller@2c001000 { > compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic"; > #interrupt-cells = <3>; > -- > 1.9.1 > > > > _______________________________________________ > linux-arm-kernel mailing list > [email protected] > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
