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.
On Sunday, December 2, 2018 at 6:54:43 AM UTC-8, Charles Steinkuehler wrote:
> 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.
>
> On 12/1/2018 11:56 PM, Ken Shirriff wrote:
> > 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 <https://git.ti.com/apps/tida01555/> project does just what I
> > (and presumably Gaurav) want, if I can get it to work.)
> >
> > Ken
> >
> > On Tuesday, October 9, 2018 at 6:55:28 PM UTC-7, RobertCNelson wrote:
> >>
> >> On Tue, Oct 9, 2018 at 5:58 PM GS <[email protected] <javascript:>>
> >> wrote:
> >>>
> >>> 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.
> >>
> >> 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,
> >>
> >> --
> >> Robert Nelson
> >> https://rcn-ee.com/
> >>
> >
>
>
> --
> 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/4a8827bd-dd28-4ecb-899b-d7f70903bee5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
