From owner-freebsd-arm@freebsd.org Fri Jun 5 21:19:35 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 00AD7338091 for ; Fri, 5 Jun 2020 21:19:35 +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 49dwWn5XXwz3d6F for ; Fri, 5 Jun 2020 21:19:33 +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=1591391972; 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=Pry+jsS3XAee3fPhUeCMS0WhsJgqnQyk6QGOrx5rhZ8=; b=FiBF5hpZAlrnkTrwhpk1wocB/yFdhi6BUk0iqS91OTSykk0SUoxEJ7R7ZzWYjd9+LbCzDU DMskLRD5LBkubEqyCxhNVi62Kt3yREYLb4JmCTzCti2gTv9f7h2P3XzDgoclycbifDPZfJ mA1mnfeSTVIH8eRILGbHbTM29STnVjs= Date: Fri, 05 Jun 2020 21:19:31 +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: Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X To: "Dan Kotowski" Cc: "freebsd-arm" , "Marcin Wojtas" In-Reply-To: References: <31D3FA64-8296-4CA5-92A2-F7FE7C4AE981@unrelenting.technology> <32d1c173d986884efb9b28932c0ead52@unrelenting.technology> <5e1b4bfe845e62bbcd8b827fa37f2b98@unrelenting.technology> X-Spam-Score: -0.10 X-Rspamd-Queue-Id: 49dwWn5XXwz3d6F X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=FiBF5hpZ; 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 [-3.93 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.006]; 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::]; NEURAL_HAM_LONG(-0.99)[-0.989]; 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.94)[-0.940]; 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: Fri, 05 Jun 2020 21:19:35 -0000 June 5, 2020 10:18 PM, "Dan Kotowski" wr= ote:=0A=0A>>> https://gist.github.com/agrajag9/749f504dcac741e902f87c2ea0= 3ae9ac=0A>>> From jnettlet:=0A>>> BEGIN QUOTE=0A>>> the V1 silicon has a = SATA errata. I have partially worked around the errata moving some=0A>>> = configuration into the firmware, but I still need to sort out the remaini= ng bits. Sometimes just=0A>>> unplugging and replugging your SATA cable w= ill help to reseat the connector and help. Also it is=0A>>> very sensitiv= e to marginal SATA cables.=0A>>> END QUOTE=0A>>> I played around a bit an= d could create and destroy GPTs, make filesystems, read and write to said= =0A>>> filesystems, and hot-plug even seems to work. But I'm not sure if = jon's comment really explains=0A>> the=0A>>> AHCI error we're still seein= g:=0A>>> =0A>>> (aprobe3:ahcich3:0:15:0): NOP FLUSHQUEUE. ACB: 00 00 00 0= 0 00 00 00 00 00 00 00 00=0A>>> (aprobe3:ahcich3:0:15:0): CAM status: Com= mand timeout=0A>>> (aprobe3:ahcich3:0:15:0): Error 5, Retries exhausted= =0A>>> =0A>> =0A>> I experienced this issue on a cuple of targets (e.g. Z= ynq-MP or=0A>> LS1046A). The port-multiplier quirk flag helped - please t= ry adding:=0A>> ahci->quirks |=3D AHCI_Q_NOPMP;=0A>> =0A>> Build with thi= s + more ITS logging:=0A>> https://send.firefox.com/download/cf66ed7f4816= 0529/#LpeMjccv7iqze5hAx_6BrQ=0A>> =0A>> The patch that lets AHCI attach:= =0A>> https://reviews.freebsd.org/D25145=0A> =0A> https://gist.github.com= /agrajag9/129585436f01876cc4d799382e1c0fac=0A> =0A> AHCI is looking bette= r and better! I'm going to do a little bit of poking at that SATA HDD jus= t to=0A> see how stable it really is.=0A=0APosted quirk patch: https://re= views.freebsd.org/D25157=0A=0ABack to PCI: hmm, maybe the reason that IOR= T parsing weirdly picks SMMU up is that ranges with .NumIds=3D0 end up=0A= with end before the beginning..=0A=0Amapping->end =3D map_entry->InputBas= e + map_entry->IdCount - 1;=0A=0AThe ARM document DEN0049D says the field= is "The number of IDs in the range minus one".=0AIf my brain still works= at all: that means we have to do *plus* one when interpreting it, not mi= nus one more!! :D=0A=0AThis causes the *first* mapping on the PCIe root c= omplex to be used, when we clearly want the second one.=0A=0ASooo NOW pci= e should work! I promise:=0A=0Ahttps://send.firefox.com/download/05a4e22a= 349f611f/#azClkvNDfZU-PczXSmNvaQ