How to use "reserved-memory" in device tree to reserve DDR memory?

I am trying to figure out how to reserve memory in device tree. (this is based on an example by TI: Dts and compile instructions section 3.1.2.4)
Here is is my dts file:

/dts-v1/;

/ {
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;

pruadc_reserved: pruadc_reserved@0x9ffc0000 {
reg = <0x9ffc0000 0x00010000>;
no-map;
status = “okay”;
};
};
};

However, when I compile I get the following warnings:

src/arm/MEM.dtbo: Warning (ranges_format): /reserved-memory has empty “ranges” property but its #address-cells (1) differs from / (2)
src/arm/MEM.dtbo: Warning (avoid_default_addr_size): Relying on default #address-cells value for /reserved-memory
src/arm/MEM.dtbo: Warning (avoid_default_addr_size): Relying on default #size-cells value for /reserved-memory

Other combinations of address-cells/size-cells give reg format warnings.

Any suggestions would be much appreciated.

Thanks
Gaurav

Looks fine:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/da850-lcdk.dts?h=v4.19-rc7#n29

dtc just being over-jealous on warnings, and we haven't fixed all the
in-kernel nodes up to the proper syntax..

Regards,

Thanks Robert, much appreciated!

Robert/other device tree experts,
Apparently using u-boot to load the compiled dtbo bricks the beaglebone. The device does not complete boot up and all 4 led’s remain on (ethernet/usb is non responsive too). I am wondering if U-boot is the right way to do it?How should I compile the original Dts and add to boot up? TI’s compilation instructions are:

3.1.2.4 Compile the Device Tree to Configure Pin Muxing
A device tree file is provided in the dts folder of the TIDA-01555 git repository. Copy the device tree file (am335x-boneblack-pruadc.dts) into the dts folder of the RT Linux Kernel source of the Processor SDK. Find the dts folder at ${RT Linux Processor SDK Install Path}/board-support/linux-xx.xx.xx/ arch/arm/boot/dts/.
After the am335x-boneblack-pruadc.dts file is placed in the SDK’s dts folder, compile the device tree. From the ${RT Linux Processor SDK Install Path}/board-support/linux-xx.xx.xx/ directory, run the following bolded commands. Make sure to add the cross-compile toolchain to the PATH variable first. For more information on the following commands, see the Processor SDK Linux Kernel Users Guide.
• # make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- distclean
• # make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- tisdk_am335x-evm-rt_defconfig
• # make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- am335x-boneblack-pruadc.dtb

How would I accomplish the same on Beaglebone?

Thanks
Gaurav

For starters, grab a usb-serial adapter and plug it into j1 to see
what's really happening..

Regards,

Thanks for the suggestion, Robert.
I have attached the complete output. The relevant section is pasted here:

uboot_overlays: loading /lib/firmware/MEM.dtbo …
418 bytes read in 94 ms (3.9 KiB/s)
failed on fdt_overlay_apply(): FDT_ERR_BADOVERLAY

Not exactly sure what it means.

Thanks
Gaurav

BootFailSerialOutput_10092018 (4.94 KB)

Thanks for the suggestion, Robert.
I have attached the complete output. The relevant section is pasted here:

uboot_overlays: loading /lib/firmware/MEM.dtbo …
418 bytes read in 94 ms (3.9 KiB/s)
failed on fdt_overlay_apply(): FDT_ERR_BADOVERLAY

Not exactly sure what it means.

Thanks
Gaurav

BootFailSerialOutput_10092018 (4.94 KB)

it means, error, bad overlay...

Which means it didn't do the overlay syntax..

We have lots of examples here:

https://github.com/beagleboard/bb.org-overlays/tree/master/src/arm

what's your actual overlay dts file look like?

You need:

/plugin/;

fragment@0 {'s

target = <&xyz>; or target-path="/";

and

__overlay__ {

finally built with "-@"

Regards,

I’m trying to do exactly the same thing as Gaurav and I found this thread.

First, I ran into the same problem as Gaurav that the beaglebone bricked on boot with FDT_ERR_BADOVERLAY. The problem was I put the “reserved-memory” section in my overlay dts, which the overlay system doesn’t like.

I moved that to a fragment, and now it boots and there’s a reserved-memory section in /sys/firmware, but looking at dmesg and /proc, I don’t think it actually reserved any memory.

fragment@6 {
target = <&ocp>;
overlay {
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;

pruadc_reserved: pruadc_reserved@0x9ffc0000 {
reg = <0x9ffc0000 0x00040000>;
no-map;
status = “okay”;
};
};
};
};

So, my question is: how do I get this fragment to actually reserve a chunk of memory? I just guessed at the target “ocp”, so that may be wrong.

(My underlying goal is to allocate a chunk of RAM to share between the ARM and the PRU; the built-in shared RAM is a bit too small. It seems that the TIDA01555 project does just what I (and presumably Gaurav) want, if I can get it to work.)

Ken

The reserved memory ranges don't really show up in the boot logs.
Check the "Memory:" line early in the kernel boot messages if you've
got a serial console, or you can run "free" to see the amount of
system memory available. It should be reduced by the amount you reserved.

I got the reserved-memory info to load into the device tree [1]; it shows up in /sys/firmware/devicetree/base/reserved-memory. However, I am doubtful that the kernel is actually reserving memory since I get the same values in dmesg or free, with or without reserved-memory:

[ 0.000000] Memory: 440720K/522240K available (13312K kernel code, 1169K rwdata, 4364K rodata, 1024K init, 361K bss, 32368K reserved, 49152K cma-reserved, 0K highmem)

total used free shared buff/cache available
Mem: 495324 59848 354340 5052 81136 419296
Swap: 0 0 0

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?

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.)

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.

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.

Thanks for the replies, Charles. I figured out the problem. The 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

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.

Hello.
I compiled the following code as the device tree source.

/dts-v1/;
/plugin/;
/* Reserve 256kB DDR memory for the ping/pong buffers */
/ {
fragment@0 {
target = <&ocp>;
overlay {
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;

pruadc_reserved: pruadc_reserved@0x90000000 {
reg = <0x90000000 0x00040000>;
no-map;
status = “okay”;
};
};
};
};
};

But after booting, there is no trace of the reserved memory in the /proc/iomem file (there is no gap in “System RAM”). I also tested a large number of different sources, but none of them came up with a result.
Can you share here the device tree source that you have used?

Hello.
I compiled the following code as the device tree source.

/dts-v1/;
/plugin/;

/* Reserve 256kB DDR memory for the ping/pong buffers */
/ {
fragment@0 {
target = <&ocp>;
overlay {
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;

pruadc_reserved: pruadc_reserved@0x90000000 {
reg = <0x90000000 0x00040000>;
no-map;
status = “okay”;
};
};
};
};
};

But after booting, there is no trace of the reserved memory in the /proc/iomem file (there is not any gap in “System RAM”). I also tested a large number of other sources, but none of them came up with a result.
Can you share the source of the device that you have used?

Hello.
I compiled the following code as the device tree source.

/dts-v1/;
/plugin/;
/* Reserve 256kB DDR memory for the ping/pong buffers */
/ {
fragment@0 {
target = <&ocp>;

swap ocp for this:

target-path = "/";

__overlay__ {
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;

pruadc_reserved: pruadc_reserved@0x90000000 {
reg = <0x90000000 0x00040000>;
no-map;
status = "okay";
};
};
};
};
};

But after booting, there is no trace of the reserved memory in the /proc/iomem file (there is no gap in "System RAM"). I also tested a large number of different sources, but none of them came up with a result.
Can you share here the device tree source that you have used?

Regards,

I did what you said, but no result. Does memory reserving need any kernel driver or configurations?

OK, I’m sorry. I’d made a mistake. Your suggestion solved the problem. Now I have a gap in System RAM.
This is the device tree source that i have used and is OK:

/dts-v1/;
/plugin/;
/* Reserve 256kB DDR memory for the ping/pong buffers */
/ {
fragment@0 {
target-path = “/”;
overlay {
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;

pruadc_reserved: pruadc_reserved@0x90010000 {
reg = <0x90010000 0x00040000>;
no-map;
status = “okay”;
};
};
};
};
};

Thank you very much.

OK. I had made a mistake. Your suggestion solved the problem. Now I have a gap in System RAM.
This is the device tree source that i have used and is OK:

/dts-v1/;
/plugin/;
/* Reserve 256kB DDR memory for the ping/pong buffers */
/ {
fragment@0 {
target-path = “/”;
overlay {
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;

pruadc_reserved: pruadc_reserved@0x90010000 {
reg = <0x90010000 0x00040000>;
no-map;
status = “okay”;
};
};
};
};
};

Thank you very much.