Date: Sat, 6 Mar 2021 07:46:36 +0100 From: Gordon Bergling <gbe@freebsd.org> To: Emmanuel Vadot <manu@bidouilliste.com> Cc: "freebsd-arm@freebsd.org" <arm@freebsd.org> Subject: Re: RPi4 Status and sysutils/rpi-firmware Message-ID: <YEMlTFSf%2B8cqFa5e@lion.0xfce3.net> In-Reply-To: <20210302122057.86ba62bb1daa7f922134ecd9@bidouilliste.com> References: <20210302122057.86ba62bb1daa7f922134ecd9@bidouilliste.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YEMlTFSf%2B8cqFa5e>