Date: Wed, 20 Jan 2021 15:06:21 -0800 From: Mark Millard <marklmi@yahoo.com> To: Oleg Ginzburg <olevole@olevole.ru> Cc: freebsd-arm@freebsd.org Subject: Re: FreeBSD on RPI4B: shows an incorrect value of RAM Message-ID: <AD5590F5-FA84-4FDC-ACEC-D814137AE23C@yahoo.com> In-Reply-To: <CAMsb%2BmZVPcb6-c2zwd9Dy9_0Zm6oV%2BcvS9d%2BEkmr=9rSKx99uw@mail.gmail.com> References: <CAMsb%2BmZVPcb6-c2zwd9Dy9_0Zm6oV%2BcvS9d%2BEkmr=9rSKx99uw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Jan-20, at 14:25, Oleg Ginzburg via freebsd-arm = <freebsd-arm@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? >=20 > https://www.bsdstore.ru/trash/IMG_20210121_000558.jpg > https://www.bsdstore.ru/trash/IMG_20210120_224751.jpg >=20 > ps: booted from SD via RPI_EFI.fd ( > https://github.com/pftf/RPi4/releases/tag/v1.22 ), config.txt: >=20 > disable_splash=3D1 > arm_64bit=3D1 > enable_uart=3D1 > uart_2ndstage=3D1 > enable_gic=3D1 > armstub=3DRPI_EFI.fd > #disable_commandline_tags=3D1 > #disable_overscan=3D1 > #device_tree_address=3D0x1f0000 > #device_tree_end=3D0x200000 > #dtoverlay=3Dminiuart-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). =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?AD5590F5-FA84-4FDC-ACEC-D814137AE23C>