From owner-freebsd-arm@freebsd.org Tue May 19 19:22:44 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 696362F2BE1 for ; Tue, 19 May 2020 19:22:44 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out1.migadu.com (out1.migadu.com [IPv6:2001:41d0:2:863f::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49RQkp6f05z43DJ for ; Tue, 19 May 2020 19:22:42 +0000 (UTC) (envelope-from greg@unrelenting.technology) MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unrelenting.technology; s=default; t=1589916160; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gpX0kZyefWHgrtMXYmuvu0/bfA4jD1INrtRM/ksv6m4=; b=GbUJ1eG0Nu2nYQ9+lu/fwvFx1PjDw7SmdyGlVPk4ic7KPmrEF4oz+uvH8hT0UP4wZYmb7X mQVM0rTaDDw27V/pzqm3UlBYqaoaLeQD492w3l618VR8HFyuRV2cCt0KMBRcyCNmTRaKps h9pnN48jn0zk0oHh06BoIywAAkISLJs= Date: Tue, 19 May 2020 19:22:39 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: greg@unrelenting.technology Message-ID: <3e81db774e0fc1a3c2251c89b7629e1b@unrelenting.technology> Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X To: "Dan Kotowski" , "Marcin Wojtas" Cc: "freebsd-arm" In-Reply-To: References: <2053cd2299b81860deecc638ef839d1f@unrelenting.technology> <0012917d629a48e9fcd8589f4f002e1b@unrelenting.technology> <947c2f9bfaad823a2b104b8741502b40@unrelenting.technology> X-Spam-Score: -0.10 X-Rspamd-Queue-Id: 49RQkp6f05z43DJ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=GbUJ1eG0; dmarc=pass (policy=none) header.from=unrelenting.technology; spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 2001:41d0:2:863f:: as permitted sender) smtp.mailfrom=greg@unrelenting.technology X-Spamd-Result: default: False [-2.06 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.95)[-0.949]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=default]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2001:41d0:2:863f::]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[unrelenting.technology:+]; DMARC_POLICY_ALLOW(-0.50)[unrelenting.technology,none]; FROM_NO_DN(0.00)[]; NEURAL_HAM_SHORT(-0.11)[-0.110]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2020 19:22:44 -0000 May 19, 2020 9:17 PM, "Dan Kotowski" wro= te:=0A=0A>>> I can't find the PCIe cables for my PSU right now, so the RX= 480 is out until I have time to dig=0A>>> through The Cable Box Of Doom. = But I do have a spare LSI SAS HBA that I'll try after lunch!=0A>> =0A>> Y= eah, mpr/mps drivers are present, would be an okay thing to try.=0A> =0A>= Latest dmesg.boot: https://gist.github.com/agrajag9/cf6d203dc3730350182c= b53ba5a8b999=0A> =0A> The HBA came up as pci1 on pcib1 (line 105). And, a= s expected since it came up as a generic PCI=0A> device rather than MPR/M= PS, the attached drive doesn't show up. And yes, I did confirm that mpr.k= o=0A> and mps.ko are present in /boot/kernel/=0A=0AThe problem is not tha= t the driver isn't loaded (you can always just kldload it manually), it's= this sadness:=0A=0Apcib1: pci_host_generic_core_alloc_resource FAIL: typ= e=3D4, rid=3D16, start=3D0000000000040000, end=3D00000000000400ff, count= =3D0000000000000100, flags=3D2000=0Apcib1: pci_host_generic_core_alloc_re= source FAIL: type=3D4, rid=3D16, start=3D0000000000000000, end=3Dffffffff= ffffffff, count=3D0000000000000100, flags=3D2000=0Apcib1: pci_host_generi= c_core_alloc_resource FAIL: type=3D3, rid=3D20, start=3D0000000670440000,= end=3D0000000670443fff, count=3D0000000000004000, flags=3D3800=0Apcib1: = pci_host_generic_core_alloc_resource FAIL: type=3D3, rid=3D28, start=3D00= 00000670000000, end=3D000000067003ffff, count=3D0000000000040000, flags= =3D4800=0A=0ALooking at NetBSD code, we might need to implement support f= or the custom NXP0016 config device:=0A=0Ahttps://github.com/NetBSD/src/c= ommit/1a0fb037e62e4e3472966e33588957919b5e3a97=0A=0AI'll have time to att= empt a blind port of that code next week :D=0A=0AThere is a way to get an= y stock OS (even Windows!) to work with this PCIe controller,=0Abut it in= volves awful hacks and legacy interrupts, unacceptable stuff:=0Ahttps://t= witter.com/linux4kix/status/1260946442346205184=0A=0Aso you'll have to wa= it for now.