From owner-freebsd-arm@freebsd.org Wed May 20 00:59:44 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 6EF1F2FA8D8 for ; Wed, 20 May 2020 00:59:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49RZCg3g10z4T7h for ; Wed, 20 May 2020 00:59:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: q0d5cFMVM1kFBe3MSypTDkpgzQ_spTClWnUmJq_OJyE5DoBt7B53rnzrYxhwJC1 GvlzAYsaTLqZZU7UR8wmxC0VH9RKWFvNlL9Rk.QfhnK8m0mTjV28QmSbvYeLjbupBCx7CUWf1AWX wceNxwxChWiE2IjnvkYOXjOje70mOGnXsSqexWURrKKcMtpfFdApMHYhSDGRkXC2l0MkUAnIY6Ye MNPQ20vOTsoAsvX5vzAEjSTTTfFSMdYhq5MCyHt00wbd9wuTaOc0u2QAX0KdmmEsazsRAX4Z6nYY wRZCcmVLvPP7xT9w2ODpTPbQF13KR6_BIuu.lPflYFD4BaOHH0y0gVRSr.Juk16Qe2YDR1Hsu6u6 PG1EWtHgoZbNctCoyz_EmYdS41x15G83AIBdvnhE_NpFm_9sEfDouqE1hP4bfSCI6Yu2c7cH9R.B EETOyeBzgE1Q8AG0Wa0n7MeancPkIsAq78KQONvkv7se0GK3ShEEBF_YWGWt6.VfoMcNnqzcjUtd MWNtkVkUo5mkvY_B0SDeWmbGwn9hi_XE6Q5wXC68JmPjiRl_stx4lUlLr6eFKPg.JgYEsV2OQcX5 Wdrtln39hZqBXJDYCksyFZcBdV76WyVUCwgn.vghP6ZOMXb6rZ07jWKso0j6LrXaGy_mGLEbOjCi BcQSqfKfW1Z2taje7xH30i28k8.Een1rYB_AuMq9QJkiyEzmdkx.bbuShnRyEywHhbjc4z3frAxj NDGb.IgJ2HtQxBkH8DwFFWwYeo2gNTMHWxpegPECiE6CjuZAif14mpslz6PWLgoWXATUQFDuO8Z_ sLS3DYQFMMXHS3dsePWXphVY1.1nDqxi6zt_GwE3wtm_2ncyCyVRIE3GuaThOxY09s15Iudrt6Nu ruZIo.Tm8rDdRXghr5Tka.3bda6lAjiJ8B_w982OzIrkczQaObH4VWglm8JMrMUXS_AMoM2Z_crU 3X4K0godpbgt3eXZtKhDwb5tqcSGcLBUDR2O5tqPXAzAjZqpXKY_LIJ3B4W5Tj5p_AbsXdTcEJxu wWxO5Xagm.bKj4DOlo31Otxpy9INRaeSxjmXr7VL.d.S8a59bv6rupmUnV3vJ8.V3JdXO.7COzqU fE08zAe8r4Ohx86Awt9aK66BDzz3RabiAjDIScs6jnC1SF0BT6ZxI3s8si_hT2vHmZpYQCibu13q khhXiq1YdwMVBUHLRyi5AFUhi6l1KxxgpbSvE4o3FWQlJ0dqZgzHyTfX3Za..WY6fkfgq3XeH9lX VhlnV8rQGYOkvxvA5TYJAvUDunWeN3_WDV7IKKAa7vCvouDjXuvzJN3LIyitfBTWHp5uceljDm1r 16kQh3W4m.aBxj2XHyAy_anQuN5uwJwjs.doazpLzIc03XQ16UhVkzmUDUG0fJ4RaQnLbJIs86nq dsJvCO9Fft1wMrB1s_CbMtYyFUZ19PHZdTSu9H028Yn59OflDwSiRqy22Wg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Wed, 20 May 2020 00:59:41 +0000 Received: by smtp412.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b39841441d4dc3afa521b2cafb763d1d; Wed, 20 May 2020 00:59:37 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: rpi4 headless experience Date: Tue, 19 May 2020 17:59:36 -0700 References: To: mack@macktronics.com, freebsd-arm In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49RZCg3g10z4T7h X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.10 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.148:from]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_MEDIUM(-0.89)[-0.889]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.148:from]; NEURAL_HAM_SHORT(-0.71)[-0.708]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] 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, 20 May 2020 00:59:44 -0000 On 2020-May-19, at 17:42, Mark Millard wrote: > Dan Mack mack at macktronics.com wrote on > Tue May 19 22:12:47 UTC 2020 : >=20 >> Thanks for you report info, especially the fact that you are having = it see=20 >> all your memory. Perhaps this is an issue with different revisions = of the=20 >> rpi4 ? I have a pre-Nov 2019 rpi4-4GB. >=20 > The 2 RPi4B's that I have access to are 4 GiByte models and > predate Nov-2019 for when they arrived. >=20 > Presuming an installation based on sysutils/u-boot-rpi4 > head -r528547 or later for reliable booting, the detection > has always indicated the 4 GiByte size. (The unreliable > booting also did as I remember: the problems were in > other aspects. But I avoid depending on unreliable > contexts for judgments.) u-boot-rpi4 -r528547 is from > 2020-Mar-16. >=20 > If I had to guess, you really tested a 1 GiByte RPi4. I > do not remember anyone previously reporting such an > incorrect memory size. (Not that there appear to be > many having used FreeBSD on a RPI4B at this point.) >=20 > One of the RPi4B is currently running head -r360311 : >=20 > hw.physmem: 4127358976 > hw.usermem: 4053913600 > hw.realmem: 4148047872 >=20 > RPi4B development is in the early stages, with not much > time spent on it as far as I can tell. It may be that > uefi/ACPI support may be how more ends up working at > some point. (Unclear path for progress: other things > are taking the time of those with the skill set for > the development but there is an independent uefi/ACPI > effort going on that may someday help.) Clearly Robert Crowston's separate notes indicate more folks are working on getting more going for the RPi4 than I thought of when I wrote the above. I did not mean the above to slight anyone's skills. It is just that, without the reminder, the activity did not come to mind. > Things like USB not working and the processor clock rate > being well below normal for an RPi4B are expected at > this stage. >=20 >> And I can confirm that reboot doesn't work, on my system, it does = this: >=20 > Known at this stage. Same here. >=20 >> root at generic >> :~ # reboot >> May 14 12:28:56 generic reboot[1642]: rebooted by root >> May 14 12:28:56 generic syslogd: exiting on signal 15 >> Waiting (max 60 seconds) for system process `vnlru' to stop... done >> Waiting (max 60 seconds) for system process `syncer' to stop... >> Syncing disks, vnodes remaining... 2 0 0 done >> Waiting (max 60 seconds) for system thread `bufdaemon' to stop... = done >> Waiting (max 60 seconds) for system thread `bufspacedaemon-0' to = stop...=20 >> done >> All buffers synced. >> lock order reversal: >> 1st 0xfffffd00012809f0 ufs (ufs) @ = /usr/src/sys/kern/vfs_mount.c:1631 >> 2nd 0xfffffd00012f5438 devfs (devfs) @=20 >> /usr/src/sys/fs/msdosfs/msdosfs_vfsops.c:945 >> stack backtrace: >> #0 0xffff00000047f440 at witness_debugger+0x64 >> #1 0xffff0000003e7794 at lockmgr_lock_flags+0x1d8 >> #2 0xffff0000004fa3c0 at _vn_lock+0x54 >> #3 0xffff0000002e5508 at msdosfs_sync+0x1a8 >> #4 0xffff0000002e512c at msdosfs_unmount+0x30 >> #5 0xffff0000004de514 at dounmount+0x430 >> #6 0xffff0000004e9034 at vfs_unmountall+0x8c >> #7 0xffff0000004c4844 at bufshutdown+0x280 >> #8 0xffff000000415ea4 at kern_reboot+0x238 >> #9 0xffff000000415c00 at sys_reboot+0x338 >> #10 0xffff000000775a00 at do_el0_sync+0x3f8 >> #11 0xffff000000759224 at handle_el0_sync+0x90 >> Uptime: 1h49m6s >=20 > The lock order reversal is normal and not limited > to arm families: all platforms used with typical > debug kernels report such. Non-debug kernels do > not report the reversal because the checks are > turned off. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)