Re: Need testers for ALPHA RPi-5 fan control, GE NIC, WiFi drivers for FreeBSD-CURRENT

On 6/4/26 20:56, Mark Millard wrote:
> On 6/4/26 20:12, Mark Millard wrote:
>> On 6/4/26 19:39, Mark Millard wrote:
>>> On 5/29/26 17:42, Jeremy McMillan wrote:
>>>>
>>>>
>>>> If anyone has a Raspberry Pi 5 that's not dedicated to anything
>>>> important, I'd appreciate some help testing this:
>>>>
>>>> https://github.com/aphor/FreeBSD15-RPi5-modules <https://github.com/
>>>> aphor/FreeBSD15-RPi5-modules>
>>>>
>>>> The README.md is up to date, but other docs in there might be stale.
>>>>
>>>> IDK if I should try to implement Bluetooth yet. I haven't tried using
>>>> FreeBSD bluetooth with working known-good drivers on supported hardware,
>>>> but when this is relatively complete I'm planning to do some bug fixing
>>>> and performance improvements where necessary in a BETA phase, then a
>>>> rewrite from scratch for maintainability that can be submitted to
>>>> FreeBSD-CURRENT. I know the repo says FreeBSD15, but I'm currently
>>>> building against FreeBSD-16-CURRENT. I've had feedback that the fan
>>>> control works fine on FreeBSD-15.
>>>>
>>>> I also don't know what I should do about GPIO testing. I'd appreciate
>>>> any pointers if other people work with RPi hardware and have any
>>>> pointers for testing GPIO stuff. I think there's a few pins that can do
>>>> DAC and ADC and others that can do PWM (like the ones used for the fan
>>>> header) when programmed to different modes. I have an oscilloscope, but
>>>> I'd like to automate testing as much as possible because my spare time
>>>> is precious.
>>>>
>>>> It seems like RPi-5 will be around for a while under the current market
>>>> conditions for the semiconductor business, and it is my hope that
>>>> FreeBSD can deserve and get more attention and support from Broadcom and
>>>> Raspberry Pi. Also, I have my own projects :)
>>>>
>>>> Thanks in advance for your attention!
>>>
>>> QUOTE
>>> Add to your FreeBSD device tree (typically at
>>> /usr/src/sys/arm64/broadcom/bcm2712-rpi-5-b.dts):
>>> END QUOTE
>>>
>>> FreeBSD has never used RPi* device trees based on the ones in the
>>> FreeBSD /usr/src/sys/ area (copied from linux mainline): only binary
>>> ones copied directly or indirectly from the RPi* folks (the RPi*
>>> upstream). (The sources are available.) The same is true for what the
>>> two RPi5 EDK2's provide: *.dtb files and *.dtbo files from the RPi*
>>> upstream, both in binary form.
>>>
>>> My limited understanding is that they are (were?) not the same in
>>> various ways --but I do not know the details.
>>>
>>> The modern RPi5 *.dtb files include the RPi* folks RP1 description.
>>> (I have converted the live representation of the time to text in the
>>> past, not that I remember the details.)
>>>
>>> I've no clue what the consequences of mixing such might be or if use of
>>> a device tree overlay might help avoid such questions.
>>>
>>> I'll also note that the RPi* firmware makes some live adjustments to
>>> what is handed to EDK2 and EDK2 may well make more for what is handed to
>>> the FreeBSD EFI loader. Some of that is not from overlays.
>>>
>>> Anyway, I was surprised at the reference to the copy of the linux
>>> upstream *.dts .
>>>
>>
>> I do still have the files from 2025-Nov-04. Looking . . .
>>
>> /  {
>> . . .
>>         __symbols__ {
>> . . .
>>                 pwm = "/axi/pcie@1000120000/rp1/pwm@98000";
>>                 pwm0 = "/axi/pcie@1000120000/rp1/pwm@98000";
>>                 pwm1 = "/axi/pcie@1000120000/rp1/pwm@9c000";
>> . . .
>>                 rp1_pwm0 = "/axi/pcie@1000120000/rp1/pwm@98000";
>>                 rp1_pwm1 = "/axi/pcie@1000120000/rp1/pwm@9c000";
>> . . .
>>         axi {
>> . . .
>>                 pcie@1000120000 {
>>                         rp1 {
>> . . .
>>                                 pwm@98000 {
>>
>>                                         #pwm-cells = <0x3>;
>>                                         assigned-clock-rates = <0x2faf080>;
>>                                         assigned-clocks = <0x2 0x11>;
>>                                         clocks = <0x2 0x11>;
>>                                         compatible = "raspberrypi,rp1-pwm";
>>                                         phandle = <0xb9>;
>>                                         reg = <0xc0 0x40098000 0x0 0x100>;
>>                                         status = "disabled";
>>                                 };
>>                                 pwm@9c000 {
>>
>>                                         #pwm-cells = <0x3>;
>>                                         assigned-clock-rates = <0x2faf080>;
>>                                         assigned-clocks = <0x2 0x12>;
>>                                         clocks = <0x2 0x12>;
>>                                         compatible = "raspberrypi,rp1-pwm";
>>                                         phandle = <0x61>;
>>                                         pinctrl-0 = <0x39>;
>>                                         pinctrl-names = "default";
>>                                         reg = <0xc0 0x4009c000 0x0 0x100>;
>>                                         status = "okay";
>>                                 };
>> . . .
>>         cooling_fan {
>>                 compatible = "pwm-fan";
>>                 pwms = <0x61 0x3 0xa25e 0x1>;
>>         };
> 
> cooling_fan was from a grep output. More complete:
> 
>         cooling_fan {
> 
>                 #cooling-cells = <0x2>;
>                 compatible = "pwm-fan";
>                 cooling-levels = <0x0 0x4b 0x7d 0xaf 0xfa>;
>                 cooling-max-state = <0x3>;
>                 cooling-min-state = <0x0>;
>                 phandle = <0x54>;
>                 pwms = <0x61 0x3 0xa25e 0x1>;
>                 rpm-offset = <0x3c>;
>                 rpm-regmap = <0x61>;
>                 status = "okay";
>         };
> 
>> . . .
>>
>> Now I just have to remember how I generated that file from hw.fdt so I
>> can see what modern looks like.
>>
> 
> And the only differences were (summarized as what had a different value,
> not what the value was, using indentation for nesting):
> 
> memreserve
> choosen
>   bootargs, kaslr-seed, log, rng-seed
>   NEW: rpi-machine-id, rpi-min-boot-ver, rpi-sdram-size-gbit
>   bootloader
>     build-timestamp, count,  update-timestamp, version
>   power
>     NEW: sd_overcurrent
> reserved-memory
>   nvram@0
>     reg
> 
> Nothing else was different.
> 
> 
> The magic command was (given that EDK2 was exporting a DeviceTree as well):
> 
> # sysctl -b hw.fdt.dtb | dtc -I dtb -s > ~/RPi5B-D0-live-newer.dts
> 
> 

I found (from 2026-Mar-20):

<https://github.com/raspberrypi/firmware/issues/2018#issuecomment-4099774849>

that is explicit about the RPi* folks bcm2712d0-rpi-5-b.dts file that
they provided (and the matching *.dtb that they provide):

"The discussion in the PR that added bcm2712d0-rpi-5-b.dts
( https://github.com/raspberrypi/linux/pull/5847 ) shows that it was
really only there as an example for the upstream kernel devs. It's not
been kept in line with the main Pi 5 dts. The upstream D0 support
doesn't have all the tweaks included in the overlay, but it's been
enough for them up to now."

There is also this earlier in exchange:

"The downstream kernel uses a modified bcm2712-rpi-5-b.dts for C0, with
the firmware applying the bcm2712d0 overlay as needed. The upstream
kernels uses bcm2712-rpi-5-b.dts (unmodified) for C0, and bcm2712-d-
rpi-5-b.dts for D0."


-- 
===
Mark Millard
marklmi at yahoo.com