Date: Fri, 14 Jan 2022 11:38:57 +1100 From: Brian Scott <bscott@bunyatech.com.au> To: freebsd-arm@freebsd.org Subject: Re: RPi4B, POE+. Fan Message-ID: <590ae9e7-095d-9269-6ec1-54dc403e0440@bunyatech.com.au> In-Reply-To: <4b24de3a-0124-50d6-e1bc-cc45785e3755@bunyatech.com.au> References: <7ddec2da-b22a-9d3d-b64b-6c8137ff8f6d@bunyatech.com.au> <5a2db808-d90a-cebd-51d2-7b4ee9953a75@gmail.com> <4b24de3a-0124-50d6-e1bc-cc45785e3755@bunyatech.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/1/22 2:59 pm, Brian Scott wrote: > 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. Hi, Just following up my previous post. The PoE+ HAT seems to almost follow the rules for HATs have a storage device at address 51 on the normally hidden iic0 controller. The HAT specifications require the device to be at address 50 but I'm guessing that would make it incompatible with other devices on the same controller/bus. Using the i2c command to dump the contents of the device (note: it repeats after 256 bytes so presumably has an 8 bit address internally): # i2c -f /dev/iic0 -m tr -w 16 -d r -c 256 -a 51 gives: 52 2d 50 69 01 00 04 00 8a 00 00 00 01 00 00 00 2c 00 00 00 e9 50 f6 3f c3 47 81 a4 5c 40 7d 07 c5 d1 6f 7f 04 00 03 00 0c 08 52 61 73 70 62 65 72 72 79 20 50 69 50 6f 45 2b 20 48 41 54 c2 6c 02 00 01 00 20 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 6d 6d 03 00 02 00 0f 00 00 00 72 70 69 2d 70 6f 65 2d 70 6c 75 73 00 be d8 04 00 03 00 03 00 00 00 00 45 c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00 00 80 07 00 ff 30 41 50 52 38 32 f9 3f 0f 40 (apologies if this is rendered in a variable width font) Using the specification for the id of a HAT, this looks quite straight forward. There is a header and 4 'atom's of information. Significantly, the device doesn't claim any GPIO pins (nice), and the required dtoverlay is 'rpi-poe-plus'. The raspberry pi firmware port doesn't include the 'rpi-poe-plus' overlay but the upstream repository does. Tracking down the source files (rpi-poe-plus-overlay.dts and rpi-poe-overlay.dts), the FreeBSD dtc tool complains because they use a '#include' statement to include the non-plus version into the plus version's code. This is easily overcome by editing the file to actually include the other contents and now it compiles cleanly. I Haven't done a test run with this overlay yet. My earlier tests were using the non-plus version of the overlay from the firmware port. I don't expect it to make any difference from FreeBSD's perspective but it may trigger something in the video core firmware. The really interesting thing about this dump is the last 16 bytes. They are past the end of the defined contents for the HAT id structure. I presume they are from another part of the device and are used to control the fan speed as well as return some telemetry from the device (temperature, voltage in/out, power draw, actual fan speed, ... just guessing here). Unfortunately, the only example code that deals with this mystery device is inside the video core firmware and therefore unavailable. This I imagine, will also include the hack to check address 51 on the iic bus specifically for the PoE HAT. Apart from trying the new dtoverlay, I expect my next step will be to unplug the fan and wire it directly to power. It would probably run at full speed most of the time anyway. Cheers, Brian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?590ae9e7-095d-9269-6ec1-54dc403e0440>