RPi4B only allocates 1GB instead of 4GB

[Mark Millard]

On 2020-Aug-11, at 12:47, Gordon Bergling <gbe at freebsd.org> wrote:

> I am currently working on an issue [1] of FreeBSD regarding the memory allocation
> on the RPi4B. I have a 4GB model running a very recent version of -CURRENT,
> but FreeBSD only recognizes 1GB instead of the installed 4GB of memory.
> 
> I spent some time today looking through the general determination of physical 
> memory in FreeBSD in sys/vm/vm_phys.c, but my initial try to simply the issue
> by building a kernel without NUMA support wasn't that successful.
> 
> The next part I was thinking about was the firmware -> kernel interface, lets
> say UEFI vs. 'plain u-boot'. But after the study of information I found on the
> net, that is a far different story, compared to read C-sources.
> 
> Has anyone a RPi4 or RPi4B with memory != 1GB, who could verify that issue?
> 
> I found some information on a chinese website where somebody posted a dmesg
> output of FreeBSD 13-CURRENT on an RPi4B (8 GB version) where the memory
> allocation was correct.
> 

I've access to both 4 GiBYTe and 8 GiByte RPi4B's. I've
had no trouble with RAM size being recognized at any
time. As stands, I've got head -r363590 in use.

But, be warned, FreeBSD does not correctly handle DMA
for > 3 GiByte yet. The only stable environment I've
had for FreeBSD has been UEFI/ACPI with the selection
to limit RAM to 3 GiBytes.

For 4 GiByte+ I would have various 4K pages written to
the USB SSD that had the wrong content. Copying a huge
file and then diffing the copies seemed to be guaranteed
to fail. (I generally picked "huge" to be more than then
amount of RAM.) Both UEFI/ACPI and u-boot for this.

I'll note that I do some cross-checking by also running
NetBSD (also via UEFI/ACPI). In that context I've had
no troubles with allowing the actual RAM size.

For the FreeBSD UEFI/ACPI boots, I use a USB Ethernet
device, not the built in. The built-in and the sdcard
slot are ignored still for the UEFI/ACPI context. (They
work on NetBSD.)

From your dmesg report:

                   Type     Physical      Virtual   #Pages Attr
               Reserved 000000000000            0 00000002 WB 
     ConventionalMemory 000000002000         2000 00007ef0 WB 
       BootServicesData 000007ef2000      7ef2000 0000001c WB 
     ConventionalMemory 000007f0e000      7f0e000 00029f81 WB 
       BootServicesData 000031e8f000     31e8f000 00000001 WB 
             LoaderData 000031e90000     31e90000 00008001 WB 
             LoaderCode 000039e91000     39e91000 000000aa WB 
               Reserved 000039f3b000     39f3b000 00000007 WB 
       BootServicesData 000039f42000     39f42000 00000001 WB 
               Reserved 000039f43000     39f43000 00000002 WB 
    RuntimeServicesData 000039f45000     39f45000 00000001 WB RUNTIME
               Reserved 000039f46000     39f46000 00000001 WB 
       BootServicesData 000039f47000     39f47000 00000002 WB 
    RuntimeServicesData 000039f49000     39f49000 00000002 WB RUNTIME
             LoaderData 000039f4b000     39f4b000 00001405 WB 
    RuntimeServicesCode 00003b350000     3b350000 00000010 WB RUNTIME
             LoaderData 00003b360000     3b360000 000000a0 WB 
         MemoryMappedIO 0000fe100000     fe100000 00000001 RUNTIME
Physical memory chunk(s):
  0x00002000 - 0x39f3afff,   927 MB ( 237369 pages)
  0x39f42000 - 0x39f42fff,     0 MB (      1 pages)
  0x39f45000 - 0x39f45fff,     0 MB (      1 pages)
  0x39f47000 - 0x3b34ffff,    20 MB (   5129 pages)
  0x3b360000 - 0x3b3fffff,     0 MB (    160 pages)
Excluded memory regions:
  0x00000000 - 0x00001fff,     0 MB (      2 pages) NoAlloc 
  0x32000000 - 0x33392fff,    19 MB (   5011 pages) NoAlloc 
  0x39f3b000 - 0x39f41fff,     0 MB (      7 pages) NoAlloc 
  0x39f43000 - 0x39f46fff,     0 MB (      4 pages) NoAlloc 
  0x39f49000 - 0x39f4afff,     0 MB (      2 pages) NoAlloc 
  0x3b350000 - 0x3b35ffff,     0 MB (     16 pages) NoAlloc 
  0x3e513000 - 0x3ebebfff,     6 MB (   1753 pages) NoAlloc 
  0xfe100000 - 0xfe100fff,     0 MB (      1 pages) NoAlloc 

That means that nothing later in FreeBSD is going to
see more RAM.

May be u-boot or UEFI can report the amount of RAM it
finds? If it is 1 GiByte at such an early stage, later
stages are not likely to find more. If UEFI/ACPI finds
1 GiByte, a NetBSD test would likely agree. (Same type
of staging issue.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)