Thanks for the replies, Charles. I figured out the problem. The dts <https://git.ti.com/apps/tida01555/blobs/master/dts/am335x-boneblack-pruadc.dts> I was using tried to reserve 256K at 0x9ffc0000. However, system RAM ends at 9fdfffff, which is earlier, so the reservation never showed up in the RAM numbers. (I'm unclear what's in that last 2 meg of RAM, and if it's okay to reserve part of it.)
I changed the range to start at 0x90000000 and now it shows up as a change when running "free". As well, the reserved memory hole is nicely visible in /proc/iomem: # grep RAM /proc/iomem 80000000-8fffffff : System RAM 90040000-9fdfffff : System RAM So I think everything is working with memory reservation now. Ken On Sunday, December 2, 2018 at 10:59:09 AM UTC-8, Charles Steinkuehler wrote: > > On 12/2/2018 12:22 PM, Ken Shirriff wrote: > > > > I also tried increasing the amount of reserved memory from 256K to 4M > and > > didn't see any change. I increased the size way beyond physical memory, > and > > didn't get any errors. So I suspect it is being ignored. Do I need a > kernel > > flag or something to reserve memory? > > No. > > > So, is there any way to verify that the memory is getting reserved? (I > > suspect nothing is reserved, so I would be writing to random memory if I > > tried to use the buffer.) > > Other than noticing the reduced amount of free ram, I don't think the > reserved memory regions show up until/unless they are requested by a > kernel driver. > > > Ken > > > > [1]: I got the reserved-memory to load two ways. I figured out that I > need > > to use target-path = "/"; in the dtc file so it gets loaded under the > root > > node. Next, in case reserved-memory didn't work as an overlay, I edited > > am335x-bone-common.dtsi under /opt/source/dtb-4.14-ti. > > There's likely an issue in your device tree. Make sure your entries > are showing up under /sys: > > $ find /sys/firmware/devicetree/base/reserved-memory/ -type f > /sys/firmware/devicetree/base/reserved-memory/ranges > /sys/firmware/devicetree/base/reserved-memory/#address-cells > /sys/firmware/devicetree/base/reserved-memory/#size-cells > /sys/firmware/devicetree/base/reserved-memory/NewTek_Reserved/reg > /sys/firmware/devicetree/base/reserved-memory/NewTek_Reserved/name > /sys/firmware/devicetree/base/reserved-memory/NewTek_Video/reg > /sys/firmware/devicetree/base/reserved-memory/NewTek_Video/name > /sys/firmware/devicetree/base/reserved-memory/name > > ~$ hd /sys/firmware/devicetree/base/reserved-memory/NewTek_Reserved/reg > 00000000 18 00 00 00 08 00 00 00 |........| > 00000008 > > NOTES: > * This is from a Zynq (not a BBB), but it should match if you're using > a recent 4.x kernel. > > * The names should match whatever you have in device-tree > > * The values in the "reg" file are in wacky device-tree byte order, > the hex dump above corresponds to a "reg = <0x18000000 0x08000000>;" > entry in the device-tree. > > * You don't need the status="okay"; entries in your node > > * Don't use overlays and put the reserved-memory node at the root of > the device-tree (I think you already figured this out). > > * Double (and then triple) check for typos! > > * Note that just because something shows up in the "live" device tree > (under /sys/firmware/devicetree/base/) doesn't mean the kernel did > anything with it. If you misspell "reserved-memory" for instance, > your node will show up in the device tree, but you won't have actually > reserved any memory. The kernel doesn't complain about unknown or > unexpected elements in the device-tree. > > -- > Charles Steinkuehler > [email protected] <javascript:> > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/ec52447b-7089-4692-b0d3-1f33ffab41cf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
