Glad you got it working! It seems like the beginning and end of the memory region are "special cases", so I usually reserve memory at the middle of the available range. As long as the reserved memory region starts and ends on page boundaries it won'pretty much t matter at all from a performance standpoint what the absolute address is.
On 12/2/2018 2:27 PM, Ken Shirriff wrote: > 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 >> cha...@steinkuehler.net <javascript:> >> > -- Charles Steinkuehler char...@steinkuehler.net -- 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/4f37bc1b-7918-2f0f-30f3-f68f4a2caa81%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
