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

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


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