| Message ID | 411296ab915959b862923d827e730a1db2ff9b4e.1414099246.git.geoff@infradead.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 <geoff@infradead.org> > --- > 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 > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >
On Fri, Oct 24, 2014 at 11:51 AM, Mark Rutland <mark.rutland@arm.com> wrote: > 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? Yes, I suggested the same thing to Geoff in a separate thread. Here's what I wrote: >> Geoff Levand wrote: >>> I did some work on this and I think we just need to convert all the >>> arm64 dts from /memreserve/ to reserved-memory nodes and update the >>> arm64 booting.txt to specify using reserved-memory. I'll prepare a >>> patch for it. >> >> I don't think that is going to be entirely sufficient. There will be >> platforms that don't get converted over, and this is a generic problem >> that covers all architectures using DT, not just aarch64. The solution >> probably needs to include exposing the /memreserve/ sections to >> userspace. I can see two ways to do this: >> >> 1) Create a new property in /sysfs with all the memreserve sctions >> 2) Live-modify the device tree to put the memreserve data into a node >> at boot time. >> >> Option 2 is probably the most generic solution, but it will require >> some care to make sure there aren't any overlaps if a reserved-memory >> node already exists. >> >> g. > > For reference, here is an old conversation about this exact thing. > Reading through it, the opinions I expressed then don't necessarily > match what I think now. I still don't think it is a good idea to > expose the physical address of the old .dtb blob, but I do agree that > the memreserve sections need to be exposed. > > https://lists.ozlabs.org/pipermail/linuxppc-dev/2010-July/083993.html > > g.
On Fri, Oct 24, 2014 at 11:59:38AM +0100, Grant Likely wrote: > On Fri, Oct 24, 2014 at 11:51 AM, Mark Rutland <mark.rutland@arm.com> wrote: > > 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? > > Yes, I suggested the same thing to Geoff in a separate thread. Here's > what I wrote: > > >> Geoff Levand wrote: > >>> I did some work on this and I think we just need to convert all the > >>> arm64 dts from /memreserve/ to reserved-memory nodes and update the > >>> arm64 booting.txt to specify using reserved-memory. I'll prepare a > >>> patch for it. > >> > >> I don't think that is going to be entirely sufficient. There will be > >> platforms that don't get converted over, and this is a generic problem > >> that covers all architectures using DT, not just aarch64. The solution > >> probably needs to include exposing the /memreserve/ sections to > >> userspace. I can see two ways to do this: > >> > >> 1) Create a new property in /sysfs with all the memreserve sctions > >> 2) Live-modify the device tree to put the memreserve data into a node > >> at boot time. > >> > >> Option 2 is probably the most generic solution, but it will require > >> some care to make sure there aren't any overlaps if a reserved-memory > >> node already exists. I would prefer the former currently. While I currently believe that modifying the tree is something we're going to have to do for stateful properties, it's not someting I want to have to do unless absolutely necessary. > >> > >> g. > > > > For reference, here is an old conversation about this exact thing. > > Reading through it, the opinions I expressed then don't necessarily > > match what I think now. I still don't think it is a good idea to > > expose the physical address of the old .dtb blob, but I do agree that > > the memreserve sections need to be exposed. > > > > https://lists.ozlabs.org/pipermail/linuxppc-dev/2010-July/083993.html Another option would be to expose the original DTB as a (read-only) binary file somewhere. That might interact poorly with live tree modification in future, however. Mark.
On Fri, Oct 24, 2014 at 1:27 PM, Mark Rutland <mark.rutland@arm.com> wrote: > On Fri, Oct 24, 2014 at 11:59:38AM +0100, Grant Likely wrote: >> On Fri, Oct 24, 2014 at 11:51 AM, Mark Rutland <mark.rutland@arm.com> wrote: >> > 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? >> >> Yes, I suggested the same thing to Geoff in a separate thread. Here's >> what I wrote: >> >> >> Geoff Levand wrote: >> >>> I did some work on this and I think we just need to convert all the >> >>> arm64 dts from /memreserve/ to reserved-memory nodes and update the >> >>> arm64 booting.txt to specify using reserved-memory. I'll prepare a >> >>> patch for it. >> >> >> >> I don't think that is going to be entirely sufficient. There will be >> >> platforms that don't get converted over, and this is a generic problem >> >> that covers all architectures using DT, not just aarch64. The solution >> >> probably needs to include exposing the /memreserve/ sections to >> >> userspace. I can see two ways to do this: >> >> >> >> 1) Create a new property in /sysfs with all the memreserve sctions >> >> 2) Live-modify the device tree to put the memreserve data into a node >> >> at boot time. >> >> >> >> Option 2 is probably the most generic solution, but it will require >> >> some care to make sure there aren't any overlaps if a reserved-memory >> >> node already exists. > > I would prefer the former currently. While I currently believe that > modifying the tree is something we're going to have to do for stateful > properties, it's not someting I want to have to do unless absolutely > necessary. We already have a file in debugfs that will expose the entire dtb to userspace, but I strongly discourage using that feature in production. Search for "DEBUG_FS" in fdt.c g.
Hi, On Fri, 2014-10-24 at 13:27 +0100, Mark Rutland wrote: > On Fri, Oct 24, 2014 at 11:59:38AM +0100, Grant Likely wrote: > > On Fri, Oct 24, 2014 at 11:51 AM, Mark Rutland <mark.rutland@arm.com> wrote: > > > 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? > > > > Yes, I suggested the same thing to Geoff in a separate thread. Here's > > what I wrote: > > > > >> Geoff Levand wrote: > > >>> I did some work on this and I think we just need to convert all the > > >>> arm64 dts from /memreserve/ to reserved-memory nodes and update the > > >>> arm64 booting.txt to specify using reserved-memory. I'll prepare a > > >>> patch for it. > > >> > > >> I don't think that is going to be entirely sufficient. There will be > > >> platforms that don't get converted over, and this is a generic problem > > >> that covers all architectures using DT, not just aarch64. The solution > > >> probably needs to include exposing the /memreserve/ sections to > > >> userspace. I can see two ways to do this: > > >> > > >> 1) Create a new property in /sysfs with all the memreserve sctions > > >> 2) Live-modify the device tree to put the memreserve data into a node > > >> at boot time. > > >> > > >> Option 2 is probably the most generic solution, but it will require > > >> some care to make sure there aren't any overlaps if a reserved-memory > > >> node already exists. > > I would prefer the former currently. While I currently believe that > modifying the tree is something we're going to have to do for stateful > properties, it's not someting I want to have to do unless absolutely > necessary. Current user space kexec utilities use /proc/device-tree and nothing else. The intension of the device tree is to describe the system sufficiently for a kernel to boot, so I think we should put the /memreserve/ info into /proc/device-tree. We could put the /memreserve/ entries in there directly, or convert to reserved-memory nodes. At the moment I like the idea to convert to reserved-memory nodes. > > > For reference, here is an old conversation about this exact thing. > > > Reading through it, the opinions I expressed then don't necessarily > > > match what I think now. I still don't think it is a good idea to > > > expose the physical address of the old .dtb blob, but I do agree that > > > the memreserve sections need to be exposed. > > > > > > https://lists.ozlabs.org/pipermail/linuxppc-dev/2010-July/083993.html > > Another option would be to expose the original DTB as a (read-only) > binary file somewhere. That might interact poorly with live tree > modification in future, however. I don't like the idea of having two interfaces to get essentially the same info. I think it will be a maintenance problem over time. -Geoff
On Fri, Oct 31, 2014 at 11:44:52PM +0000, Geoff Levand wrote: > Hi, > > On Fri, 2014-10-24 at 13:27 +0100, Mark Rutland wrote: > > On Fri, Oct 24, 2014 at 11:59:38AM +0100, Grant Likely wrote: > > > On Fri, Oct 24, 2014 at 11:51 AM, Mark Rutland <mark.rutland@arm.com> wrote: > > > > 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? > > > > > > Yes, I suggested the same thing to Geoff in a separate thread. Here's > > > what I wrote: > > > > > > >> Geoff Levand wrote: > > > >>> I did some work on this and I think we just need to convert all the > > > >>> arm64 dts from /memreserve/ to reserved-memory nodes and update the > > > >>> arm64 booting.txt to specify using reserved-memory. I'll prepare a > > > >>> patch for it. > > > >> > > > >> I don't think that is going to be entirely sufficient. There will be > > > >> platforms that don't get converted over, and this is a generic problem > > > >> that covers all architectures using DT, not just aarch64. The solution > > > >> probably needs to include exposing the /memreserve/ sections to > > > >> userspace. I can see two ways to do this: > > > >> > > > >> 1) Create a new property in /sysfs with all the memreserve sctions > > > >> 2) Live-modify the device tree to put the memreserve data into a node > > > >> at boot time. > > > >> > > > >> Option 2 is probably the most generic solution, but it will require > > > >> some care to make sure there aren't any overlaps if a reserved-memory > > > >> node already exists. > > > > I would prefer the former currently. While I currently believe that > > modifying the tree is something we're going to have to do for stateful > > properties, it's not someting I want to have to do unless absolutely > > necessary. > > Current user space kexec utilities use /proc/device-tree and nothing > else. The intension of the device tree is to describe the system > sufficiently for a kernel to boot, so I think we should put the > /memreserve/ info into /proc/device-tree. I don't follow. The intention of device tree generically has precisely nothing to do with the Linux-specific filesystem hierarchy for exposing device tree to userspace. The memreserve entries aren't the same as other elements in /proc/device-tree. They're a flat table pointed to by the header rather than a hierarchy of nodes and properties. There's no way to expose that difference under /proc/device-tree, so exposing that as a parallel hierarchy makes the most sense to me. > We could put the /memreserve/ entries in there directly, or convert > to reserved-memory nodes. At the moment I like the idea to convert to > reserved-memory nodes. I think we need a parallel hierarchy to expose header information (though we likely only need the memreserve entries). I'm not keen on rewriting the device tree to work around a historical mistake. > > > > For reference, here is an old conversation about this exact thing. > > > > Reading through it, the opinions I expressed then don't necessarily > > > > match what I think now. I still don't think it is a good idea to > > > > expose the physical address of the old .dtb blob, but I do agree that > > > > the memreserve sections need to be exposed. > > > > > > > > https://lists.ozlabs.org/pipermail/linuxppc-dev/2010-July/083993.html > > > > Another option would be to expose the original DTB as a (read-only) > > binary file somewhere. That might interact poorly with live tree > > modification in future, however. > > I don't like the idea of having two interfaces to get essentially the same > info. I think it will be a maintenance problem over time. Given Grant's comments, I'm perfectly happy to not expose the raw DTB for situations otehr than debugging. Thanks, Mark.
Adding Leif... On Fri, Oct 31, 2014 at 6:44 PM, Geoff Levand <geoff@infradead.org> wrote: > Hi, > > On Fri, 2014-10-24 at 13:27 +0100, Mark Rutland wrote: >> On Fri, Oct 24, 2014 at 11:59:38AM +0100, Grant Likely wrote: >> > On Fri, Oct 24, 2014 at 11:51 AM, Mark Rutland <mark.rutland@arm.com> wrote: >> > > 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? >> > >> > Yes, I suggested the same thing to Geoff in a separate thread. Here's >> > what I wrote: >> > >> > >> Geoff Levand wrote: >> > >>> I did some work on this and I think we just need to convert all the >> > >>> arm64 dts from /memreserve/ to reserved-memory nodes and update the >> > >>> arm64 booting.txt to specify using reserved-memory. I'll prepare a >> > >>> patch for it. >> > >> >> > >> I don't think that is going to be entirely sufficient. There will be >> > >> platforms that don't get converted over, and this is a generic problem >> > >> that covers all architectures using DT, not just aarch64. The solution >> > >> probably needs to include exposing the /memreserve/ sections to >> > >> userspace. I can see two ways to do this: >> > >> >> > >> 1) Create a new property in /sysfs with all the memreserve sctions >> > >> 2) Live-modify the device tree to put the memreserve data into a node >> > >> at boot time. >> > >> >> > >> Option 2 is probably the most generic solution, but it will require >> > >> some care to make sure there aren't any overlaps if a reserved-memory >> > >> node already exists. >> >> I would prefer the former currently. While I currently believe that >> modifying the tree is something we're going to have to do for stateful >> properties, it's not someting I want to have to do unless absolutely >> necessary. > > Current user space kexec utilities use /proc/device-tree and nothing > else. The intension of the device tree is to describe the system > sufficiently for a kernel to boot, so I think we should put the > /memreserve/ info into /proc/device-tree. > > We could put the /memreserve/ entries in there directly, or convert > to reserved-memory nodes. At the moment I like the idea to convert to > reserved-memory nodes. I'm just wondering does UEFI being used for the memory information have any impact here as the DT would not have valid memory nodes either? I'd assume reserved memory comes from UEFI (or both) in that case? Perhaps we need to expose memory layout independent of DT, UEFI or anything else. Rob > >> > > For reference, here is an old conversation about this exact thing. >> > > Reading through it, the opinions I expressed then don't necessarily >> > > match what I think now. I still don't think it is a good idea to >> > > expose the physical address of the old .dtb blob, but I do agree that >> > > the memreserve sections need to be exposed. >> > > >> > > https://lists.ozlabs.org/pipermail/linuxppc-dev/2010-July/083993.html >> >> Another option would be to expose the original DTB as a (read-only) >> binary file somewhere. That might interact poorly with live tree >> modification in future, however. > > I don't like the idea of having two interfaces to get essentially the same > info. I think it will be a maintenance problem over time. > > -Geoff > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Mon, Nov 03, 2014 at 10:26:02PM +0000, Rob Herring wrote: > Adding Leif... [...] > I'm just wondering does UEFI being used for the memory information > have any impact here as the DT would not have valid memory nodes > either? For UEFI, things should just work (TM). The dtb will be free of memory nodes (and memreserves), and the next kernel will discover the UEFI memory map via the linux,uefi-mmap-* properties as the first kernel did. We shouldn't need to pass any additional data in this case. > I'd assume reserved memory comes from UEFI (or both) in that > case? Yes. Any memory that should be reserved should be described as such in the UEFI memory map. One caveat is that reserved-memory nodes are preserved (because they can be referred to by phandle for CMA and such). There are few potential problems with this (we'll have to reconcile it with the UEFI memory map, prevent overlap when the kernel is relocated, etc). The reserved-memory nodes should only be used for CMA type carve outs rather than for protecting firmware and similar. > Perhaps we need to expose memory layout independent of DT, UEFI > or anything else. I can see that being useful for debugging, but I don't think that we require it. Thanks, Mark.
On Mon, Nov 3, 2014 at 10:26 PM, Rob Herring <robherring2@gmail.com> wrote: > On Fri, Oct 31, 2014 at 6:44 PM, Geoff Levand <geoff@infradead.org> wrote: >> On Fri, 2014-10-24 at 13:27 +0100, Mark Rutland wrote: >> Current user space kexec utilities use /proc/device-tree and nothing >> else. The intension of the device tree is to describe the system >> sufficiently for a kernel to boot, so I think we should put the >> /memreserve/ info into /proc/device-tree. >> >> We could put the /memreserve/ entries in there directly, or convert >> to reserved-memory nodes. At the moment I like the idea to convert to >> reserved-memory nodes. > > I'm just wondering does UEFI being used for the memory information > have any impact here as the DT would not have valid memory nodes > either? I'd assume reserved memory comes from UEFI (or both) in that > case? It should, but as always the answer is not simple. UEFI+DT, it may be that a CMA region is specified in /reserved-memory and we would want to respect that, even when getting memory information from UEFI. However, the /memreserve/ section shouldn't be an issue in this case. Anything firmware needs protected must be reflected in the UEFI memory map. g.
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>; + }; + }; + 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>;
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. 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 <geoff@infradead.org> --- arch/arm64/boot/dts/foundation-v8.dts | 13 +++++++++++-- arch/arm64/boot/dts/rtsm_ve-aemv8a.dts | 13 +++++++++++-- 2 files changed, 22 insertions(+), 4 deletions(-)