Raspberry Pi 3B Distorted U-boot Display

From: Archimedes Gaviola <archimedes.gaviola_at_gmail.com>
Date: Sat, 26 Feb 2022 03:49:54 UTC
Hi,

I've installed FreeBSD 13.0-RELEASE and 14.0-CURRENT successfully with
Raspberry Pi 3B. However, upon U-boot initialization stage the monitor
display is distorted as you can see here
https://pasteboard.co/hxDjJHwxXPc8.jpg but when the FreeBSD kernel is
loaded it displays normal as you can see here
https://pasteboard.co/EkgcZdQSxjtA.jpg. I am thinking of lowering the
resolution so I tried changing the HDMI configuration settings in the
config.txt but it cannot be changed, it has no effect. It always stays on
the default 1366x768 as what dmesg has detected. This behavior is also
observed in 14.0-CURRENT.

FreeBSD 13.0-RELEASE #0: Sat Feb 19 14:09:03 PST 2022
    root@fbsd13:/usr/src/sys/arm64/compile/GENERIC arm64
FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git
llvmorg-11.0.1-0-g43ff75f2c3fe)
VT(efifb): resolution 1366x768
...
fb0: <BCM2835 VT framebuffer driver> on simplebus0
fb0: keeping existing fb bpp of 32
fbd0 on fb0
WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD 14.0.
VT: Replacing driver "efifb" with new "fb".
fb0: 1366x768(1366x768@0,0) 32bpp
fb0: fbswap: 1, pitch 5504, base 0x3e7f2000, screen_size 4227072

freebsd@fbsd13:~ % cat /boot/msdos/config.txt
[all]
arm_64bit=1
dtparam=audio=on,i2c_arm=on,spi=on
dtoverlay=ds3231
dtoverlay=mmc
dtoverlay=disable-bt
device_tree_address=0x4000
kernel=u-boot.bin
enable_uart=1

[pi4]
hdmi_group=2
hdmi_mode=11
armstub=armstub8-gic.bin

freebsd@fbsd13:~ % grep -r "1366x768" /boot/msdos/
Binary file /boot/msdos/start_cd.elf matches
Binary file /boot/msdos/start_db.elf matches
Binary file /boot/msdos/start_x.elf matches
Binary file /boot/msdos/start.elf matches
Binary file /boot/msdos/start4.elf matches
Binary file /boot/msdos/start4cd.elf matches
Binary file /boot/msdos/start4db.elf matches
Binary file /boot/msdos/start4x.elf matches

Using the same images with 13.0-RELEASE and 14.0-CURRENT this issue does
not occur in RPi 4B. Anyone encountered this issue? I confirmed this as
well with another new RPi 3B hardware and it behaves the same. Please see
attached dmesg log output for reference.

Thanks,
Archimedes