From owner-freebsd-arm@freebsd.org Tue May 19 20:36:52 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 33F742F4834 for ; Tue, 19 May 2020 20:36:52 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49RSNM2HsVz46hX for ; Tue, 19 May 2020 20:36:51 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Date: Tue, 19 May 2020 20:36:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=a9development.com; s=protonmail; t=1589920608; bh=850a17D77WBAZhMA1qrIZJgBbkYMC3gxj2GIHBTtZtw=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=TcPfG9QzypkRZ4gVoDqT/Y8728nB8Ns3jA57JJjJPa+j4GsrXo0+nbyKmMHssajeI 8jeZB1Ug9J0UA2iVT+4ZweT7rkrDn/bd9QwdLneuRdiLZYsWTUlozhwPEJq6DuH8Go jylYBoqE/EeyqKvUU/N1ipnHyibHO9vst3WfDFdg= To: "greg@unrelenting.technology" From: Dan Kotowski Cc: Marcin Wojtas , freebsd-arm Reply-To: Dan Kotowski Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X Message-ID: In-Reply-To: <3e81db774e0fc1a3c2251c89b7629e1b@unrelenting.technology> References: <0012917d629a48e9fcd8589f4f002e1b@unrelenting.technology> <947c2f9bfaad823a2b104b8741502b40@unrelenting.technology> <3e81db774e0fc1a3c2251c89b7629e1b@unrelenting.technology> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Rspamd-Queue-Id: 49RSNM2HsVz46hX X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=a9development.com header.s=protonmail header.b=TcPfG9Qz; dmarc=pass (policy=none) header.from=a9development.com; spf=pass (mx1.freebsd.org: domain of dan.kotowski@a9development.com designates 185.70.40.18 as permitted sender) smtp.mailfrom=dan.kotowski@a9development.com X-Spamd-Result: default: False [-2.79 / 15.00]; HAS_REPLYTO(0.00)[dan.kotowski@a9development.com]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[a9development.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[a9development.com:+]; DMARC_POLICY_ALLOW(-0.50)[a9development.com,none]; NEURAL_HAM_SHORT(-0.73)[-0.731]; NEURAL_HAM_MEDIUM(-0.96)[-0.961]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_VERYGOOD(0.00)[185.70.40.18:from]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[185.70.40.18:from] 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 20:36:52 -0000 > > > > I can't find the PCIe cables for my PSU right now, so the RX480 is = out until I have time to dig > > > > through The Cable Box Of Doom. But I do have a spare LSI SAS HBA th= at I'll try after lunch! > > > > > > Yeah, mpr/mps drivers are present, would be an okay thing to try. > > > > Latest dmesg.boot: https://gist.github.com/agrajag9/cf6d203dc3730350182= cb53ba5a8b999 > > The HBA came up as pci1 on pcib1 (line 105). And, as expected since it = came up as a generic PCI > > device rather than MPR/MPS, the attached drive doesn't show up. And yes= , I did confirm that mpr.ko > > and mps.ko are present in /boot/kernel/ > > The problem is not that the driver isn't loaded (you can always just kldl= oad it manually), it's this sadness: > > pcib1: pci_host_generic_core_alloc_resource FAIL: type=3D4, rid=3D16, sta= rt=3D0000000000040000, end=3D00000000000400ff, count=3D0000000000000100, fl= ags=3D2000 > pcib1: pci_host_generic_core_alloc_resource FAIL: type=3D4, rid=3D16, sta= rt=3D0000000000000000, end=3Dffffffffffffffff, count=3D0000000000000100, fl= ags=3D2000 > pcib1: pci_host_generic_core_alloc_resource FAIL: type=3D3, rid=3D20, sta= rt=3D0000000670440000, end=3D0000000670443fff, count=3D0000000000004000, fl= ags=3D3800 > pcib1: pci_host_generic_core_alloc_resource FAIL: type=3D3, rid=3D28, sta= rt=3D0000000670000000, end=3D000000067003ffff, count=3D0000000000040000, fl= ags=3D4800 > > Looking at NetBSD code, we might need to implement support for the custom= NXP0016 config device: > > https://github.com/NetBSD/src/commit/1a0fb037e62e4e3472966e33588957919b5e= 3a97 > > I'll have time to attempt a blind port of that code next week :D > > There is a way to get any stock OS (even Windows!) to work with this PCIe= controller, > but it involves awful hacks and legacy interrupts, unacceptable stuff: > https://twitter.com/linux4kix/status/1260946442346205184 > > so you'll have to wait for now. I've waited this many months to finally get this far, another week is no pr= oblem :D Would you be able to share any patches and kernconfs you're working from so= I have a frame of reference? My own dev skills are certainly nowhere near = yours, but I'd like to at least read through the code you've applied to get= us this far and maybe even learn something new along the way.