Re: 13.0-RELEASE Poor performance on Raspberry pi 3 B+

Reply: Juan David Hurtado G : "Re: 13.0-RELEASE Poor performance on Raspberry pi 3 B+"
In reply to: bob prohaska : "Re: 13.0-RELEASE Poor performance on Raspberry pi 3 B+"
Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: Mark Millard via freebsd-arm <freebsd-arm_at_freebsd.org>
Date: Wed, 24 Nov 2021 20:11:02 UTC
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:
>> 
>> Raspberry Pi 3B+
>> 
>> ```
>> 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
>> ```
>> 
>> 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
>> ```
>> 
>> So no matter the pi or the card, the microsd clock is at 0.4MHz while in
>> raspios same cards gets 50 MHz apparently
>> 
>> Seems that explain the behaviour... So is this a FreeBSD bug? or a card
>> issue even if I've tested with different cards?
>> 
>> PS: A brand new sandisk ultra is on the way so I can test with it.
>> 
> 
> Very strange. I get
> 
> 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
> 
> on an old Pi2 running
> FreeBSD www.zefox.net 12.2-STABLE FreeBSD 12.2-STABLE r370512 GENERIC  arm
> 
> and
> 
> 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
> 
> 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
> 

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/arm64.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/arm64.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.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)