Date: Wed, 24 Nov 2021 12:11:02 -0800 From: Mark Millard via freebsd-arm <freebsd-arm@freebsd.org> To: Juan David Hurtado G <jdhurtado@orbiware.com> Cc: Free BSD <freebsd-arm@freebsd.org>, bob prohaska <fbsd@www.zefox.net> Subject: Re: 13.0-RELEASE Poor performance on Raspberry pi 3 B+ Message-ID: <6CCD061E-DCDA-46E0-AE19-76EA1B30E56F@yahoo.com> In-Reply-To: <20211124155352.GA26072@www.zefox.net> References: <CAL3Ut_bFZhWKThHJsPaa%2BP0JXH6-=e3Pxv3xF3Y0u9dXpQ3kZQ@mail.gmail.com> <CAL3Ut_Y_BLbGM1WZ%2B8JbkSp9F=s9_xcWbFikLpcOufioxd1m_g@mail.gmail.com> <20211124155352.GA26072@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Nov-24, at 07:53, bob prohaska <fbsd at www.zefox.net> wrote: > On Wed, Nov 24, 2021 at 09:33:33AM -0500, Juan David Hurtado G wrote: >> Thanks to @evadot and @f451 on Discord, seems there is the issue: >>=20 >> Raspberry Pi 3B+ >>=20 >> ``` >> root@generic:~ # dmesg | grep -i mmcsd >> mmcsd0: 31GB <SDHC SPCC 2.0 SN 1072013D MFG 08/2017 by 49 SP> at mmc0 >> 0.4MHz/4bit/65535-block >> ``` >>=20 >> Raspberry Pi 4 with a different card: >> ``` >> mmcsd0: 31GB <SDHC 00000 0.0 SN 0000509F MFG 09/2019 by 159 TI> at = mmc1 >> 0.4MHz/4bit/65535-block >> ``` >>=20 >> So no matter the pi or the card, the microsd clock is at 0.4MHz while = in >> raspios same cards gets 50 MHz apparently >>=20 >> Seems that explain the behaviour... So is this a FreeBSD bug? or a = card >> issue even if I've tested with different cards? >>=20 >> PS: A brand new sandisk ultra is on the way so I can test with it. >>=20 >=20 > Very strange. I get >=20 > bob@www:~ % dmesg | grep -i mmcsd > mmcsd0: 64GB <SDHC EC2QT 3.0 SN 5A4667E1 MFG 08/2019 by 27 SM> at mmc0 = 50.0MHz/4bit/65535-block >=20 > on an old Pi2 running > FreeBSD www.zefox.net 12.2-STABLE FreeBSD 12.2-STABLE r370512 GENERIC = arm >=20 > and >=20 > root@pelorus:/home/bob # dmesg | grep -i mmcsd > mmcsd0: 16GB <SDHC SL16G 8.0 SN BAAB3C19 MFG 11/2016 by 3 SD> at mmc0 = 50.0MHz/4bit/65535-block >=20 > on a Pi3 running > FreeBSD pelorus.zefox.org 13.0-RELEASE FreeBSD 13.0-RELEASE #0 = releng/13.0-n244733-ea31abc261f: Fri Apr 9 06:06:55 UTC 2021 = root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC = arm64 >=20 Since an RPi4B was mentioned . . . Booting main: # uname -apKU FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #22 = main-n250972-319e9fc642a1-dirty: Tue Nov 23 12:25:36 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 got: # dmesg | grep -i mmcsd mmcsd0: 31GB <SDHC USD 1.0 SN 01201557 MFG 03/2017 by 116 J`> at mmc1 = 50.0MHz/4bit/65535-block Booting stable/13 (same USB3 SSD boot media, different bectl selection): # uname -apKU FreeBSD CA72_4c8G_ZFS 13.0-STABLE FreeBSD 13.0-STABLE #15 = stable/13-n248179-f4aba8c9f0cb-dirty: Tue Nov 23 11:31:51 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13S-CA72-nodbg-clang/usr/13S-src/arm64.= aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300521 1300521 got: # dmesg | grep -i mmcsd mmcsd0: 31GB <SDHC USD 1.0 SN 01201557 MFG 03/2017 by 116 J`> at mmc1 = 50.0MHz/4bit/65535-block Booting releng/13.0 (same USB3 SSD boot media, different bectl = selection: # uname -apKU FreeBSD CA72_4c8G_ZFS 13.0-RELEASE-p5 FreeBSD 13.0-RELEASE-p5 #2 = releng/13.0-n244765-2646dd665909-dirty: Thu Nov 4 00:19:17 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/ar= m64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300139 1300139 got: # dmesg | grep -i mmcsd mmcsd0: 31GB <SDHC USD 1.0 SN 01201557 MFG 03/2017 by 116 J`> at mmc1 = 50.0MHz/4bit/65535-block I'll note that I've never seen the 0.4MHz problem in the past either. But, the above ignores: What RPi4B firmware vintage was in use? What U-Boot vintage was in use? What FreeBSD loader.efi vintage is n use? ( in the /boot/efi/efi/boot/bootaa64.efi ) Note: in my context I have the msdosfs file system mounted at /boot/efi/ . Your context may be different. For example (in may context, for all 3 FreeBSD variations): # strings /boot/efi/start4.elf | grep VC_BUILD_ID_ VC_BUILD_ID_USER: dom VC_BUILD_ID_TIME: 12:10:40 VC_BUILD_ID_VARIANT: start VC_BUILD_ID_TIME: Feb 25 2021 VC_BUILD_ID_BRANCH: bcm2711_2 VC_BUILD_ID_HOSTNAME: buildbot VC_BUILD_ID_PLATFORM: raspberrypi_linux VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean) # strings /boot/efi/u-boot.bin | grep "U-Boot 2" U-Boot 2021.04 (Apr 08 2021 - 10:46:22 +0000) But I'm not aware of anything good to search for in the copy of loader.efi . I also doubt it is contributing to the specific problem. You may want to report such details for what you have tried. Your various boot media may have distinct versions of one or more of those. There is also the issue of: What specific version/variation of the RPi4B was in use? To my knowledge there is only the original version for 8 GiByte RPi4B's: v1.4 . But that is not true of various other variations. You may want to be explicit about which RPi4B variation(s) and version(s) you are using. This even gets into the labeling on the SOC's top, for example: BROADCOM 2711ZPKFSB06BOT TE1919 045-23 B3 W vs. BROADCOM 2711ZPKFSB06COT TA2105 054-05 B3 W The B vs. C in BOT vs. COT is significant. (I'm not sure of that should be O vs. 0 (zero) in the middle.) As I understand, the vintages for the combination of Firmware/U-Boot that I use would not work for a 2711ZPKFSB06COT context. Other notes: If I boot (via USB3 media) with a microsd card in place that has no firmware, the microsd card is seen and accessible. But card removal and insertion is not recognized, basically limiting me to what was in place at boot time. If I boot with no microsd card in place, card insertion and removal is not recognized: no microsd card access. (Ignore using, say, a USB reader in the above wording.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6CCD061E-DCDA-46E0-AE19-76EA1B30E56F>