Re: fdt based rework Re: Raspbery Pi support (release notes/wiki page) update?

On Feb 9, 2025, at 13:40, Klaus Küchemann <maciphone2@googlemail.com> wrote:

> As you saw, the rp1 driver is compiled into the specific U-Boot version that I used and the devicetree is handed over to the fbsd-kernel...

My curiosity about the live Device Tree content and differences
across board variations or across kernel updates is not dependent
on if FreeBSD ever supports the RPi5 --or even if anyone tries to
provide such support. It is also not dependent on if there is ever
a rp1 driver.

I do not expect satisfying my curiosity would help anyone enable
RPi5 support by FreeBSD. (But I'd not object if it accidentally
did so somehow.)

The ability for me to satisfy my curiosity is more dependent on
what U-Boot has working for the RPi5, such that things at least
complete the "Using DTB provided by EFI at " message and allow
a restart without cutting power. In my context, that likely
means not requiring a network based boot process as well. But a
microsd card boot process that managed to output the "Using DTB
provided by EFI at " message would likely work just fine.

I'm monitoring to see if things start to look like they happen to
allow me to satisfy my curiosity on the issue, not expecting that
to mean anything for future FreeBSD RPi5 support.

> Or let's say: a hacked u-boot could currently be considered operational (except currently USB)...

For my point of curiosity, a hacked U-Boot would be sufficient
to get the information in a useful form, even if that was not
point of the U-Boot but just an accidental status that I could
then put to use once I had a copy.

> 
> but of course freebsd is not ready for use yet...

I already reliably use FreeBSD on the RPi5 that I have access
to --and have been doing since 2024-Mar-15 or so (RPi5-uefi
v0.3's release). No need of U-Boot for my existing, limited,
old-vintage context. The frozen status of RPi5-uefi does not
change that status for my context.

I'm not likely to end up with access to any more modern
RPi5 variant for the indefinite future.

> I'm afraid we need an rp1.c driver...
> The original is available here:
> https://github.com/raspberrypi/linux/blob/rpi-6.6.y/drivers/mfd/rp1.c
> 
> 
> but as long as no fbsd developer comes forward who wants/can work on it, we don't need to talk about it any further or we have to do it ourselves.. but huh, not that easy and not for everyone

I've generally tried to stick to my point of curiosity and to not
talk about the rp1 or its driver. I'm no where close to having the
background knowledge to deal with such things in any sort of
reasonable time frame: a huge learning curve.

It is true that my area of curiosity once lead to the discovery
of why the FreeBSD kernel used to panic for what was
then-more-recent RPi* firmware and the related *.dtb files:

QUOTE
The sdhci_bcm driver attach routine relies on bcm_dma already
being attached, in order to allocate a DMA channel. However,
both drivers attached at the default pass so this is not
guaranteed. Newer RPI firmware exposes this assumption, and the
result is a NULL-dereference in bcm_dma_allocate().
END QUOTE

So I had identified the "NULL-dereference in bcm_dma_allocate()"
at a given point and its being tied to the ordering of things in the
live Device Tree the kernel was given.

But it took months before I finally reached an identification of
the general structure for the correct type of fix in the FreeBSD
kernel's source code. What was actually committed was a variation
of my initial changes that used different parameter values for
controlling the detailed staging of of an activity. The result
was:

-DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0);
+EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0,
+ BUS_PASS_SUPPORTDEV + BUS_PASS_ORDER_MIDDLE);

Ignoring the parameter values involved: Just the structure of
that type of change took me months to identify, given that I'd
already identified the NULL-dereference was due to the ordering
of the live Device Tree's content.

> Regards
> 
> K.
> 
>> Am 09.02.2025 um 18:18 schrieb Mark Millard <marklmi@yahoo.com>:
>> …
>> ..
>> 
>> FYI: The U-Boot fdt print output is sufficient to essentially
>> reproduce the live DTB with: It is a complete source and has
>> vastly bigger output to capture. With a dtc that follows the
>> same conventions, it can be compiled to produce such a .dtb
>> file.
>> …..




===
Mark Millard
marklmi at yahoo.com