On Fri, Oct 24, 2014 at 1:27 PM, Mark Rutland <mark.rutland at 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 at 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.
