RAM (for a Raspberry Pi3B+) reported as 100Mb instead of 1GB

Reported memory when running openwrt is about 100 Mb :

# free
             total       used       free     shared    buffers     cached
Mem:        108312      26388      81924         56        732       6728
-/+ buffers/cache:      18928      89384
Swap:            0          0          0
cat /proc/meminfo 
MemTotal:         108312 kB
MemFree:           81864 kB
MemAvailable:      62512 kB
Buffers:             732 kB
Cached:             6728 kB
SwapCached:            0 kB
Active:             7440 kB
Inactive:           1680 kB
Active(anon):       1696 kB
Inactive(anon):       20 kB
Active(file):       5744 kB
Inactive(file):     1660 kB
# top
Mem: 26452K used, 81860K free, 56K shrd, 732K buff, 6728K cached

However, when running "Raspbian LIte", the memory shows up according spec, about 1Gb.

Is this fake reporting or is this the real available memory?

OpenWRT version:

# uname -a
Linux OpenWrt 4.9.152 #0 SMP Mon Jan 28 08:54:32 2019 aarch64 GNU/Linux

OpenWRT build version:


(Some additional files were required to be added by hand as described here.)

SOLUTION EDIT: I've selected @anon50098793 's answer as a solution. It was in fact a version problem with Broadcom's software which needlessly broke back compatibility. The full solution is to use the full set of Broadcom software corresponding to a certain raspbian release - changing onlystart.elf could lead to other more subtle problems.

apples aren't apples.... which version?


@anon50098793 - Good point. Updated with version info.

1 Like

Appears to be related to start.elf .... see cwm here.....https://elinux.org/RPiconfig

dmesg | grep vc
cat /proc/cmdline

raw guesswork... absolutely know zero about these things.....


1 Like

That was helpful.

# dmesg | grep vc
[    0.000000] Kernel command line: 8250.nr_uarts=1 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708_fb.fbswap=1 vc_mem.mem_base=0xec00000 vc_mem.mem_size=0x10000000  dwc_otg.lpm_enable=0 console=ttyS0,115200 kgdboc=ttyS0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=squashfs,ext4 rootwait
[    0.777810] vc-mem: phys_addr:0x00000000 mem_base=0x0ec00000 mem_size:0x10000000(256 MiB)

mem_size:0x10000000(256 MiB) when it should be 4x that. So if the GPU grabbed 128Mb of memory based on detecting 1Gb of RAM, but only 256Mb of ram was allocated to due the the command line, that might explain why free only reports about 110 Mb total - 108 + 128 =~ 256.

Unfortunately, neither of the files /boot/cmdline.txt and /boot/config.txt have any parameter mem_size=. I don't know where that's getting set, but next I'll look in the build image.

edit: FWIW I did some grepping for mem_size in boot and found this:

/boot/kernel8.img ::: 
6vc-mem: phys_addr:0x%08lx mem_base=0x%08x mem_size:0x%08x(%u MiB)
%s:could not create vc_mem_size entry

/boot/start_cd.elf ::: 
 vc_mem.mem_base=0x%x vc_mem.mem_size=0x%x 

/boot/start.elf ::: 
 vc_mem.mem_base=0x%x vc_mem.mem_size=0x%x 

The start.elf file used for the openwrt boot is copied from debian-lite, although the kernel file is different. The debian-lite boots up with the correct memory (0x40000000) shown in /proc/cmdline. So I think the problem lies not in start.elf itself, but in whatever parameters it is reading. I'm having no luck at finding those parameters anywhere, not even in the build image directory.

A blog "Understanding the Raspberry Pi Boot Process" says:

The third stage bootloader - start.elf, also passes extra parameters to the kernel than contained within the cmdline.txt. For example, my Linux Kernel receives the following parameters, specifying DMA channels, GPU parameters, MAC addresses, eMMC clock speeds and allowable Kernel Memory size.


However, that blog doesn't say that those parameters are embedded in start.elf, and if not, where they are read from.

The problem was that newer versions of these Broadcom proprietary files changed but didn't support back compatibility:


I changed to a version set dated June, 2018. Unfortunately there is no version control to make it clear when a new version set will break existing kernels. Also there is no documentation about this particular change at all. Back-compatibility is not that hard - Broadcom should have followed it.

Just to be clear, I was able to use openwrt 18.06.2 (rpi3b+ specific) using the June 2018 version of the above Broadcom files.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.