Re: Need testers for ALPHA RPi-5 fan control, GE NIC, WiFi drivers for FreeBSD-CURRENT
Mark Millard <[email protected]> Fri, 5 Jun 2026 14:22:31 -0700
| Newsgroups | gmane.os.freebsd.devel.arm |
|---|---|
| Message-ID | <[email protected]> |
On 6/5/26 12:46, Mark Millard wrote:
> 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 switched to the *.dtb's ( and the *.dtbo ) from the RaspiOS64 (my
abbr.) I used to upgrade the EEPROM contents. It shows a lot more
differences to prior ones that I'd looked at.
I'll note some. The '-' lines are ~/RPi5B-D0-live-newer.dts and the '+'
lines are ~/RPi5B-D0-live-newer2.dts (the most recent). But first, I used:
# diff -u ~/RPi5B-D0-live-newer*.dts \
| grep '^[-+]' \
| grep -v 'phandle = '
which removed the lots of changed phandle value lines.
I did add some blank lines to separate somethings for clarity. I also
added comments of my own, somethings just naming something not detailed.
The first difference is the overall:
- #size-cells = <0x1>;
+ #size-cells = <0x2>;
There are now eee, eth_max_speed, and watchdog in: __overrides__
There is now a watchdog in: __symbols__
- bsc_irq = "/soc@107c000000/intc@7d508380";
+ bsc_irq = "/soc@107c000000/interrupt-controller@7d508380";
(So changes in that naming convention.)
- hdmi0 = "/soc@107c000000/hdmi@7ef00700";
- hdmi1 = "/soc@107c000000/hdmi@7ef05700";
+ hdmi0 = "/soc@107c000000/hdmi@7c701400";
+ hdmi1 = "/soc@107c000000/hdmi@7c706400";
- l2_cache_l0 = "/cpus/cpu@0/l2-cache-l0";
- l2_cache_l1 = "/cpus/cpu@1/l2-cache-l1";
- l2_cache_l2 = "/cpus/cpu@2/l2-cache-l2";
- l2_cache_l3 = "/cpus/cpu@3/l2-cache-l3";
+ l2_cache_l0 = "/cpus/cpu@0/l2-cache";
+ l2_cache_l1 = "/cpus/cpu@1/l2-cache";
+ l2_cache_l2 = "/cpus/cpu@2/l2-cache";
+ l2_cache_l3 = "/cpus/cpu@3/l2-cache";
(So: another naming change.)
- local_intc =
"/soc@107c000000/interrupt-controller@7cd00000";
(So something deleted.)
- main_irq = "/soc@107c000000/intc@7d508400";
+ main_irq = "/soc@107c000000/interrupt-controller@7d508400";
+ watchdog = "/soc@107c000000/watchdog@7d200000";
+ watchdog = "/soc@107c000000/watchdog@7d200000";
The 1st is in: __symbols__
The 2nd is in: aliases
+ aperture-size = <0x1 0x0>;
That new thing is in: iommu@5100
- snps,axi-max-burst-len = <0x4>;
+ snps,axi-max-burst-len = <0x8
0x8 0x4 0x4 0x4 0x4 0x4 0x4>;
+ snps,chan-flags = <0x100 0x100
0x0 0x0 0x0 0x0 0x0 0x0>;
- dmas = <0x2b 0x38 0x2b 0x39 0x2b
0x3a 0x2b 0x3b 0x2b 0x3c 0x2b 0x3d 0x2b 0x3e 0x2b 0x3f>;
+ dmas = <0x2b 0x138 0x2b 0x139
0x2b 0x13a 0x2b 0x13b 0x2b 0x13c 0x2b 0x13d 0x2b 0x13e 0x2b 0x13f>;
bootargs has (old then new):
nvme.max_host_mem_size_mb=0 vs. nvme.max_host_mem_size_mb=32
- l2-cache-l0 {
+ l2-cache {
- l2-cache-l1 {
+ l2-cache {
- l2-cache-l2 {
+ l2-cache {
- l2-cache-l3 {
+ l2-cache {
- reg = <0x10 0x7c580000 0x1a000>;
+ reg = <0x10 0x7c580000 0x0 0x1a000>;
- #size-cells = <0x1>;
+ #size-cells = <0x2>;
- reg = <0x0 0x0 0x80000>;
+ reg = <0x0 0x0 0x0 0x80000>;
- alloc-ranges = <0x0 0x0 0x40000000>;
+ alloc-ranges = <0x0 0x0 0x0 0x40000000>;
- size = <0x4000000>;
+ size = <0x0 0x4000000>;
- reg = <0x0 0x3fd233a0 0x38>;
+ reg = <0x0 0x3fd233a0 0x0 0x38>;
- reg = <0x0 0x0 0x0>;
+ reg = <0x0 0x0 0x0 0x0>;
- hdmi@7ef00700 {
+ hdmi@7c701400 {
- hdmi@7ef05700 {
+ hdmi@7c706400 {
- intc@7d508380 {
-
- #interrupt-cells = <0x1>;
- compatible = "brcm,bcm7271-l2-intc";
- interrupt-controller;
- interrupts = <0x0 0xf2 0x4>;
- reg = <0x7d508380 0x10>;
- };
- intc@7d508400 {
-
- #interrupt-cells = <0x1>;
- compatible = "brcm,bcm7271-l2-intc";
- interrupt-controller;
- interrupts = <0x0 0xf4 0x4>;
- reg = <0x7d508400 0x10>;
- };
- interrupt-controller@7cd00000 {
+ interrupt-controller@7d508380 {
- compatible = "brcm,bcm2836-l1-intc";
- reg = <0x7cd00000 0x100>;
+ #interrupt-cells = <0x1>;
The below starts inside : interrupt-controller@7d508380
+ compatible = "brcm,bcm7271-l2-intc";
+ interrupt-controller;
+ interrupts = <0x0 0xf2 0x4>;
+ reg = <0x7d508380 0x10>;
+ interrupt-controller@7d508400 {
+
+ #interrupt-cells = <0x1>;
+ compatible = "brcm,bcm7271-l2-intc";
+ interrupt-controller;
+ interrupts = <0x0 0xf4 0x4>;
+ reg = <0x7d508400 0x10>;
+ };
+ #address-cells = <0x0>;
The above line was inside: interrupt-controller@7fff9000
The below was inside: serial@7d001000
- compatible = "arm,pl011", "arm,primecell";
+ compatible = "arm,pl011-axi", "arm,pl011",
"arm,primecell";
>>
>>
>
> 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