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

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!

https://github.com/aphor/FreeBSD15-RPi5-modules/blob/main/README.md uses
the terminology:

hw.rpi5.fan.temp0: Level 1 trigger threshold (milli-°C ...)

hw.rpi5.fan.temp1: Level 2 trigger threshold

hw.rpi5.fan.temp2: Level 3 trigger threshold

hw.rpi5.fan.temp3: Level 4 trigger threshold


What I found was:

 # sysctl hw.rpi5
hw.rpi5.fan.rpm: 0
hw.rpi5.fan.current_state: 0
hw.rpi5.fan.cpu_temp: 47400
hw.rpi5.fan.speed3: 255
hw.rpi5.fan.speed2: 255
hw.rpi5.fan.speed1: 255
hw.rpi5.fan.speed0: 0
hw.rpi5.fan.temp3_hyst: 5000
hw.rpi5.fan.temp2_hyst: 5000
hw.rpi5.fan.temp1_hyst: 5000
hw.rpi5.fan.temp0_hyst: 5000
hw.rpi5.fan.temp3: 75000
hw.rpi5.fan.temp2: 67500
hw.rpi5.fan.temp1: 60000
hw.rpi5.fan.temp0: 50000

(I've not tested for temp0..temp3 not being in increasing order: only
increasing order. But I do not know the general intent, just likely the
normal-use expectation.)

So: hw.rpi5.fan.cpu_temp < hw.rpi5.fan.temp0 leads to use of
hw.rpi5.fan.speed0

(Equality is difficult to test for, so may be that should be <=.)


And:


# sysctl hw.rpi5
hw.rpi5.fan.rpm: 9661
hw.rpi5.fan.current_state: 1
hw.rpi5.fan.cpu_temp: 46300
hw.rpi5.fan.speed3: 255
hw.rpi5.fan.speed2: 255
hw.rpi5.fan.speed1: 255
hw.rpi5.fan.speed0: 255
hw.rpi5.fan.temp3_hyst: 5000
hw.rpi5.fan.temp2_hyst: 5000
hw.rpi5.fan.temp1_hyst: 5000
hw.rpi5.fan.temp0_hyst: 5000
hw.rpi5.fan.temp3: 75000
hw.rpi5.fan.temp2: 67500
hw.rpi5.fan.temp1: 60000
hw.rpi5.fan.temp0: 0

So: hw.rpi5.fan.temp0 < hw.rpi5.fan.cpu_temp < hw.rpi5.fan.temp1
(mathematics style interpretation of being in the range) leads to use of
hw.rpi5.fan.speed1

(Again, equality is not clear via being hard to test for.)

That would suggest that:

hw.rpi5.fan.temp2 < hw.rpi5.fan.cpu_temp < hw.rpi5.fan.temp3 would lead
to use of  hw.rpi5.fan.speed3


A problem? . . .

What about hw.rpi5.fan.temp3 < hw.rpi5.fan.cpu_temp ? There is no
hw.rpi5.fan.speed4 for it to use. But:

# sysctl hw.rpi5
hw.rpi5.fan.rpm: 0
hw.rpi5.fan.current_state: 4
hw.rpi5.fan.cpu_temp: 65550
hw.rpi5.fan.speed3: 0
hw.rpi5.fan.speed2: 0
hw.rpi5.fan.speed1: 0
hw.rpi5.fan.speed0: 0
hw.rpi5.fan.temp3_hyst: 5000
hw.rpi5.fan.temp2_hyst: 5000
hw.rpi5.fan.temp1_hyst: 5000
hw.rpi5.fan.temp0_hyst: 5000
hw.rpi5.fan.temp3: 60000
hw.rpi5.fan.temp2: 52000
hw.rpi5.fan.temp1: 51000
hw.rpi5.fan.temp0: 50000

So it reports that there are states: 0, 1, 2, 3, and 4 but gives no
explicit control over the speed for state 4.

That wording takes things as reported by the code. It might not be
following the actual intent does not involve a state 4.

Given (an arbitrary, general illustration):

0 as a fixed  low bound, likely implicit.
MAXT (say) as a fixed high bound greater than 60000,
also implicit:
(illustrated for an unsigned context)

    0 .. 19999 : hw.rpi5.fan.speed0
20000 .. 39999 : hw.rpi5.fan.speed1
40000 .. 59999 : hw.rpi5.fan.speed2
60000 .. MAXT  : hw.rpi5.fan.speed3

It only takes the 3 explicit values: 20000, 40000, 60000 (or whatever
values) to identify up to 4 speeds, 0 and MAXT not being needed inputs.


FYI: the maximum temperature that I observed with the fan disabled (rpm
always zero) was (so far):

# sysctl hw.rpi5.fan.cpu_temp
hw.rpi5.fan.cpu_temp: 85900

Once observed with that, it also got down to: 82600

The test was letting openssl speed run.


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