From owner-freebsd-arm@freebsd.org Fri Jun 5 23:05:56 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 AC91333A7BB for ; Fri, 5 Jun 2020 23:05:56 +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 49dytW1c7rz46VX for ; Fri, 5 Jun 2020 23:05:54 +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=1591398352; 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=Ye3w9YH1r2V3DSdUYf5VcGVFvroJvmDQajPoAinvJmw=; b=aa7n94p3RO0QSaasMWEvaDTDe6Q33sTfnQTI1XtHbavZWKVDwk+QteYAOymcvHzr5lHDMw mKxCKq6WvLRa2H5OkijmL7lhU2LrwY7iXBVbsPIbt/f+sEZU3XeSCr27BG6MPEhEkXLgmC dyzW/3zJNc114Ypd/IABGUeJRufu4Qo= Date: Fri, 05 Jun 2020 23:05:51 +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: <940a6099e971e01bd6d04564d0982b9d@unrelenting.technology> Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X To: "Dan Kotowski" Cc: "freebsd-arm" 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: 49dytW1c7rz46VX X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=aa7n94p3; 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.43 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.012]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=default]; R_SPF_ALLOW(-0.20)[+ip6:2001:41d0:2:863f::]; NEURAL_HAM_LONG(-1.01)[-1.008]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[unrelenting.technology:+]; RCPT_COUNT_TWO(0.00)[2]; FROM_NO_DN(0.00)[]; NEURAL_HAM_SHORT(-0.41)[-0.409]; DMARC_POLICY_ALLOW(-0.50)[unrelenting.technology,none]; 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 23:05:56 -0000 June 6, 2020 12:53 AM, "Dan Kotowski" wr= ote:=0A=0A>>>> https://gist.github.com/agrajag9/749f504dcac741e902f87c2ea= 03ae9ac=0A>>>> From jnettlet:=0A>>>> BEGIN QUOTE=0A>>>> the V1 silicon ha= s 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 re= maining bits. Sometimes=0A>> just=0A>>>> unplugging and replugging your S= ATA cable will help to reseat the connector and help. Also it=0A>> is=0A>= >>> very sensitive to marginal SATA cables.=0A>>>> END QUOTE=0A>>>> I pla= yed around a bit and could create and destroy GPTs, make filesystems, rea= d and write to=0A>> said=0A>>>> filesystems, and hot-plug even seems to w= ork. But I'm not sure if jon's comment really explains=0A>>>> the=0A>>>> = AHCI error we're still seeing:=0A>>>> (aprobe3:ahcich3:0:15:0): NOP FLUSH= QUEUE. ACB: 00 00 00 00 00 00 00 00 00 00 00 00=0A>>>> (aprobe3:ahcich3:0= :15:0): CAM status: Command timeout=0A>>>> (aprobe3:ahcich3:0:15:0): Erro= r 5, Retries exhausted=0A>>> =0A>>> I experienced this issue on a cuple o= f targets (e.g. Zynq-MP or=0A>>> LS1046A). The port-multiplier quirk flag= helped - please try adding:=0A>>> ahci->quirks |=3D AHCI_Q_NOPMP;=0A>>> = Build with this + more ITS logging:=0A>>> https://send.firefox.com/downlo= ad/cf66ed7f48160529/#LpeMjccv7iqze5hAx_6BrQ=0A>>> The patch that lets AHC= I attach:=0A>>> https://reviews.freebsd.org/D25145=0A>> =0A>> https://gis= t.github.com/agrajag9/129585436f01876cc4d799382e1c0fac=0A>> AHCI is looki= ng better and better! I'm going to do a little bit of poking at that SATA= HDD just to=0A>> see how stable it really is.=0A>> =0A>> Posted quirk pa= tch:https://reviews.freebsd.org/D25157=0A>> =0A>> Back to PCI: hmm, maybe= the reason that IORT parsing weirdly picks SMMU up is that ranges with= =0A>> .NumIds=3D0 end up=0A>> with end before the beginning..=0A>> =0A>> = mapping->end =3D map_entry->InputBase + map_entry->IdCount - 1;=0A>> =0A>= > The ARM document DEN0049D says the field is "The number of IDs in the r= ange minus one".=0A>> If my brain still works at all: that means we have = to do plus one when interpreting it, not minus=0A>> one more!! :D=0A>> = =0A>> This causes the first mapping on the PCIe root complex to be used, = when we clearly want the second=0A>> one.=0A>> =0A>> Sooo NOW pcie should= work! I promise:=0A>> =0A>> https://send.firefox.com/download/05a4e22a34= 9f611f/#azClkvNDfZU-PczXSmNvaQ=0A> =0A> Sad trombone https://gist.github.= com/agrajag9/eddb36ad44898c070e464e7add59426d=0A=0Ahmm. The device ID loo= ks correct to me.. but we can check against NetBSD just in case.=0A=0ACan= you boot NetBSD with debug messages (boot -x)?=0AIt should print 'ACPI: = IORT mapped devid' messages among other things.=0A=0AAlso.. about the fac= t that it's showing up as if the PCIe root is outputting to the SMMU,=0Am= aybe that really doesn't sound like a bug, more like the firmware modifyi= ng the table?=0A(and the interrupt is *actually* going to the SMMU?)=0ABu= t I can't find anything like that in the firmware code.=0A=0AAn ACPI tabl= e dump from running FreeBSD might help: /usr/sbin/acpidump -dt=0AAnd for = a full binary dump, install acpica-tools=0A(if you don't want to bother w= ith USB Ethernet and package installs,=0Ajust wget the package on another= machine and extract it onto the live image):=0Ahttps://pkg.freebsd.org/F= reeBSD:13:aarch64/latest/All/acpica-tools-20200430.txz=0Aand with that, r= un: /usr/local/bin/acpidump -b=0A(creates a bunch of binary files in the = current directory)=0A=0AAlso.. try using your self built firmware again?