Date: Tue, 11 Aug 2020 13:57:06 -0700 From: Mark Millard <marklmi@yahoo.com> To: Gordon Bergling <gbe@freebsd.org> Cc: freebsd-arm@freebsd.org Subject: Re: RPi4B only allocates 1GB instead of 4GB Message-ID: <40AFD587-9BC9-457E-8DB4-F33E78861614@yahoo.com> In-Reply-To: <20200811194713.GA54090@lion.0xfce3.net> References: <20200811194713.GA54090@lion.0xfce3.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
>=20
> I spent some time today looking through the general determination of =
physical=20
> 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.
>=20
> 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.
>=20
> Has anyone a RPi4 or RPi4B with memory !=3D 1GB, who could verify that =
issue?
>=20
> 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.
>=20
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.)
=46rom your dmesg report:
Type Physical Virtual #Pages Attr
Reserved 000000000000 0 00000002 WB=20
ConventionalMemory 000000002000 2000 00007ef0 WB=20
BootServicesData 000007ef2000 7ef2000 0000001c WB=20
ConventionalMemory 000007f0e000 7f0e000 00029f81 WB=20
BootServicesData 000031e8f000 31e8f000 00000001 WB=20
LoaderData 000031e90000 31e90000 00008001 WB=20
LoaderCode 000039e91000 39e91000 000000aa WB=20
Reserved 000039f3b000 39f3b000 00000007 WB=20
BootServicesData 000039f42000 39f42000 00000001 WB=20
Reserved 000039f43000 39f43000 00000002 WB=20
RuntimeServicesData 000039f45000 39f45000 00000001 WB RUNTIME
Reserved 000039f46000 39f46000 00000001 WB=20
BootServicesData 000039f47000 39f47000 00000002 WB=20
RuntimeServicesData 000039f49000 39f49000 00000002 WB RUNTIME
LoaderData 000039f4b000 39f4b000 00001405 WB=20
RuntimeServicesCode 00003b350000 3b350000 00000010 WB RUNTIME
LoaderData 00003b360000 3b360000 000000a0 WB=20
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=20
0x32000000 - 0x33392fff, 19 MB ( 5011 pages) NoAlloc=20
0x39f3b000 - 0x39f41fff, 0 MB ( 7 pages) NoAlloc=20
0x39f43000 - 0x39f46fff, 0 MB ( 4 pages) NoAlloc=20
0x39f49000 - 0x39f4afff, 0 MB ( 2 pages) NoAlloc=20
0x3b350000 - 0x3b35ffff, 0 MB ( 16 pages) NoAlloc=20
0x3e513000 - 0x3ebebfff, 6 MB ( 1753 pages) NoAlloc=20
0xfe100000 - 0xfe100fff, 0 MB ( 1 pages) NoAlloc=20
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.)
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40AFD587-9BC9-457E-8DB4-F33E78861614>