From owner-freebsd-arm@freebsd.org Wed May 20 02:52:58 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 48A3D2FCC5F for ; Wed, 20 May 2020 02:52:58 +0000 (UTC) (envelope-from mack@macktronics.com) Received: from mail.macktronics.com (coco.macktronics.com [209.181.253.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49RckK2FmBz4Z81 for ; Wed, 20 May 2020 02:52:56 +0000 (UTC) (envelope-from mack@macktronics.com) Received: from olive.macktronics.com (unknown [209.181.253.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.macktronics.com (Postfix) with ESMTPS id A9DD4AEF; Tue, 19 May 2020 21:52:55 -0500 (CDT) Date: Tue, 19 May 2020 21:52:55 -0500 (CDT) From: Dan Mack X-X-Sender: mack@localhost.local To: Mark Millard cc: freebsd-arm Subject: Re: rpi4 headless experience In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (GSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Rspamd-Queue-Id: 49RckK2FmBz4Z81 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=macktronics.com; spf=pass (mx1.freebsd.org: domain of mack@macktronics.com designates 209.181.253.65 as permitted sender) smtp.mailfrom=mack@macktronics.com X-Spamd-Result: default: False [-1.76 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.62)[-0.622]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.181.253.64/29]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.34)[-0.336]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[macktronics.com,none]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:209, ipnet:209.181.252.0/23, country:US]; RCVD_COUNT_TWO(0.00)[2]; 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, 20 May 2020 02:52:58 -0000 Thanks for that info - this is my first foray into fbsd on arm so I might be messing something up. As a test I swapped in an alpine linux sdcard and booted the same rpi4-4 and this is what it reports for cpu and memory. What the heck am I doing wrong? :-) # alpine Booting Linux on physical CPU 0x0000000000 [0x410fd083] Linux version 5.4.12-0-rpi4 (buildozer@build-3-11-aarch64) version 9.2.0 (Alpine 9.2.0)) #1-Alpine SMP PREEMPT Thu Jan 16 Machine model: Raspberry Pi 4 Model B Rev 1.1 pi4f:~# cat /proc/cpuinfo processor : 0 BogoMIPS : 108.00 Features : fp asimd evtstrm crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3 processor : 1 BogoMIPS : 108.00 Features : fp asimd evtstrm crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3 processor : 2 BogoMIPS : 108.00 Features : fp asimd evtstrm crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3 processor : 3 BogoMIPS : 108.00 Features : fp asimd evtstrm crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3 Hardware : BCM2835 Revision : c03111 Serial : 100000002b2bb8fd Model : Raspberry Pi 4 Model B Rev 1.1 pi4f:~# cat /proc/meminfo MemTotal: 3890684 kB MemFree: 3739844 kB Since others are not seeing the memory discrepency, more investigation is warranted on my end. Take care. Dan On Tue, 19 May 2020, Mark Millard wrote: > 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) > >