Re: RPi4B, POE+. Fan

Hi,

On 12/1/22 11:23 am, MJ wrote:
>
>
> On 11/01/2022 9:50 pm, Brian Scott wrote:
>> Hi List,
>>
>> Is there a known method to get the fan running on the rpi-poe+ board 
>> under FreeBSD?
>>
>
> I would assume this depends on the board. You've not specified anything.

Sorry, I should have been more explicit. The board is the 'official' 
rpi-poe+ board from the raspberry pi foundation. I should have 
underlined that. https://www.raspberrypi.com/products/poe-plus-hat/

>> It looks like it is controlled completely by the kernel in Linux 
>> land. Adding the rpi-poe dtb overlay has no effect on FreeBSD so I'm 
>> guessing there is no driver for it.
>>
>>  From what I've read, its controlled by something on the iic bus used 
>> for HAT identification. Beyond that, information seems to get very 
>> scarce. The Linux driver operates it by sending messages to the 
>> firmware. This would be a lot more tricky than just sending commands 
>> to an iic device from userland and beyond my hacking skills.
>
> If it is i2c rather than some n-channel FET, then you have a few options:
> 1. Look on the design specifications or data sheet for the address of 
> the i2c.
> 2. Build an i2c scanner using an arduino. This will scan for the 
> address on the bus.

All of the official documentation seems to revolve around enabling the 
device in the Linux kernel. I have found schematics for the power 
handling side of the board but nothing for the fan side.

I'm happy scanning the i2c bus from the Pi directly. The FreeBSD i2c 
command has worked well in the past. Knowing the address of the device 
doesn't tell me what it is since many i2c addresses are shared between 
many different device types.

>
> Once you have the address it's trivial to program i2c.There's lots of 
> examples of how to do this out in the internet.
>
> MJ

Thanks. As I said, knowing the address doesn't tell me what it is, only 
how to address it. The only example of code that I've found for this 
device is in the Linux kernel and uses an interface to the firmware 
rather than directly through i2c.

I'll follow your advice and do some bus probing to see what is there 
since I believe it's possible to access the second i2c bus with the 
right config.txt entries.

Thanks

Brian