From owner-freebsd-arm@freebsd.org Fri Jun 5 21:53:15 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 75B6D338672 for ; Fri, 5 Jun 2020 21:53:15 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch [185.70.40.131]) (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 49dxGf1d2Lz3yD2 for ; Fri, 5 Jun 2020 21:53:13 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Date: Fri, 05 Jun 2020 21:53:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=a9development.com; s=protonmail; t=1591393991; bh=r31Ue3DYkbyc8BansCuU1mD24L60nG/3K2/4HYyaexA=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=IxOw70mOo0nF/cqr1KrB2fKNLw5rbmKnkCjTIYNceXZBBpIGT7aNdduSnejIXm+Lk KY+V05Hqcz/XaqGkVcZd24uHOGdmEvryi8K9xj5YmXEczeidgRCACHtoLwqMx+NdGy ZJVOYtwMs7vGot3fSxKL4TlzZEFkoXH0zYR+z/CE= To: "greg@unrelenting.technology" From: Dan Kotowski Cc: freebsd-arm , Marcin Wojtas Reply-To: Dan Kotowski Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X Message-ID: In-Reply-To: References: <31D3FA64-8296-4CA5-92A2-F7FE7C4AE981@unrelenting.technology> <32d1c173d986884efb9b28932c0ead52@unrelenting.technology> <5e1b4bfe845e62bbcd8b827fa37f2b98@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: 49dxGf1d2Lz3yD2 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=a9development.com header.s=protonmail header.b=IxOw70mO; dmarc=pass (policy=none) header.from=a9development.com; spf=pass (mx1.freebsd.org: domain of dan.kotowski@a9development.com designates 185.70.40.131 as permitted sender) smtp.mailfrom=dan.kotowski@a9development.com X-Spamd-Result: default: False [-4.14 / 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)[]; RWL_MAILSPIKE_GOOD(0.00)[185.70.40.131:from]; NEURAL_HAM_LONG(-0.96)[-0.956]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[a9development.com:+]; DMARC_POLICY_ALLOW(-0.50)[a9development.com,none]; NEURAL_HAM_SHORT(-1.09)[-1.088]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; 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.131: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: Fri, 05 Jun 2020 21:53:15 -0000 > > > > https://gist.github.com/agrajag9/749f504dcac741e902f87c2ea03ae9ac > > > > From jnettlet: > > > > BEGIN QUOTE > > > > the V1 silicon has a SATA errata. I have partially worked around th= e errata moving some > > > > configuration into the firmware, but I still need to sort out the r= emaining bits. Sometimes just > > > > unplugging and replugging your SATA cable will help to reseat the c= onnector and help. Also it is > > > > very sensitive to marginal SATA cables. > > > > END QUOTE > > > > I played around a bit and could create and destroy GPTs, make files= ystems, read and write to said > > > > filesystems, and hot-plug even seems to work. But I'm not sure if j= on's comment really explains > > > > the > > > > AHCI error we're still seeing: > > > > (aprobe3:ahcich3:0:15:0): NOP FLUSHQUEUE. ACB: 00 00 00 00 00 00 00= 00 00 00 00 00 > > > > (aprobe3:ahcich3:0:15:0): CAM status: Command timeout > > > > (aprobe3:ahcich3:0:15:0): Error 5, Retries exhausted > > > > > > I experienced this issue on a cuple of targets (e.g. Zynq-MP or > > > LS1046A). The port-multiplier quirk flag helped - please try adding: > > > ahci->quirks |=3D AHCI_Q_NOPMP; > > > Build with this + more ITS logging: > > > https://send.firefox.com/download/cf66ed7f48160529/#LpeMjccv7iqze5hAx= _6BrQ > > > The patch that lets AHCI attach: > > > https://reviews.freebsd.org/D25145 > > > > https://gist.github.com/agrajag9/129585436f01876cc4d799382e1c0fac > > AHCI is looking better and better! I'm going to do a little bit of poki= ng at that SATA HDD just to > > see how stable it really is. > > Posted quirk patch:https://reviews.freebsd.org/D25157 > > Back to PCI: hmm, maybe the reason that IORT parsing weirdly picks SMMU u= p is that ranges with .NumIds=3D0 end up > with end before the beginning.. > > mapping->end =3D map_entry->InputBase + map_entry->IdCount - 1; > > The ARM document DEN0049D says the field is "The number of IDs in the ran= ge minus one". > If my brain still works at all: that means we have to do plus one when in= terpreting it, not minus one more!! :D > > This causes the first mapping on the PCIe root complex to be used, when w= e clearly want the second one. > > Sooo NOW pcie should work! I promise: > > https://send.firefox.com/download/05a4e22a349f611f/#azClkvNDfZU-PczXSmNva= Q Sad trombone https://gist.github.com/agrajag9/eddb36ad44898c070e464e7add594= 26d