Date: Tue, 2 Mar 2021 12:20:57 +0100 From: Emmanuel Vadot <manu@bidouilliste.com> To: "freebsd-arm@freebsd.org" <arm@freebsd.org> Subject: RPi4 Status and sysutils/rpi-firmware Message-ID: <20210302122057.86ba62bb1daa7f922134ecd9@bidouilliste.com>
index | next in thread | raw e-mail
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@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@bidouilliste.com> <manu@freebsd.org>home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20210302122057.86ba62bb1daa7f922134ecd9>