RPi4 Status and sysutils/rpi-firmware

Tue Mar 2 11:21:10 UTC 2021

 Hello arm folks,

 Over the past years I've handled the update of the
sysutils/rpi-firmware and sysutils/u-boot-rpi* ports.
 For that I've bought a lot of different RPI to ensure that we could
boot on all different models that the RPI Foundation folks deliver to
us.
 A lot of users (and some FreeBSD devs) seems to be interested in
FreeBSD for the RPI4 and I can understand that. It's relatively cheap
and somewhat powerful (at least the RPI4) compared to other SBC
available on the market.

 FreeBSD support-wise our RPI support is pretty low. The last big
commit in term of functionality was from Mike Karels who added the
genet driver (imported from NetBSD) which handle the ethernet
controller on the RPI4 SoC and the PCI-e patches from Robert Crowston
which allow us to have working xhci as the usb controller is on the
PCI-e bus on the RPI4 Model B.

 But the updates of the firmware files have been a big problems over
the last few months, every update that I've done to fix one issue seems
to have created another one.

 It all started with commit r561841 in ports
(https://svnweb.freebsd.org/ports?view=revision&revision=561841) which
was needed for me to boot on my RPI4-8GB board (the only RPI4 board
that I have). This seems to cause a issue when booting without an hdmi
screen connected. It was also found that the previous firmware from 1st
of december has the opposite problem, you could only boot without an
hdmi screen connected.
 As a workaround I added hdmi_safe=1 in the config.txt that we ship for
RPI4 image, that make the firmware not read edid from the screen and
init the hdmi controller with a basic mode.

 It also caused the cpufreq driver not working and the root cause was
that the firmware node compatible in the device tree changed and we
needed to adapt our code for it, which was done in commit
1cf282363101f.

 Another problem that this update caused is that usb stopped working.
 This was also found by the edk2 rpi guys and they reported it
upstream : https://github.com/raspberrypi/firmware/issues/1518
 Upstream proposed a fix and offered two files to make sure that the
bug was not present anymore in people setup, start4.elf and fixup4.dat.
It indeed fixed the issue for me and edk2, all good.
 But what have been commited in the rpi-firmware repo seems to be
different and caused more breakage.

 So the status currently is :

1/ Take the latest BETA4 image for RPI and burn on your sdcard
2/ Boot with or without hdmi screen.
3/ You will see that u-boot fails to init usb :
starting USB...
Bus xhci_pci: probe failed, error -110
No working controllers found
 If you drop to u-boot prompt and do 'usb list' it will say that the
usb system is stopped and you can of course not start it without having
the above error.
 4/ If you boot to FreeBSD everything that we support seems to work
except for usb (of course).
 5/ Take the two files proposed as a fix from upstream
(https://github.com/raspberrypi/firmware/issues/1518#issuecomment-779355320)
and copy them to the sdcard.
 6/ Boot that and you will see that usb is working again in u-boot and
in FreeBSD, perfect.
 7/ Update the ports using [1] or download the files from
github.com/raspberrypi/firmware and copy them on the sdcard (The issue
should be fixed right ?)
 8/ Boot that and now you find that u-boot is failing in its synchronous
abort handler.
 9/ Ok, maybe updating u-boot to the latest version will fix that,
apply patch from [2] or used the compiled file from [3].
 10/ And this isn't fixed

 There is probably a new or different node in the dtb that causes that
and usually I look at what the problem is and fix it, but now I'm tired
of doing that. Updating rpi is too much time consuming for me,
especially since I don't really care or like to work on this platform.

 So, if you care about RPI support I invite you to look at this issue
and the next ones caused by firmware update.
 The maintainer of the port is uboot at f.o and I don't think that should
change. If you think that we should go back to an earlier version of
the firmware port (even if that cause my RPI4 to not boot) that's fine
with me, I don't think I will ever boot again an RPI board.
 If you're not a commiter and you have patches for
sysutils/rpi-firmware I'll happily commit them if they look sane.
 If you think that using our own DTBs or using the ones used in
mainline linux (available in sys/contrib/device-tree) think again of
what you're implying. We choose some time ago to use the "official" one
used by rpi-foundation so people could use the overlays also shipped by
them. That means that a user could simply follow a blog post on how to
activate something on the board using rpios and that will work for us
too (if we have a driver for the hardware of course). Maybe this was a
bad choice and we should follow linux mainline dts but this will
require some audit of all sys/arm/broadcom to be sure that we have
every compatible in the drivers and make sure that the node aren't
different so we process them correctly. Again, if you have patches that
look sane, I'll happily review and commit them.

 The TLDR is: 
 I won't do anything anymore on the rpi-firmware port and we need a
maintainer for this platform.

 Please keep the discussion sane in this thread too.

 Cheers,

Links :
1. https://people.freebsd.org/~manu/rpi-firmware-20210222.patch
2. https://people.freebsd.org/~manu/u-boot-rpi-arm64-2021.01.patch
3. https://people.freebsd.org/~manu/u-boot-rpi-arm64-2021.01.bin

-- 
Emmanuel Vadot <manu at bidouilliste.com> <manu at freebsd.org>