RPi4 Status and sysutils/rpi-firmware

Tue Mar 2 12:59:43 UTC 2021

> On 2. Mar 2021, at 12:20, Emmanuel Vadot <manu at bidouilliste.com> 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.
Thank you very much for the work you did!

Best regards
Michael
> 
> 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>
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"