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

On 6/15/26 20:58, Mark Millard wrote:
> On 6/15/26 20:36, 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!
>>
>> 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.
>>
>>
> 
> I thought to try setting hw.rpi5.fan.speed3=255 despite
> hw.rpi5.fan.current_state: 4 and . . .
> 
> # sysctl hw.rpi5
> hw.rpi5.fan.rpm: 9746
> hw.rpi5.fan.current_state: 4
> hw.rpi5.fan.cpu_temp: 80950
> hw.rpi5.fan.speed3: 255
> 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
> 
> It looks like:
> 
> hw.rpi5.fan.temp2 < hw.rpi5.fan.cpu_temp selects hw.rpi5.fan.speed3 even
> when hw.rpi5.fan.temp3 < hw.rpi5.fan.cpu_temp
> 
> It may be that hw.rpi5.fan.temp3 is ignored (at least when they are in
> increasing order).
> 
> Later it cooled down more and was:
> 
> # sysctl hw.rpi5
> hw.rpi5.fan.rpm: 9920
> hw.rpi5.fan.current_state: 3
> hw.rpi5.fan.cpu_temp: 55650
> hw.rpi5.fan.speed3: 255
> 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
> 
> 

I found an explicit description of the normal intent with the default
values:

https://www.raspberrypi.com/documentation/computers/raspberry-pi.html

says:

QUOTE
As the temperature of the Raspberry Pi 5 increases, the fan reacts in
the following way:

below 50°C, the fan does not spin at all (0% speed)

at 50°C, the fan turns on at a low speed (30% speed)

at 60°C, the fan speed increases to a medium speed (50% speed)

at 67.5°C, the fan speed increases to a high speed (70% speed)

at 75°C the fan increases to full speed (100% speed)

Temperature decreases use the same mapping with a 5°C hysteresis; fan
speed decreases when the temperature drops to 5°C below each of the
above thresholds.
END QUOTE

(I've made the assumption that decreasing keeps the equality in the same
place.)

Note that there are 5 speeds and 4 boundaries for increasing
temperatures. Also note the < vs. <= status, but listed with the FreeBSD
notation for the increasing temperature case (hysteresis for decreasing
not involved):

hw.rpi5.fan.cpu_temp < hw.rpi5.fan.temp0 :
0 RPM always, RPM not under user control

hw.rpi5.fan.temp0 <= hw.rpi5.fan.cpu_temp < hw.rpi5.fan.temp1:
w.rpi5.fan.speed0

hw.rpi5.fan.temp1 <= hw.rpi5.fan.cpu_temp < hw.rpi5.fan.temp2:
w.rpi5.fan.speed1

hw.rpi5.fan.temp2 <= hw.rpi5.fan.cpu_temp < hw.rpi5.fan.temp3:
w.rpi5.fan.speed2

hw.rpi5.fan.temp3 <= hw.rpi5.fan.cpu_temp:
w.rpi5.fan.speed3

For decreasing temperature:

hw.rpi5.fan.cpu_temp < hw.rpi5.fan.temp0 - hw.rpi5.fan.temp0_hyst:
0 RPM always, RPM not under direct user control

hw.rpi5.fan.temp0 - hw.rpi5.fan.temp0_hyst <= hw.rpi5.fan.cpu_temp
                           < hw.rpi5.fan.temp1 - hw.rpi5.fan.temp1_hyst:
w.rpi5.fan.speed0

hw.rpi5.fan.temp1 - hw.rpi5.fan.temp1_hyst <= hw.rpi5.fan.cpu_temp
                           < hw.rpi5.fan.temp2 - hw.rpi5.fan.temp2_hyst:
w.rpi5.fan.speed1

hw.rpi5.fan.temp2 - hw.rpi5.fan.temp2_hyst <= hw.rpi5.fan.cpu_temp
                           < hw.rpi5.fan.temp3 - hw.rpi5.fan.temp3_hyst:
w.rpi5.fan.speed2

hw.rpi5.fan.temp3 - hw.rpi5.fan.temp3_hyst <= hw.rpi5.fan.cpu_temp:
w.rpi5.fan.speed3

As I understand the wording, that is what corresponds.

It is not what the existing fan control does:

# sysctl hw.rpi5
hw.rpi5.fan.rpm: 3313
hw.rpi5.fan.current_state: 0
hw.rpi5.fan.cpu_temp: 58950
hw.rpi5.fan.speed3: 250
hw.rpi5.fan.speed2: 175
hw.rpi5.fan.speed1: 125
hw.rpi5.fan.speed0: 75
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: 85900
hw.rpi5.fan.temp2: 80000
hw.rpi5.fan.temp1: 74000
hw.rpi5.fan.temp0: 68000

58950 < 68000-5000 < 68000 but: hw.rpi5.fan.rpm is 3313 instead of zero.


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