RPi4B only allocates 1GB instead of 4GB

Wed Aug 12 10:44:46 UTC 2020

Hi Mark,

On 2020-08-12 00:57, Mark Millard via freebsd-arm wrote:
> 
> 
> 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.)>

Both works for me in UEFI boot as of -r364058 and some woodoo from wiki.
Boot off the SD card that contains root and var partitions, and using
onboard genet0. I didn't test DMA like you, but svn checkout and updates
of src and ports works well.
The world compiles in ten hours - there is cooling fan that reduces idle
CPU temperature to ~50C, so it throttling less than without cooling.

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

Indeed:
The one supplied with -r363236 snapshot as of Jul 16 reports:
U-Boot 2020.07 (Jul 16 2020 - 04:57:41 +0000)

DRAM:  240 MiB
RPI 4 Model B (0xd03114)

The other one -
https://sourceforge.net/projects/rpi4-8gbram-boot-fbsdonly/files/u-boot.bin/download
:
U-Boot 2020.07-rc3-00208-g88bd5b1793-dirty (Jun 06 2020 - 20:33:00 +0100)

DRAM:  7.2 GiB
RPI 4 Model B (0xd03114)

Thank you,
Hrant

> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
> 
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 554 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20200812/38477f70/attachment.sig>