RPi4 Status and sysutils/rpi-firmware

Sat Mar 6 06:46:38 UTC 2021

On Tue, Mar 02, 2021 at 12:20:57PM +0100, Emmanuel Vadot wrote:
>  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

Hi Emmanuel,

thanks for your work, it is much appreciated.

I personal use the RPi4B 4GB model as arm64 reference for regular tests 
in terms of -CURRENT performance, kyua tests and possible
bugs.

The 4GB model seems to not have such many firmware bugs as the 8GB model,
I never updated the firmware or the u-boot image, but I'll try the patches
to incorporate this into my regular testing.

Thanks for your work on that platform!

--Gordon