RPi4B 2711ZPKFSB06C0T parts seen in the wild, 13.0-RELEASE fails to boot on them

[Mark Millard via freebsd-arm]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255080

comment #5 reports a comparison/contrast of 4 GiByte
RPi4B's with:

BROADCOM
2711ZPKFSB06BOT
TE1919
045-23 B3 W

vs.

BROADCOM
2711ZPKFSB06C0T
TA2105
054-05 B3 W

The C0T one does not boot for 13.0-RELEASE's image
the older B0T one does.

The C0T RPi4B should be able to DMA outside
the 3 GiByte limit that the B0T ones had: no more
limit. The RPi firmware may configure the C0T parts
differently and FreeBSD might have changes
required if it is to work with the newer parts.

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

[tech-lists]

Post by Mark Millard via freebsd-arm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255080
comment #5 reports a comparison/contrast of 4 GiByte
BROADCOM
2711ZPKFSB06BOT
TE1919
045-23 B3 W

Is there a way, on both linux and freebsd, of reading this information
other than looking at the writing on the chip directly?

thanks,

[Mark Millard via freebsd-arm]

Post by tech-lists

Post by Mark Millard via freebsd-arm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255080
comment #5 reports a comparison/contrast of 4 GiByte
BROADCOM
2711ZPKFSB06BOT
TE1919
045-23 B3 W

Is there a way, on both linux and freebsd, of reading this information
other than looking at the writing on the chip directly?

I've never noticed a reference to a way to do that directly.
In some cases you can infer from the RPi revision code's
"TTTTTTTT Type" field that it should have C0T (or later?)
parts: The 14: CM4 and 13: 400. But, for this new example,
the type field is far from sufficient and we can not be
sure that even the whole revision code would be sufficient.
Some B0T parts might have a b03114 revision code for all
I know.

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

[Denis Ovsienko]

Post by Mark Millard via freebsd-arm
The C0T RPi4B should be able to DMA outside
the 3 GiByte limit that the B0T ones had: no more
limit. The RPi firmware may configure the C0T parts
differently and FreeBSD might have changes
required if it is to work with the newer parts.

As far as these commends make sense to me, the foundation has started
shipping RPI4B revision 1.5, but forgot to bump the revision number up
and to update
https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md

If that's the case, it might be better to solve the problem at the
source rather than at run time. It may be more effective to raise this
through the shop, as the foundation does not seem to have a bug tracker.

[Mark Millard via freebsd-arm]

Post by Denis Ovsienko

Post by Mark Millard via freebsd-arm
The C0T RPi4B should be able to DMA outside
the 3 GiByte limit that the B0T ones had: no more
limit. The RPi firmware may configure the C0T parts
differently and FreeBSD might have changes
required if it is to work with the newer parts.

As far as these commends make sense to me, the foundation has started
shipping RPI4B revision 1.5,

The 2711ZPKFSB06C0T RPi4B was reported to indicate
revision code b03114 for itself (via attachment
content), which that README.md lists as v1.4:

b03114 4B 1.4 2GB Sony UK

(The ending hexadecimal digit indicates what
goes after "1." for "new-style revision codes".)

But it turns out that the above line was added to
the table in the same commit as the line:

c03130 Pi 400 1.0 4GB Sony UK

which is a known 2711ZPKFSB06C0T context. The commit
was back in 2020-Nov. For all I know there may be
b03114's that show a B0T suffix. The shared commit
may be a red herring.

This makes it still unclear if there will be distinct
revision codes in general.

Post by Denis Ovsienko
but forgot to bump the revision number up
and to update

It is a possibility but not a certainty.

Post by Denis Ovsienko
https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md
If that's the case, it might be better to solve the problem at the
source rather than at run time. It may be more effective to raise this
through the shop, as the foundation does not seem to have a bug tracker.

An interesting point about b03114 being a 2GB
model's revision code is that the DMA limitation
is basically irrelevant since there is < 3 GiByte
of RAM to start with. Fixing the DMA limitation
would not have been the point of having a
2711ZPKFSB06C0T part in this type of context.


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

[Denis Ovsienko]

On Sun, 18 Apr 2021 13:38:07 -0700

Post by Mark Millard via freebsd-arm
b03114 4B 1.4 2GB Sony UK

If it helps, I have one RPI4B that reports itself as the above (2GB),
and another as d03114 (8GB). Both boot FreeBSD 13.0 from an SD card
fine. It is too late to confirm the labelling as the chips are under
heatsinks, but if anybody needs any debug information from a known-good
b03114, let me know.

[Mark Millard via freebsd-arm]

Post by Denis Ovsienko
On Sun, 18 Apr 2021 13:38:07 -0700

Post by Mark Millard via freebsd-arm
b03114 4B 1.4 2GB Sony UK

If it helps, I have one RPI4B that reports itself as the above (2GB),
and another as d03114 (8GB). Both boot FreeBSD 13.0 from an SD card
fine. It is too late to confirm the labelling as the chips are under
heatsinks, but if anybody needs any debug information from a known-good
b03114, let me know.

That does suggest 3 possibiliites:

A) Differing EEPROM content versions
B) Differing board/CPU revisions
C) A combination of both

(A) would definitely not lead to b03114 changing.

So I propose another test under RaspiOS or RaspiOS64:

# vcgencmd bootloader_config
and/or:
# rpi-eeprom-config


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

[Denis Ovsienko]

On Sun, 18 Apr 2021 16:12:35 -0700

Post by Mark Millard via freebsd-arm
# vcgencmd bootloader_config
# rpi-eeprom-config

This is RPI b03114 that can boot and run FreeBSD 13.0 (and OpenBSD 6.8),
booted into the latest 32-bit Raspbian:

***@raspberrypi:~# grep -E '^[^#]' /boot/config.txt
dtparam=i2c_arm=on
dtparam=audio=on
[pi4]
dtoverlay=vc4-fkms-v3d
max_framebuffers=2
[all]
gpu_mem=16

***@raspberrypi:~# vcgencmd bootloader_config
[all]
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
ENABLE_SELF_UPDATE=1
DISABLE_HDMI=0
BOOT_ORDER=0xf41

***@raspberrypi:~# rpi-eeprom-config
[all]
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
ENABLE_SELF_UPDATE=1
DISABLE_HDMI=0
BOOT_ORDER=0xf41

***@raspberrypi:~# rpi-eeprom-update
BOOTLOADER: up-to-date
CURRENT: Thu 3 Sep 12:11:43 UTC 2020 (1599135103)
LATEST: Thu 3 Sep 12:11:43 UTC 2020 (1599135103)
RELEASE: default (/lib/firmware/raspberrypi/bootloader/default)
Use raspi-config to change the release.

VL805_FW: Using bootloader EEPROM
VL805: up-to-date
CURRENT: 000138a1
LATEST: 000138a1

***@raspberrypi:~# lspci
00:00.0 PCI bridge: Broadcom Limited Device 2711 (rev 10)
01:00.0 USB controller: VIA Technologies, Inc. VL805 USB 3.0 Host
Controller (rev 01)

***@raspberrypi:~# lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub