Is memory spec in dts shipped with BBB A6A Angstrom 3.8.13 wrong?

GoogleGroups
1

Really hard to categorize this.

I have BBB A6A running Angstrom distro:

Linux beaglebone 3.8.13 #1 SMP Wed Sep 4 09:09:32 CEST 2013 armv7l GNU/Linux

I’m working on using DDR to pass information back and forth to PRU, so looking at dts and memory assignment.

Either the dts (actually, dtb converted to dts using dtc) is wrong, or I don’t really understand it as well as I thought, or I can’t read hex any more…

The BBB ships with 512MB DDR3 RAM. That’s 0x2000_0000. However, the dts(b) in /boot/am335x-boneblack.dtb has this entry:

memory { device_type = “memory”; reg = <0x80000000 0x10000000l>; };

Am I missing something here, or is my bone setup to only use 256MB of the 512MB available?

2

Hi,

I don’t have access to my lab at the moment, so I can not try it myself, but can you rebuild a fdt and make a change in am335x-bone-common.dtsi?

Please also do:
cat /proc/meminfo before and after the change?

Just search for memory and replace it with:

	memory {
		device_type = "memory";
		reg = < 0x80000000 0x20000000 >;	/* 512MB RAM */
	};

Regards,

Robert

3

I don’t see a dtsi in /boot. I did “dtc -I dtb -O dts -o test.dts /boot/am335x-boneblack.dtb”. Looking at test.dts I still see memory {… reg = <0x80000000 0x10000000> };
However, “cat /proc/meminfo” returns a first line of “MemTotal: 510600 kB” which seems OK - I suppose. It looks like /boot/am335x-boneblack.dtb is not what is used at boot time, or is being overridden somehow?
BTW, “find / -name am335x-bone-common.dtsi -print” found no such file on my BBB.

4

Hi,

5

The original installed on flash (shipped in Jan/Feb this year):

I have BBB A6A running Angstrom distro:
Linux beaglebone 3.8.13 #1 SMP Wed Sep 4 09:09:32 CEST 2013 armv7l GNU/Linux

6

Any suggestions on where to look next to figure out what’s going on here? Seems that either something other than the device tree in file “/boot/am335x-boneblack.dts” is being read at boot, or there is something else that is overriding later on, or a boot parameter… or the memory specification in the reg property doesn’t work as I expect it to.

7

So... What issue are you having with it? Other then the dts file
showing 256Mb and linux showing 512Mb available?

u-boot initializes the memory, the kernel just uses what's available.

Regards,

8

Not necessarily an issue. Originally I was wondering if only half of available physical memory was being made available. Still, I’d like to understand why the device tree bindings indicate 256 MB memory, yet it appears that the full 512 MB are available.

9

Can anyone explain how/why the dtc specification of memory size is not being used, and/or where the actual size is coming from?

10

u-boot... Would you feel more comfortable if i patch the
am335x-boneblack.dtb to the correct memory size, on the next kernel
build, even thou it won't really change anything?

Regards,

11

@ags:

u-boot reads the fdt, probes stuff, adds things to the fdt, modifies things in the fdt and passes this modified version on the GNU/Linux kernel.

Assuming you configured your kernel correctly you can inspect the fdt in runtime. I did this on a beagle bone black (with the “wrong” memory setting in the fdt: memory { device_type = “memory”; reg = <0x80000000 0x10000000l>; }:wink:

root@beagle-bone-black-ml:/proc/device-tree/memory# cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 2 (v7l)
Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc08
CPU revision : 2

Hardware : Generic AM33XX (Flattened Device Tree)
Revision : 0000
Serial : 0000000000000000
root@beagle-bone-black-ml:/proc/device-tree/memory# cat /proc/version
Linux version 3.14.1 (builder@ubuntu-srvr-lv-kvm3) (gcc version 4.8.1 (GCC) ) #1 SMP Mon Apr 21 14:46:38 EEST 2014

root@beagle-bone-black-ml:/proc/device-tree/memory# hexdump -C ‘/proc/device-tree/memory/name’
00000000 6d 65 6d 6f 72 79 00 |memory.|
00000007
root@beagle-bone-black-ml:/proc/device-tree/memory# hexdump -C ‘/proc/device-tree/memory/device_type’
00000000 6d 65 6d 6f 72 79 00 |memory.|
00000007
root@beagle-bone-black-ml:/proc/device-tree/memory# hexdump -C ‘/proc/device-tree/memory/reg’
00000000 80 00 00 00 20 00 00 00 |… …|
00000008

As you can see the reg setting was “automagically” changed by u-boot to 0x20000000 and passed on to the GNU/Linux kernel.
So it will not make any difference if you change the memory size setting in the fdt file, except for making things a bit more consistent.

Regards,

Robert

12

Thanks for the reply. I mostly wanted to verify that my understanding of dt is correct, and this was confusing. I was also hoping to learn something new (why was the specification in the .dtb file no consistent with the actual memory being used) - which you’ve helped with by pointing out the role of u-boot in this (I know nothing about u-boot).

No need to change the .dtb on my behalf now that I understand. However, it may avoid future confusion for others if it is made consistent with the actual hardware configuration.