Date: Wed, 12 Aug 2020 14:44:27 +0400 From: Hrant Dadivanyan <hrant@dadivanyan.com> To: freebsd-arm@freebsd.org Subject: Re: RPi4B only allocates 1GB instead of 4GB Message-ID: <379196eb-8188-1325-9162-d1bdc054e0e2@dadivanyan.com> In-Reply-To: <40AFD587-9BC9-457E-8DB4-F33E78861614@yahoo.com> References: <20200811194713.GA54090@lion.0xfce3.net> <40AFD587-9BC9-457E-8DB4-F33E78861614@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --noUf999RBvDqWAQ4F8c5f72ZpIa7gZSmY Content-Type: multipart/mixed; boundary="ksyBvGsroXhTxXHhZuQD8fQ1lJjWc1ICL" --ksyBvGsroXhTxXHhZuQD8fQ1lJjWc1ICL Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Mark, On 2020-08-12 00:57, Mark Millard via freebsd-arm wrote: >=20 >=20 > On 2020-Aug-11, at 12:47, Gordon Bergling <gbe at freebsd.org> wrote: >=20 >> I am currently working on an issue [1] of FreeBSD regarding the memory= allocation >> on the RPi4B. I have a 4GB model running a very recent version of -CUR= RENT, >> but FreeBSD only recognizes 1GB instead of the installed 4GB of memory= =2E >> >> I spent some time today looking through the general determination of p= hysical=20 >> memory in FreeBSD in sys/vm/vm_phys.c, but my initial try to simply th= e issue >> by building a kernel without NUMA support wasn't that successful. >> >> The next part I was thinking about was the firmware -> kernel interfac= e, lets >> say UEFI vs. 'plain u-boot'. But after the study of information I foun= d on the >> net, that is a far different story, compared to read C-sources. >> >> Has anyone a RPi4 or RPi4B with memory !=3D 1GB, who could verify that= issue? >> >> I found some information on a chinese website where somebody posted a = dmesg >> output of FreeBSD 13-CURRENT on an RPi4B (8 GB version) where the memo= ry >> allocation was correct. >> >=20 > I've access to both 4 GiBYTe and 8 GiByte RPi4B's. I've > had no trouble with RAM size being recognized at any > time. As stands, I've got head -r363590 in use. >=20 > 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 with the selection > to limit RAM to 3 GiBytes. >=20 > For 4 GiByte+ I would have various 4K pages written to > the USB SSD that had the wrong content. Copying a huge > file and then diffing the copies seemed to be guaranteed > to fail. (I generally picked "huge" to be more than then > amount of RAM.) Both UEFI/ACPI and u-boot for this. >=20 > I'll note that I do some cross-checking by also running > NetBSD (also via UEFI/ACPI). In that context I've had > no troubles with allowing the actual RAM size. >=20 > For the FreeBSD UEFI/ACPI boots, I use a USB Ethernet > device, not the built in. The built-in and the sdcard > slot are ignored still for the UEFI/ACPI context. (They > work on NetBSD.)> Both works for me in UEFI boot as of -r364058 and some woodoo from wiki. Boot off the SD card that contains root and var partitions, and using onboard genet0. I didn't test DMA like you, but svn checkout and updates of src and ports works well. The world compiles in ten hours - there is cooling fan that reduces idle CPU temperature to ~50C, so it throttling less than without cooling. > From your dmesg report: >=20 > Type Physical Virtual #Pages Attr > Reserved 000000000000 0 00000002 WB=20 > ConventionalMemory 000000002000 2000 00007ef0 WB=20 > BootServicesData 000007ef2000 7ef2000 0000001c WB=20 > ConventionalMemory 000007f0e000 7f0e000 00029f81 WB=20 > BootServicesData 000031e8f000 31e8f000 00000001 WB=20 > LoaderData 000031e90000 31e90000 00008001 WB=20 > LoaderCode 000039e91000 39e91000 000000aa WB=20 > Reserved 000039f3b000 39f3b000 00000007 WB=20 > BootServicesData 000039f42000 39f42000 00000001 WB=20 > Reserved 000039f43000 39f43000 00000002 WB=20 > RuntimeServicesData 000039f45000 39f45000 00000001 WB RUNTIME > Reserved 000039f46000 39f46000 00000001 WB=20 > BootServicesData 000039f47000 39f47000 00000002 WB=20 > RuntimeServicesData 000039f49000 39f49000 00000002 WB RUNTIME > LoaderData 000039f4b000 39f4b000 00001405 WB=20 > RuntimeServicesCode 00003b350000 3b350000 00000010 WB RUNTIME > LoaderData 00003b360000 3b360000 000000a0 WB=20 > MemoryMappedIO 0000fe100000 fe100000 00000001 RUNTIME > Physical memory chunk(s): > 0x00002000 - 0x39f3afff, 927 MB ( 237369 pages) > 0x39f42000 - 0x39f42fff, 0 MB ( 1 pages) > 0x39f45000 - 0x39f45fff, 0 MB ( 1 pages) > 0x39f47000 - 0x3b34ffff, 20 MB ( 5129 pages) > 0x3b360000 - 0x3b3fffff, 0 MB ( 160 pages) > Excluded memory regions: > 0x00000000 - 0x00001fff, 0 MB ( 2 pages) NoAlloc=20 > 0x32000000 - 0x33392fff, 19 MB ( 5011 pages) NoAlloc=20 > 0x39f3b000 - 0x39f41fff, 0 MB ( 7 pages) NoAlloc=20 > 0x39f43000 - 0x39f46fff, 0 MB ( 4 pages) NoAlloc=20 > 0x39f49000 - 0x39f4afff, 0 MB ( 2 pages) NoAlloc=20 > 0x3b350000 - 0x3b35ffff, 0 MB ( 16 pages) NoAlloc=20 > 0x3e513000 - 0x3ebebfff, 6 MB ( 1753 pages) NoAlloc=20 > 0xfe100000 - 0xfe100fff, 0 MB ( 1 pages) NoAlloc=20 >=20 > That means that nothing later in FreeBSD is going to > see more RAM. >=20 > May be u-boot or UEFI can report the amount of RAM it > finds? If it is 1 GiByte at such an early stage, later > stages are not likely to find more. If UEFI/ACPI finds > 1 GiByte, a NetBSD test would likely agree. (Same type > of staging issue.)> Indeed: The one supplied with -r363236 snapshot as of Jul 16 reports: U-Boot 2020.07 (Jul 16 2020 - 04:57:41 +0000) DRAM: 240 MiB RPI 4 Model B (0xd03114) The other one - https://sourceforge.net/projects/rpi4-8gbram-boot-fbsdonly/files/u-boot.b= in/download : U-Boot 2020.07-rc3-00208-g88bd5b1793-dirty (Jun 06 2020 - 20:33:00 +0100)= DRAM: 7.2 GiB RPI 4 Model B (0xd03114) Thank you, Hrant > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >=20 --ksyBvGsroXhTxXHhZuQD8fQ1lJjWc1ICL-- --noUf999RBvDqWAQ4F8c5f72ZpIa7gZSmY Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQEzBAEBCAAdFiEEPbz+l3tnoK718ci3h/fmw7c/bD0FAl8zyAsACgkQh/fmw7c/ bD0rBgf/cvt8Q4P8MSuerLrGXM108E52Tqj1JSTiMXKQyMScAMHZd+Nlrcmrdo56 SQ9/ejNsRCyTL/NJRjK/KoUhtebdL24A7v0wEf9E+nggiMa5pnZDIMW+NkFeu1Gd wy/x6LEjxCQJXzdEj4OqZOrKpkyX2+xmsuxiPwMmXiGZFvVu4S4LkV5HYiRe3kLK rNBeTBOixkZxLBhEfUzt99OaWqVjYPSSf9vBeJ4ptGeczx1XhichyBok51/lg+v9 hKMCKoutoAf94jfPql6txabZlCLZdD8PzffVONtZ1VnF4HhLe3NB1oR6fUXK9vAI Ytz7aQ6xERUfVfQ2dVkdvkS7oCoJ5Q== =bSol -----END PGP SIGNATURE----- --noUf999RBvDqWAQ4F8c5f72ZpIa7gZSmY--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?379196eb-8188-1325-9162-d1bdc054e0e2>