FreeBSD on RPI4B: shows an incorrect value of RAM

Mark Millard marklmi at yahoo.com
Wed Jan 20 23:06:32 UTC 2021



On 2021-Jan-20, at 14:25, Oleg Ginzburg via freebsd-arm <freebsd-arm at freebsd.org> wrote:

> Recently became the owner of an RPI4-B board. Latest FreeBSD snapshot (
> FreeBSD-13.0-CURRENT-arm64-aarch64-RPI-20210107-f2b794e1e90-255641.img )
> boots successfully. However, for some reason, the system only sees 3.1
> gigabytes.
> This model has 8 GB of RAM. Any ideas?
> 
> https://www.bsdstore.ru/trash/IMG_20210121_000558.jpg
> https://www.bsdstore.ru/trash/IMG_20210120_224751.jpg
> 
> ps: booted from SD via RPI_EFI.fd (
> https://github.com/pftf/RPi4/releases/tag/v1.22 ), config.txt:
> 
> disable_splash=1
> arm_64bit=1
> enable_uart=1
> uart_2ndstage=1
> enable_gic=1
> armstub=RPI_EFI.fd
> #disable_commandline_tags=1
> #disable_overscan=1
> #device_tree_address=0x1f0000
> #device_tree_end=0x200000
> #dtoverlay=miniuart-bt

The UEFI/ACPI ( RPI_EFI.fd ) means of booting has the UEFI
defaults being to restrict to 3 GiByte of RAM.

It can be changed and saved in UEFI. Or you can boot via
an appropriate u-boot based boot-configuration that will
not restrict itself.

However, last I tested an unpatched FreeBSD, FreeBSD does
not handle DMA for file system activity correctly when
there is more than 3 GiByte of RAM: duplicating a large
file like (from my context):

-rw-r--r--  1 root  wheel  11570948096 Jul 18 18:32:37 2020 /usr/obj/clang-armv7-on-aarch64.tar

to:

-rw-r--r--  1 root  wheel  11570948096 Jul 18 18:32:37 2020 /usr/obj/clang-armv7-on-aarch64.alt_tar

and then using diff or cmp or such on the two files will
report there being differences. Small files also could
get such behavior (which is how I found the problem
originally). Big enough files have always had a copy
failure for some part(s) of the file.

FYI:
The RPi4B's have an error that OS's have to work around
in order for DMA to work right. The work-around is not
complete/correct yet in any committed update so far as
I know. Part of it was DMA_HIGH_LIMIT being too large
relative to page boundaries for how the code uses it:
one too many pages used as a result. Some other code
from experiments that were done also probably also
should be reverted (for example, put back some of the
BUS_SPACE_MAXSIZE use: maxsize and maxsegsize arguments).

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



More information about the freebsd-arm mailing list