From owner-freebsd-arm@freebsd.org Wed May 20 00:42:46 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 9B1DB2FA91D for ; Wed, 20 May 2020 00:42:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.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 49RYr52KV1z4ST1 for ; Wed, 20 May 2020 00:42:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: DRYdSBMVM1noDTXAHDhvVDByO0qrQP0ZEfCl9RY31KZ8HXjgOiSk2MfQh2fXj2D 2ICtFEPtprrelEWVrM3outqKhh5vrU00_UxYCvTGmTJPUC9QVv6RoGyyzjsWAFc9I0UYGOYjOQ58 zmAJGCQ7qlFDGFRWpMl6MXETgH7vTF3.kDulxR2TO02mtnl4prB89zGOnZJc9sMleiiS985ASzmQ wrRbsf8YgzOtK5s5ipaLsdouoKJh3BOoMSeLrAcOuR1X3Zoebvtlu_CD43VjMP3K93lrxwQhJlaF bgG97YFVWTyQRxl41yQsWl32keSeqQ1HbB_NkWSMuruP.8xma.aheyhHCMtqjVTau9.IeI8tPdSi UzdViccVUgc.1QqPkucyM8G6.eJFbAbji6og.RgAxgFO0OQ2zxUNGy9ehRDB_jf7XydxdnSixxwp bh.avQ4Lm7Duc2T1sB2b07uwC_3T71cruhqYB1.u2F.0wmz.2ZrqFMm.npp2oTeRdaZ7rHFZaPqJ FoC77vHCJEekjF8fRaFbXdjClHLZdVJIK9t3oRgt.yR97.D5_Nf.4JdWTPdShVZTlf215bR9atT4 bBcPU5Z0zZhDUTDoavCjI0SBwzdAbtsIVZCgyVWT92m2YGtmCYfQBcVcVcjmO7FFqZkua61DTzSA RacaCgjV9Pxek7II.BbAEKYIxFpw9FQnqw3QFUbUPvWKZaxKa2W31_936Src8mh7o9pGYVktHbNO LDcKKcCpr_Ac4tPW4nwUnChDehwUwJkq1M0QWD5crdIYBJ5ePXwM3f6WMnu4bwDpA6Vx1zoODpM0 qBVGDth_yXOrvLi5R_ODAih7X40IL8ALkQA4sQmJyhJVGcBe9MDwyxwqnRsu5co1EYvah29vID3J 0CD1KdRZ2tnFkARuLfd3qXJcS8heHyNvL9Vfvt3LFOsLass8dmRq0TlJBY4oiPsVJ.CRM9MIUcVH xjSTwPmP1iI3FTYPB5Br533bA9ATqrL8vr.IBrCg_kNYFZsH8IEhcVNpI4lWsfyJ8NqzaFIYM0VU lSAEnzKM5ltdNlrO.nsq_W39mSgCHbFicsI_DMcpF70vcjiCbYIsyQO43gOHaR2beayo5OnQ3pZ_ X1u_K2lpv6JnPCSlWzrXDj18Ajcpth1xf2HjzXaAQa7VhgLu90WHhp8ZiVmrHa_jcHmXeRkWvQM6 YuFE.TXWIndjyMyuyrdaQ6jHOtDSqua5cyE1rgmH2lBVGaZFkMcWMyDvdxVUEJS3mFSSv60QiWIN ihHeKSFxZolp5_yQH5N8w73BKmWsLzFT7nY0mvD.Y8ATV8KqF4I4NWQTSTSPidMx_JXdQOsCjC3_ S_xHUdxcyGpt_i9nfItbMaMzQSFO_gCI0.h05TbnfsjewUZiblGFco1I4bYIybu08OaQGGpXkZp0 4aT8pKkRWXPYIMWJJBQClYWIxtHAhHQBD6KtsMARHc1HkijRCxTxPz_i7uA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Wed, 20 May 2020 00:42:43 +0000 Received: by smtp430.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID be2199faa4f38eae39d64c7a842a761f; Wed, 20 May 2020 00:42:38 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: rpi4 headless experience Message-Id: Date: Tue, 19 May 2020 17:42:37 -0700 To: mack@macktronics.com, freebsd-arm X-Mailer: Apple Mail (2.3608.80.23.2.2) References: X-Rspamd-Queue-Id: 49RYr52KV1z4ST1 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.65.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.65.148:from]; NEURAL_HAM_SHORT(-0.71)[-0.707]; 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:42:46 -0000 Dan Mack mack at macktronics.com wrote on Tue May 19 22:12:47 UTC 2020 : > Thanks for you report info, especially the fact that you are having it see > all your memory. Perhaps this is an issue with different revisions of the > rpi4 ? I have a pre-Nov 2019 rpi4-4GB. The 2 RPi4B's that I have access to are 4 GiByte models and predate Nov-2019 for when they arrived. 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. 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.) One of the RPi4B is currently running head -r360311 : hw.physmem: 4127358976 hw.usermem: 4053913600 hw.realmem: 4148047872 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.) Things like USB not working and the processor clock rate being well below normal for an RPi4B are expected at this stage. > And I can confirm that reboot doesn't work, on my system, it does this: Known at this stage. Same here. > 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... > done > All buffers synced. > lock order reversal: > 1st 0xfffffd00012809f0 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1631 > 2nd 0xfffffd00012f5438 devfs (devfs) @ > /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 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. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)