From nobody Fri Jan 14 00:38:57 2022 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C843219426FF for ; Fri, 14 Jan 2022 00:39:24 +0000 (UTC) (envelope-from bscott@bunyatech.com.au) Received: from vmse04.mailcluster.com.au (vmse04.mailcluster.com.au [IPv6:2401:fc00:4:1::6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JZj9P0mxRz4f40 for ; Fri, 14 Jan 2022 00:39:20 +0000 (UTC) (envelope-from bscott@bunyatech.com.au) Received: from vmcp43.digitalpacific.com.au ([101.0.119.58]) by vmse04.mailcluster.com.au with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1n8AcN-0003oX-4O for freebsd-arm@freebsd.org; Fri, 14 Jan 2022 11:39:08 +1100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bunyatech.com.au; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:From:References:To:Subject:MIME-Version:Date:Message-ID:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=T+sGaJ44evCfiRK0u8KHBavHTVo7YHef0dy2i717JDA=; b=cnsf8V3D+CS5lbgic/ZWHvPcFN 3dda2WM7T60NQ3H0yqeGJooJuNnoJyRk2z3gTUnlK3ojkgJ0GC1aET5W6bWY03fluB8M3uyDWsMi6 WAKWgoaJpUUHUBOxbowZJXeqM0YXDJcIFRjVk9OgBAZQR9YPTLUfG6/yYsGJ8XM2nvAB3p4LV3ib7 HAQs5JI2RbZhexlvFkANKSkUXvmfzX8B+Yb7uwCkDMmu0qvmTJirjl8Xj/Dg4XYfuMXTd5UtYBELR orudB/5AngILDZP3H8ewRhGsaPnmE5ovjTorlL/gMFTnXmEcnLpS7/JzqayobZLd1ItdRw3rAhe4U fpx/gjWQ==; Received: from 203-113-203-135-static.tcs.netspace.net.au ([203.113.203.135]:6337 helo=[10.153.14.100]) by vmcp43.digitalpacific.com.au with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1n8AcL-007TKI-I1 for freebsd-arm@freebsd.org; Fri, 14 Jan 2022 11:38:57 +1100 Message-ID: <590ae9e7-095d-9269-6ec1-54dc403e0440@bunyatech.com.au> Date: Fri, 14 Jan 2022 11:38:57 +1100 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: RPi4B, POE+. Fan To: freebsd-arm@freebsd.org References: <7ddec2da-b22a-9d3d-b64b-6c8137ff8f6d@bunyatech.com.au> <5a2db808-d90a-cebd-51d2-7b4ee9953a75@gmail.com> <4b24de3a-0124-50d6-e1bc-cc45785e3755@bunyatech.com.au> From: Brian Scott In-Reply-To: <4b24de3a-0124-50d6-e1bc-cc45785e3755@bunyatech.com.au> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated-User: bscott@bunyatech.com.au X-Authenticator: dovecot_plain X-Originating-IP: 101.0.119.58 X-SpamExperts-Domain: digipac-sh-outbound4.mailcluster.com.au X-SpamExperts-Username: 101.0.119.58 X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.03) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT8l/yLJ0Sqxdhy5JNIBIKHCPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5wOvGg18h18lTsuUGH1KgAagLCWYuPCxwJEfxKP87A95+fH zJ6mVE7ewsipSVIfs4Yx/owv2FAzm7Y56pBI5zAuABHVTw1lV42ob3hDgXVUNfMYOaf2k/5ge9xY pFnK4mEZANNbnYFKmAzb4T8ZHiCK+gaXrHkgRC7/tI3CjXmVyqRBrz0yacPB+Vpb1pvfg9Ep8Gnm YnDDwZLHsvD3pj+L6FeN7H3/w7GNoXC45RpOKoj/3DdQ0wDV188+gffZv/QAKQlQdTfwbSciar+2 JCMst0dEunmtVTQWqR0MJGYnYGBIZS4rRgm1GD0QN7Psq7kMoOLjGsRz/MUE6aIZoCcUNXR4aVG4 tVHU1Zldyy+zfdeiXSYiLTYFU2inszSuEYHdlUkt/DWy8vGLtXVYC5E2Ixfs2qKc0fhF4YMd0lwH wOXyY7DGIntSiB4r6Kj1fsj0vv0lYcA3KUCZ1xbWKiooCEhtIlNufemFbU3yy1ZWIMOHTNjJsV8U ZvUGC4qEZBLXzXmHaN80JC+nfH561Te/6BtpbmdpMLvM58ZB4GVvZfvg7iEFLP+SSY+Av5+AiC6v 12zNU5FHE/848hPLR1NYJla5IMQxwODSBUvv4iU63ukMT1XB043+JMyRJb1r5cd51HO6Firt88BV o4G3txy5xc8zPwPk/btDEg7yakhCkffQsJMjVuaCfq+S2F3DJOIRFZ4oobg8BBg3Jq+ntzj0NT70 kg2R2AKhDFzLC6np7U+Md/gsArzQL2xycpCDCvGkBJTycjSXYBbCRRLP/dzFGZvgVYfsK2EFAO2J yl68xeQJyPsBMRItmV2XMBZo/xvBcCqAIZodttem9i8KPHD+drySbwSPPFfZ0IrAVj3Tw2Kom956 CMNJENTxvHFc+CYnIrUaXo9oAQiaJUfHr8RdDkAjKCmcD+WP58n3ucKpsOwZrS0DLzSls2xwT68s ll0AUPM1AEV/Z4nBMjqx6+Ku85fPBYtEyP9wDgCiat7XFq2oD4F3wvnFD1nsYpfi92UulJUd6p/S u0x6qJLP8ZJcWEwQPAv2fxf3s0iIhEk0C9A6WFpTPd8WVXqUqH9xpi0= X-Report-Abuse-To: spam@vmse01.mailcluster.com.au X-Rspamd-Queue-Id: 4JZj9P0mxRz4f40 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bunyatech.com.au header.s=default header.b=cnsf8V3D; dmarc=none; spf=pass (mx1.freebsd.org: domain of bscott@bunyatech.com.au designates 2401:fc00:4:1::6 as permitted sender) smtp.mailfrom=bscott@bunyatech.com.au X-Spamd-Result: default: False [0.41 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bunyatech.com.au:s=default]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[bunyatech.com.au]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.90)[0.905]; DKIM_TRACE(0.00)[bunyatech.com.au:+]; NEURAL_SPAM_LONG(1.00)[1.000]; MLMMJ_DEST(0.00)[freebsd-arm]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:55803, ipnet:2401:fc00::/32, country:AU]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 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