Date: Tue, 2 Mar 2021 13:59:38 +0100 From: Michael Tuexen <tuexen@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: <18FFE64D-9FAC-48F3-A73F-8C229838CFA6@freebsd.org> 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 2. Mar 2021, at 12:20, Emmanuel Vadot <manu@bidouilliste.com> = wrote: >=20 >=20 > Hello arm folks, >=20 > 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. >=20 > 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. >=20 > 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. >=20 > It all started with commit r561841 in ports > (https://svnweb.freebsd.org/ports?view=3Drevision&revision=3D561841) = 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=3D1 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. >=20 > 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. >=20 > 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. >=20 > So the status currently is : >=20 > 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-77935532= 0) > 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 >=20 > 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. >=20 > 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. >=20 > The TLDR is:=20 > 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 >=20 > Please keep the discussion sane in this thread too. >=20 > Cheers, >=20 > 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 >=20 > --=20 > Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org> > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?18FFE64D-9FAC-48F3-A73F-8C229838CFA6>