Bug 247012 - FreeBSD only recognized 1 GB instead of 4 GB on Raspberry PI 4B
Summary: FreeBSD only recognized 1 GB instead of 4 GB on Raspberry PI 4B
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: arm (show other bugs)
Version: CURRENT
Hardware: arm64 Any
: --- Affects Many People
Assignee: freebsd-arm (Nobody)
Depends on:
Reported: 2020-06-05 17:35 UTC by Gordon Bergling
Modified: 2021-02-02 16:55 UTC (History)
6 users (show)

See Also:

RP4B dmesg (11.51 KB, text/plain)
2020-06-05 17:35 UTC, Gordon Bergling
no flags Details
RPi4B dmesg verbose output (36.09 KB, text/plain)
2020-08-11 20:01 UTC, Gordon Bergling
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gordon Bergling freebsd_committer 2020-06-05 17:35:02 UTC
Created attachment 215265 [details]
RP4B dmesg

FreeBSD is running fine on a Raspberry PI 4B, but it doesn't correctly recognized the memory of the board. I am currently running a PI 4B with 4 GB installed on a -CURRENT snapshot from the 4th of June 2020, but only 1 GB memory is shown by top.

Another problem is that FreeBSD isn't displaying the installed memory during boot like on amd64 and other architectures.

A dmesg is attach to this PR.
Comment 1 Gordon Bergling freebsd_committer 2020-07-22 19:19:46 UTC
Since r363162 the installed memory is printed during boot.
Comment 2 Mitchell Horne freebsd_committer 2020-08-11 19:56:21 UTC
(In reply to Gordon Bergling from comment #0)

Hi Gordon, can you attach a verbose dmesg (boot -v at loader prompt)? That will print out a detailed list of physical memory regions and whether they are excluded from general allocations.
Comment 3 Gordon Bergling freebsd_committer 2020-08-11 20:01:14 UTC
Created attachment 217160 [details]
RPi4B dmesg verbose output
Comment 4 Gordon Bergling freebsd_committer 2020-08-11 20:07:05 UTC
(In reply to Mitchell Horne from comment #2)

Hi Mitchell,

I have attached the verbose dmesg output.

As far as I can tell the memory region on the RPi4B is splitted due to the GPU, which is allocating its memory from the first 1GB and the rest of the installed memory is mapped to a second region.
Comment 5 Mark Millard 2020-08-11 21:19:13 UTC
Looks on the lists like you discovered that it was the u-boot that
you were using u-boot that limited the RAM available to 1 GiByte.

So I'll report here for reference for the RPi4B . . .

A variant of part of my list reply about using > 3 GiBytes of RAM:

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-booted with the
selection to limit RAM to 3 GiBytes (to avoid DMA
Comment 6 Gordon Bergling freebsd_committer 2020-08-11 21:28:16 UTC
(In reply to Mark Millard from comment #5)

Thanks for your reply. I just updated the u-boot.bin on the MSDOS partition, since it can be easily reverted from my notebook. I will do a 'make buildworld' tomorrow as a little stress test for the memory allocation on the RPi4B. The compilation of the google tests allocates very often more than 2 GB of memory so we see very quickly how stable this changes are. :)

Comment 7 Mark Millard 2020-08-11 21:43:09 UTC
(In reply to Gordon Bergling from comment #6)

One of the reasons that I run into the DMA issue is
that I use a USB3 SSD as the system drive. No sdcard
is involved.

Normal memory use as not been a problem, just various
DMA transfers that end up involving RAM addresses that
are out of range for the DMA hardware.

So, if your context is sdcard based, you might not
run into the issue, although I've no clue what all
might involve the problematical DMA issue other
than USB storage devices.
Comment 8 Gordon Bergling freebsd_committer 2020-08-13 13:18:16 UTC
With the u-boot.bin from 


FreeBSD finally recognizes the full 4GB.
Comment 9 Poul-Henning Kamp freebsd_committer 2020-11-28 13:39:25 UTC
I just tried FreeBSD-13.0-CURRENT-arm64-aarch64-RPI3-20201126-9e082d278b9.img.xz on my Rpi4B/4GB, and it (still) only finds 1GB (899MB)

With the u-boot.bin mentioned above it finds 4GB (3955MB).
Comment 10 Poul-Henning Kamp freebsd_committer 2020-11-28 13:40:05 UTC
... Make that 3832MB in the "avail memory =" dmesg line.
Comment 11 Helge Oldach 2020-12-13 07:42:04 UTC
(In reply to Poul-Henning Kamp from comment #10)
The latest u-boot.bin from sysutils/u-boot-rpi4 (version u-boot-rpi4-2020.10) works for me. It appears that u-boot in the snapshot build is outdated.

NB: In order to make an RPi4/8GB work with 8GB, add fixup4.dat, start4.elf, and bcm2711-rpi-4-b.dtb from the latest firmware at https://github.com/raspberrypi/firmware/raw/master/boot/

Meaning, also our firmware port sysutils/rpi-firmware is outdated (current version is rpi-firmware-1.20201022.g20201022) and therefore outdated in the snapshot build as well.
Comment 12 Helge Oldach 2020-12-13 14:06:47 UTC
(In reply to Helge Oldach from comment #11)
sysutils/rpi-firmware has been updated today and is suitable for RPi4/8GB. Now both sysutils/rpi-firmware and sysutils/u-boot-rpi4 need to be updated for snapshot building.
Comment 13 Gordon Bergling freebsd_committer 2021-02-02 16:55:19 UTC
This problem somewhat disappeared around Dezember 2020. I booted a snapshot of 13-CURRENT while trying a new micro-sd-card. The full memory of the RPi4B was detected.

If is becomes a new problem, a new PR should be opened.