Created attachment 215265 [details]
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.
Since r363162 the installed memory is printed during boot.
(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.
Created attachment 217160 [details]
RPi4B dmesg verbose output
(In reply to Mitchell Horne from comment #2)
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.
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
(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. :)
(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
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.
With the u-boot.bin from
FreeBSD finally recognizes the full 4GB.
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).
... Make that 3832MB in the "avail memory =" dmesg line.
(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.
(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.
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.