Re: FreeBSD on RPI4B: shows an incorrect value of RAM
Mark Millard via freebsd-arm <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.arm |
|---|---|
| Message-ID | <[email protected]> |
On 2021-Jan-20, at 14:25, Oleg Ginzburg via freebsd-arm <[email protected]> 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) _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "[email protected]"