Date: Sat, 7 Jan 2023 12:33:18 -0800 From: Mark Millard <marklmi@yahoo.com> To: =?utf-8?Q?Klaus_K=C3=BCchemann?= <maciphone2@googlemail.com> Cc: freebsd-arm@freebsd.org Subject: Re: How to make FreeBSD's kernel boot a RPi4B with modern RPi* firmware Message-ID: <9E36A955-9B22-4D54-9EEB-B74FCB5B67FB@yahoo.com> In-Reply-To: <7EBF1CB8-F6B9-49D4-897D-5EFAD321341F@googlemail.com> References: <9C037D3F-A440-4708-993D-117F313691BB@yahoo.com> <374EC3E5-4CB4-4336-A8B9-7A9CF6151691@yahoo.com> <BCCBE0D7-8BEB-4D6D-A017-9A59000F1E2B@yahoo.com> <9E9C739E-8308-472A-B797-05A37559DD00@googlemail.com> <EAD84A57-E8F0-4149-BCFC-8A06FF03B11B@yahoo.com> <7EBF1CB8-F6B9-49D4-897D-5EFAD321341F@googlemail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 7, 2023, at 10:07, Klaus K=C3=BCchemann = <maciphone2@googlemail.com> wrote: > Am 07.01.2023 um 11:18 schrieb Mark Millard <marklmi@yahoo.com>: >>=20 >> ...In fact, the modern firmware corrects mistakes in the >> .dtb's relative to the RPi4B PCIe description. =E2=80=A6. >=20 > 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 = =E2=80=9Eblindly=E2=80=9C because if you fix 1 thing by merging the = upstream you=E2=80=99ll 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=20 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=E2=80=A6 > or you would have to test EVERY embedded device and all (perhaps = fixed)bug reports would have been worthless when you import=20 > the next problem=E2=80=A6 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. > =E2=80=A6 but of course: >=20 > If you can fix a relevant issue of an existing driver(like the pcie on = 4b) , please give your device-hack in phabricator review,=20 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 =E2=80=9Enew features=E2=80=9C in = fw-releases which taget linux(or even only raspbian) instead of fbsd=E2=80= =A6 > ..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. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9E36A955-9B22-4D54-9EEB-B74FCB5B67FB>