Re: How to make FreeBSD's kernel boot a RPi4B with modern RPi* firmware

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