From nobody Tue Jan 16 21:55:38 2024 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 4TF2rK21V7z58787 for ; Tue, 16 Jan 2024 21:55:45 +0000 (UTC) (envelope-from pldrouin@pldrouin.net) Received: from mail-4323.proton.ch (mail-4323.proton.ch [185.70.43.23]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TF2rJ5nNLz4G5F for ; Tue, 16 Jan 2024 21:55:44 +0000 (UTC) (envelope-from pldrouin@pldrouin.net) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pldrouin.net; s=protonmail3; t=1705442142; x=1705701342; bh=LvDvlnPRtAereenRs50ObhFyTiDxSn+oQ1eMs9+wRpQ=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=WZIoWguregln7ICC8+W1M9QSHU0p4vmN99nZLVsgC9qC+TEdefHvJEwUbM5ZVFnrr dqocH+Wc8eN5B709H9l2RmhAbmkZNka9E1bzzDmOafY2XscDU8bv1YUJzlYUq1eUUr RHgn2KlDPvDCzG+vhrjj/5yNiUCGV8DWLD+MIXVWYr3SfqhIL3HyCZ0Zs3RjTTU3tc +dH7Y7t3aFalT9fWM2zNP85KwVwhfaI1dbPExV8gq2HhVYK4BDRjA3+aeGIuXTI1bo B+lGMvQNCCI8i0F40HtWZNtm/PTckQX3oe7XNTz7QPtwfjh+0/VYfVTJcZnzg4Zx3H rs+fumiV58RbQ== Date: Tue, 16 Jan 2024 21:55:38 +0000 To: Mark Millard From: Pierre-Luc Drouin Cc: "freebsd-arm@FreeBSD.org" Subject: Re: LX2160A devices not detected? Message-ID: In-Reply-To: <9CEB709A-8EC0-4214-A57D-B13ECEF3D709@yahoo.com> References: <9CEB709A-8EC0-4214-A57D-B13ECEF3D709@yahoo.com> Feedback-ID: 62276728:user:proton 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 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4TF2rJ5nNLz4G5F X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH] Hi, thank you for all the information. Yes it is really fan control that I am a= fter, the whining is really bothering me. I came across this dmesg output: = https://gist.github.com/agrajag9/bbb49048447510a128cb3304546e174b/revisions= . It seems that they are using both FDT and ACPI at the same time? I have also found this patch to split the I2C controller driver to add ACPI= support, but it does not seem to quite work, due to clock issues: https://= reviews.freebsd.org/D24917 Also there is this thread where there is mention of using ACPI _TZ methods = to control the fan, which is supported by Linux but not FreeBSD: https://co= mmunity.solid-run.com/t/fan-control/205 Based on these three avenues I am not sure what could be the most straightf= orward way to get it working? Ideally I would like to program the fan contr= oller to do some automatic fan control based on temperature. Thanks! On Tuesday, January 16th, 2024 at 12:25, Mark Millard w= rote: >=20 >=20 > On Jan 16, 2024, at 07:33, Pierre-Luc Drouin pldrouin@pldrouin.net wrote: >=20 > > I have seen that there is some support for the LX2160A SOC in FreeBSD: = https://github.com/freebsd/freebsd-src/commit/36362eb0a0a1862a0898a6e17844a= 54f3f28f114#diff-00274f2856d4a354783db33e78b20c78092e2e29bf86f4c3e4022982ec= 64620b >=20 >=20 > Standard ACPI does not present fdt. This is EDK2 based for this context. > Standard fdt does not present ACPI. This is U-Boot based for this context= . >=20 > As for what FreeBSD does: >=20 > If a fdt is presented, ACPI is not used at all by default. > If no fdt is presented, ACPI is used instead (if present). > (I happened to ask that question recently.) >=20 > So, as I understand it, FreeBSD does not, by default, ever use > a mix of fdt and ACPI as things are. (I'm not claiming such > can not be forced somehow, not that I'd know how.) >=20 > Your diff is for fdt. So it appears that you need to be using > U-Boot to involve that code (by default). Note the lack of the > network processor for U-Boot: "All peripherals but the network > processor are supported." This might mean needing a network > dongle or some such in order to have Ethernet working. >=20 > ACPI booting supports basic use of the 1Gbit/sec Ethernet port. > (I do not know the status of anything fancier for the networking > processor.) >=20 > I've always booted ACPI style. There is no port for U-Boot as I > remember. So you would have to deal with building something > appropriate. >=20 > The system that I've access to has a quieter fan and better > heatsink but am also not bothered as much by such noises as some > folks are. (Fan control seems to be the missing thing for ACPI > relative to i2c.) >=20 > > From what I understand this is all done through device tree probing. >=20 >=20 > For U-Boot and UEFI/fdt yes; for EDK2 and UEFI/ACPI no, at least > by default. >=20 > > However when I dump the ACPI table on my system, I don't have these dev= ice tree entries. I am using lx2160a_uefi. >=20 >=20 > So am I. >=20 > > What type of bootloader is FreeBSD expecting instead of what I am curre= ntly using? >=20 >=20 > U-Boot provides UEFI+fdt instead of UEFI+ACPI. FreeBSD supports both form= s > of UEFI with its normal boot loader. >=20 > Since I use UEFI/ACPI I know the kernel supports what I use. >=20 > I do not know if the kernel well supports fdt. I'm not aware of > anyone reporting using the HoneyComb via FreeBSD with fdt. The > one clear point is the lack of network processor support. >=20 > > Otherwise should it be possible to get device detection working by addi= ng device tree entries into my DSDT, recompiling the AML with iasl and load= ing the table in /boot/loader.conf? >=20 >=20 > If you want EDK2 (UEFI/ACPI) + fdt use mixed by FreeBSD, you > likely have more work to do. I do not know any details. >=20 > > Thanks! > > On Saturday, January 6th, 2024 at 23:43, Pierre-Luc Drouin pldrouin@pld= rouin.net wrote: > >=20 > > > Hi, > > >=20 > > > I would like to get access to the AMC6821 I2C fan controller on my So= lidRun HoneyComb LX2 board. Currently I only see it here: > > >=20 > > > devinfo -v | grep I2C > > > unknown pnpinfo _HID=3DNXP0001 _UID=3D0 _CID=3Dnone at handle=3D\SB.I= 2C0 > > > unknown pnpinfo _HID=3DNXP0002 _UID=3D0 _CID=3Dnone at handle=3D\SB.I= 2C0.MUX0 > > > unknown pnpinfo _HID=3DPRP0001 _UID=3D0 _CID=3Dnone at handle=3D\SB.I= 2C0.MUX0.CH01.FAN1 > > > unknown pnpinfo _HID=3DPRP0001 _UID=3D1 _CID=3Dnone at handle=3D\SB.I= 2C0.MUX0.CH03.THE1 > > > unknown pnpinfo _HID=3DNXP0001 _UID=3D1 _CID=3Dnone at handle=3D\SB.I= 2C1 > > >=20 > > > There is no iic device in /dev > > >=20 > > > There is info regarding fan control on this board here: https://commu= nity.solid-run.com/t/fan-control/205 > > >=20 > > > Am I correct that the only way to get access to the controller from t= he OS side is to write an ACPI driver for it? What is involved exactly? >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com