Re: How to make FreeBSD's kernel boot a RPi4B with modern RPi* firmware
- In reply to: Klaus_Küchemann : "Re: How to make FreeBSD's kernel boot a RPi4B with modern RPi* firmware"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 07 Jan 2023 20:33:18 UTC
On Jan 7, 2023, at 10:07, Klaus Küchemann <maciphone2@googlemail.com> wrote: > Am 07.01.2023 um 11:18 schrieb Mark Millard <marklmi@yahoo.com>: >> >> ...In fact, the modern firmware corrects mistakes in the >> .dtb's relative to the RPi4B PCIe description. …. > > just a short estimation for now... > there is far too much to say and report on the firmware/u-boot and specially its targeting linux kernel, so I'll just refer to your above snippet : > In such cases I presume that hacking the .dts files on a per device basis should do the trick instead of following the upstream „blindly“ because if you fix 1 thing by merging the upstream you’ll perhaps import the next problem from the upstream. I'm not aware that FreeBSD maintains patched or replaced versions of any .dt* source files for any device (beyond being able to identify that it is from files that FreeBSD imported). Everything is from an upstream, as far as I know. As far as I know, all such are designed for some linux kernel, mostly for mainline. The RPi* .dtb's used used as binary files may be the only non-mainline examples. > There were cases when even OLDER firmware was better than new versions, That probably happens more for the RPi*'s than most others but may not be unique to RPI*'s. There are also examples of importing mainline .dt*'s that lead to FreeBSD failures for non-RPi*'s. I've had examples of such (Rock64 and OrangePi+2ed in more modern times). But it normally means a later adjustment of the FreeBSD kernel to support the updated Device Tree established upstream. In all my examples, eventually FreeBSD started working again after the kernel was updated to track the upstream .dt* changes. FreeBSD depends on folks using devices to report when the *.dt* source updates break things for some device(s). There is no general up front work to make sure all the updated *.dt*'s work with the FreeBSD kernel that used to work before the update. > so I would always focus on working fbsd(img.xz) releases on a per device basis… > or you would have to test EVERY embedded device and all (perhaps fixed)bug reports would have been worthless when you import > the next problem… also you will not want confusing dmesg`s filled up with messages of linux featured drivers which do not exist in FreeBSD Avoiding a crash for a valid Device Tree (even if not otherwise supported) is not the same as choosing to use the Device Tree that otherwise gets the crash. One can still use the historical one. > … but of course: > > If you can fix a relevant issue of an existing driver(like the pcie on 4b) , please give your device-hack in phabricator review, If I end up concluding that the patching is safe enough to submit, I'd not propose any change to the RPi* firmware version that FreeBSD uses. I have to use more recent firmware to test the patch is doing as intended. That is not the same as saying FreeBSD should change the RPi* firmware version it uses. I view the patching as fixing an example kernel defect of incorrect general structure for handling of a Device Tree resource initialization. (It is normal for various Device Tree resources to need to be initialized early for other Device Tree content to put to use as far as I can tell.) The older Device Trees happen to accidentally have a non-required ordering that happened to accidentally initialize bcm_dma first. In other words, I do not consider the patching a hack, even if someone ends up pointing to something I could have done better than the patching I'm testing. > but also please be warned of „new features“ in fw-releases which taget linux(or even only raspbian) instead of fbsd… > ..just my few cents.. Again, I've not proposed updating the RPi* firmware vintage that FreeBSD uses. I may propose the kernel change to avoid the bcm_dma related crash when anyone happens to try newer RPi* firmware for any reason. === Mark Millard marklmi at yahoo.com