From owner-freebsd-arm@freebsd.org Sat Jun 6 00:44:11 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 6656133CA41 for ; Sat, 6 Jun 2020 00:44:11 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out0.migadu.com (out0.migadu.com [IPv6:2001:41d0:2:267::]) (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 49f13s5lPbz4K0Y for ; Sat, 6 Jun 2020 00:44:09 +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=1591404242; 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=kRfHLXW80iH+hv1/8zQ2IRygB5FDgN1BcYr2sBhF0/A=; b=Po6BWMs045hkwkQEmh1yjBzTXgNMIWHbrd8M/I9pofAV5sFuhjFq9Oq4dUoAV8cLVkdp5W vtZ8E0eC0F5tqYHqVCDhLKhm5UN1Qd+u0BdtrM1PReyJ8sqevDgv3L9SSipB0/xzWxksr0 w+a7JgeYF2g7xq113zvYkdyIxdl7voc= Date: Sat, 06 Jun 2020 00:44:00 +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" In-Reply-To: References: <32d1c173d986884efb9b28932c0ead52@unrelenting.technology> <5e1b4bfe845e62bbcd8b827fa37f2b98@unrelenting.technology> <940a6099e971e01bd6d04564d0982b9d@unrelenting.technology> X-Spam-Score: -0.10 X-Rspamd-Queue-Id: 49f13s5lPbz4K0Y X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=Po6BWMs0; dmarc=pass (policy=none) header.from=unrelenting.technology; spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 2001:41d0:2:267:: as permitted sender) smtp.mailfrom=greg@unrelenting.technology X-Spamd-Result: default: False [-3.71 / 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:267::]; 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.69)[-0.695]; 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: Sat, 06 Jun 2020 00:44:11 -0000 June 6, 2020 3:28 AM, "Dan Kotowski" wro= te:=0A=0A>>> https://gist.github.com/agrajag9/129585436f01876cc4d799382e1= c0fac=0A>>> AHCI is looking better and better! I'm going to do a little b= it of poking at that SATA HDD just=0A>> to=0A>>> see how stable it really= is.=0A>>> Posted quirk patch:https://reviews.freebsd.org/D25157=0A>>> Ba= ck 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 be= ginning..=0A>>> mapping->end =3D map_entry->InputBase + map_entry->IdCoun= t - 1;=0A>>> The ARM document DEN0049D says the field is "The number of I= Ds in the range minus one".=0A>>> If my brain still works at all: that me= ans we have to do plus one when interpreting it, not minus=0A>>> one more= !! :D=0A>>> This causes the first mapping on the PCIe root complex to be = used, when we clearly want the=0A>> second=0A>>> one.=0A>>> Sooo NOW pcie= should work! I promise:=0A>>> https://send.firefox.com/download/05a4e22a= 349f611f/#azClkvNDfZU-PczXSmNvaQ=0A>> =0A>> Sad trombone https://gist.git= hub.com/agrajag9/eddb36ad44898c070e464e7add59426d=0A>> =0A>> hmm. The dev= ice ID looks correct to me.. but we can check against NetBSD just in case= .=0A>> =0A>> Can you boot NetBSD with debug messages (boot -x)?=0A>> It s= hould print 'ACPI: IORT mapped devid' messages among other things.=0A>> = =0A>> Also.. about the fact that it's showing up as if the PCIe root is o= utputting to the SMMU,=0A>> maybe that really doesn't sound like a bug, m= ore like the firmware modifying the table?=0A>> (and the interrupt is act= ually going to the SMMU?)=0A>> But I can't find anything like that in the= firmware code.=0A>> =0A>> An ACPI table dump from running FreeBSD might = help: /usr/sbin/acpidump -dt=0A>> And for a full binary dump, install acp= ica-tools=0A>> (if you don't want to bother with USB Ethernet and package= installs,=0A>> just wget the package on another machine and extract it o= nto the live image):=0A>> https://pkg.freebsd.org/FreeBSD:13:aarch64/late= st/All/acpica-tools-20200430.txz=0A>> and with that, run: /usr/local/bin/= acpidump -b=0A>> (creates a bunch of binary files in the current director= y)=0A>> =0A>> Also.. try using your self built firmware again?=0A> =0A> h= ttps://gist.github.com/agrajag9/bce229ac6527b21f91c8337d79e1dae9=0A> =0A>= Well, my own self-built firmware seems to be misbehaving - it's failing = to see the SD reader or=0A> throwing errors about `EFI ASSERT` or things = like this:=0A> =0A> `Synchronous Exception at 0x00000000ED7BD93C`=0A> =0A= > So continuing to use Jon's for now...=0A> =0A> `acpidump -b` just spat = back "Could not get ACPI table at index 1, AE_NOT_FOUND"=0A=0AThat's norm= al, it still creates files in the current directory..=0ABut okay, the acp= iview is good enough.=0A=0A> `acpidump -dt` worked just fine=0A> =0A> Als= o pulled the output of `acpiview` from the EFI shell again since we're us= ing Jon's latest=0A> tables.=0A=0Alol, 0x30 =3D=3D decimal 48. ITS node i= s at 0x30, SMMU at 0x48 (72). How not confusing!=0A=0AYeah so the PCIe ro= ot nodes are indeed pointing at the SMMU, while that's not supposed to be= the case in the public code:=0Ahttps://github.com/SolidRun/edk2-platform= s/blob/eec706c2d693be0b3793d9180e7d1a4813a526cf/Silicon/NXP/LX2160A/AcpiT= ables/Iort.aslc#L220=0A=0AHence my hypothesis that Jon was experimenting = with enabling the SMMU in that build :)=0A=0AMaybe try the firmware from = that google drive link?=0A=0A> [ 1.0000030] panic: Trap: Data Abort (EL= 1): Translation Fault L0 with read access for 0000000000000300: pc ffffc0= 00004aca34: opcode f8607a74: ldr x20, [x19,x0,lsl #3]=0A=0ARight, damn, J= on said that on the new firmware, OSes with the custom layerscape PCIe dr= iver won't work.