From owner-freebsd-arm@freebsd.org Wed Aug 12 10:44:45 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E6BAF37C047 for ; Wed, 12 Aug 2020 10:44:45 +0000 (UTC) (envelope-from hrant.dadivanyan@gmail.com) Received: from mail-lj1-f194.google.com (mail-lj1-f194.google.com [209.85.208.194]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BRRCw5Z9qz3Vp4 for ; Wed, 12 Aug 2020 10:44:44 +0000 (UTC) (envelope-from hrant.dadivanyan@gmail.com) Received: by mail-lj1-f194.google.com with SMTP id t23so1692120ljc.3 for ; Wed, 12 Aug 2020 03:44:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to; bh=TIg3S99HmbHFMvvLpueLOwfueNL+Z9Zks15oBoUCcec=; b=syv3B+sOIzNXjhL7sbbq+8i0QiZ0g1O2yRqG5IUACpgNCcykwrUC4ofcTSpR7NYDuv wFYUG5yooBiO+xVTuAaN2HRAq3q9Df5yL11rNaOzR9/nxMigm9uE3m7QI5yvJSMvHIy9 exr1lQOVFGBFsBiFrlBu7TjNWLVkY14GqeofivAHdC6WlDUtc+pUD+uKdw/DjXFfwwyX W3s6rha6R7qF2He75iPwju1CkG1vA7+PVX1kqm+izBDOG2SVnW0asVaaIIbJ0W9m+1sK 2YjadPDovRTilTsVSrEfAwapPvPN6RTVI9+WB5Qw51s55nIdcF3WsVPFbGmtX04ZcpS3 hk+A== X-Gm-Message-State: AOAM532EyW+vKo3ywpqxM4/roqn8DjL9noZQbfP170tmk+HpL/mdxbX2 GPNxsyJquc3gOy0qdXKvK8VxWHnt X-Google-Smtp-Source: ABdhPJyM3AmKRQy872kBuKrhtIRTNoCOxmTAscma4blQVwVUhWIeNYcEN4W0FGufzuEk1xeGtstt0Q== X-Received: by 2002:a2e:8612:: with SMTP id a18mr5160249lji.149.1597229082512; Wed, 12 Aug 2020 03:44:42 -0700 (PDT) Received: from dadivanyan.net ([62.89.17.242]) by smtp.gmail.com with ESMTPSA id d26sm380412lfq.73.2020.08.12.03.44.41 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 Aug 2020 03:44:41 -0700 (PDT) Subject: Re: RPi4B only allocates 1GB instead of 4GB To: freebsd-arm@freebsd.org References: <20200811194713.GA54090@lion.0xfce3.net> <40AFD587-9BC9-457E-8DB4-F33E78861614@yahoo.com> From: Hrant Dadivanyan Autocrypt: addr=hrant@dadivanyan.com; keydata= mQENBFgDUB4BCACuEuOfqVeiotV5BY/6IlWfSvmsY+EI9yYA62Q5310oYUsKBL4HwKpNl5N2 7Nt3YJWp5QAkB49B4msl9fGpzKK/obxDwoM37bf3Np789dSRp9EKk71Thel3eeaYvaz2K7w4 iT+R5/1/5Wvn5TqV96X9aTlmzDkz7eHJ3SRVsz2Vbk4fbbFSAv1OaDaiscOVpDXZsVLUMoL3 N8YLMmsNHw8pt7Kh/08Pd5SU4k576Mo2TUWG0uRiL2BunQP/JMvs/jU8L5xpaXi1MfEFyRfC 3xEeEM9hjBn3PgJgtJW071CRibc7E+e9Xi5K7kVn4MQnoZM0byiyC26XHtKehS7rtoZDABEB AAG0J0hyYW50IERhZGl2YW55YW4gPGhyYW50QGRhZGl2YW55YW4ubmV0PokBOAQTAQIAIgUC WANQHgIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQh/fmw7c/bD0TmwgApxRd9pxN dypwqb87PYTbEwn9lBl4lHOTjuvrH+MWeIYhnG9R9AOd+MsxixMxvCVL+o54qv9HDx9Ew3ao u89QqAjzB/vsqBUldr1hluO8VUeFAYAiXZQKjToMPZQjFANrIdlAkb4E4DhGG8lKSL+t/yqf Ey3YXcx7qntsPCHnkZbXzabx37x2MOHyuSLLoqvmNHq7un99+dhNgdNxQCliDEqys8xe3Iie uThYdAaxczqZ6oHQ0iMsRJgJRwXB9CengCxZ+Znd48ugdE1ueig6NJxlrpdSrAgNpa393Cwf FLi9SkKSGciSCWjTWjkcv1Mwj5kFzSrRlLKt0/MsPwOTt7kBDQRYA1AeAQgA82m2h8C4Sj4B Kzvw29PQ3IyiQCx5mwP6JDp3X+ePPT8ZG0yDveTqXQej9ZPTOpUdofMgPc86qp19zyjAqc0l 6liOxxFAEGfV3dWKJGXA0t5dQiuBeVb+++Z8WsSsKG8pVoeFkchBvJK5DlHgpb7DaUNLevBK /fR9x3apK1zeyz2W2njs8MI7+ZBEW9O2FaEV2m9VkjVJj5SBBbm+IMYJKhgH0tPwViPoLBbp mpII1zCNyu74XlyjmPkfa5DW862UvAvljtJmNlgFt6Lu/BJYNvqe1Q56hA1NwmVjNrofnLur Vr36L/bBcmBCNXqOBmafjrjnrX5Q7eJyJDe8E2h9RwARAQABiQEfBBgBAgAJBQJYA1AeAhsM AAoJEIf35sO3P2w9RcgIAIgkvrZ7MvKWUe93WLDjpSOAL9iq8DxPTczjQ2vlnVawn0bh7Qvq Awktno+4PXi5CRx4k43npnRrj6NTg4QYrGW5eir9XQnAY45K29GeTB/TbTG7PHJfwDYD9SCW aultbVIWKlzJVreRuQFbQYMau67RLs1x2g5XkZlbGtk9gReEQv5wXUiW2KHXTxdZVAz7Imfe E7Qm/YQPImxUWj6s46gyLnSq20rGrtd1240rKHML3eVKTU7daBcs5YV0QOKOlDEbXO8J+Y0O iz7QApDB0RfSTHvUh6bn6P7cNPXQFA6JYfd9TIaW32tAUJYeYB6Q5q29VeXH0s+qJE7OLFDT YQI= Message-ID: <379196eb-8188-1325-9162-d1bdc054e0e2@dadivanyan.com> Date: Wed, 12 Aug 2020 14:44:27 +0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <40AFD587-9BC9-457E-8DB4-F33E78861614@yahoo.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="noUf999RBvDqWAQ4F8c5f72ZpIa7gZSmY" X-Rspamd-Queue-Id: 4BRRCw5Z9qz3Vp4 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hrantdadivanyan@gmail.com designates 209.85.208.194 as permitted sender) smtp.mailfrom=hrantdadivanyan@gmail.com X-Spamd-Result: default: False [-4.68 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_SHORT(-0.63)[-0.630]; SIGNED_PGP(-2.00)[]; FORGED_SENDER(0.30)[hrant@dadivanyan.com,hrantdadivanyan@gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[62.89.17.242:received]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; R_DKIM_NA(0.00)[]; TAGGED_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.960]; FROM_NEQ_ENVFROM(0.00)[hrant@dadivanyan.com,hrantdadivanyan@gmail.com]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[dadivanyan.com]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.99)[-0.994]; RCVD_IN_DNSWL_NONE(0.00)[209.85.208.194:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.194:from]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 10:44:46 -0000 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 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--