From owner-freebsd-arm@freebsd.org Sat Jun 6 00:29:09 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 2734933C169 for ; Sat, 6 Jun 2020 00:29:09 +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 49f0kX2KV1z4GQY for ; Sat, 6 Jun 2020 00:29:08 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Date: Sat, 06 Jun 2020 00:28:59 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=a9development.com; s=protonmail; t=1591403343; bh=MDvciEzn46w16jyISDCS+McnTcZwzz1GyAnBfs/aHtI=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=WFy8J5dYCiz6CbDDZlsly9gIjai1+BIAaBILaI6/ypb7L+ZuuuOEo1oQqhWZ2YGUC u4MIvvuA0kHN3CISbyPcoa6bi58R23mvUbmva7QD3H0AuYKY3gOFMI2yb13z5i3rVx pUbhBrCkzkrSYLLzdhiY/IGhhs2px1oxWKM8NSoA= To: "greg@unrelenting.technology" From: Dan Kotowski Cc: freebsd-arm Reply-To: Dan Kotowski Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X Message-ID: In-Reply-To: <940a6099e971e01bd6d04564d0982b9d@unrelenting.technology> References: <32d1c173d986884efb9b28932c0ead52@unrelenting.technology> <5e1b4bfe845e62bbcd8b827fa37f2b98@unrelenting.technology> <940a6099e971e01bd6d04564d0982b9d@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: 49f0kX2KV1z4GQY X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=a9development.com header.s=protonmail header.b=WFy8J5dY; 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.16 / 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)[]; TO_DN_SOME(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[185.70.40.131:from]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; NEURAL_HAM_LONG(-0.98)[-0.976]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[a9development.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[a9development.com,none]; NEURAL_HAM_SHORT(-1.08)[-1.084]; NEURAL_HAM_MEDIUM(-1.00)[-1.001]; 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: Sat, 06 Jun 2020 00:29:09 -0000 > > > https://gist.github.com/agrajag9/129585436f01876cc4d799382e1c0fac > > > AHCI is looking better and better! I'm going to do a little bit of po= king 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 SM= MU up 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= range minus one". > > > If my brain still works at all: that means we have to do plus one whe= n interpreting it, not minus > > > one more!! :D > > > This causes the first mapping on the PCIe root complex to be used, wh= en we clearly want the second > > > one. > > > Sooo NOW pcie should work! I promise: > > > https://send.firefox.com/download/05a4e22a349f611f/#azClkvNDfZU-PczXS= mNvaQ > > > > Sad trombone https://gist.github.com/agrajag9/eddb36ad44898c070e464e7ad= d59426d > > hmm. The device ID looks correct to me.. but we can check against NetBSD = just in case. > > Can you boot NetBSD with debug messages (boot -x)? > It should print 'ACPI: IORT mapped devid' messages among other things. > > Also.. about the fact that it's showing up as if the PCIe root is outputt= ing to the SMMU, > maybe that really doesn't sound like a bug, more like the firmware modify= ing the table? > (and the interrupt is actually going to the SMMU?) > But I can't find anything like that in the firmware code. > > An ACPI table dump from running FreeBSD might help: /usr/sbin/acpidump -d= t > And for a full binary dump, install acpica-tools > (if you don't want to bother with USB Ethernet and package installs, > just wget the package on another machine and extract it onto the live ima= ge): > https://pkg.freebsd.org/FreeBSD:13:aarch64/latest/All/acpica-tools-202004= 30.txz > and with that, run: /usr/local/bin/acpidump -b > (creates a bunch of binary files in the current directory) > > Also.. try using your self built firmware again? https://gist.github.com/agrajag9/bce229ac6527b21f91c8337d79e1dae9 Well, my own self-built firmware seems to be misbehaving - it's failing to = see the SD reader or throwing errors about `EFI ASSERT` or things like this= : `Synchronous Exception at 0x00000000ED7BD93C` So continuing to use Jon's for now... `acpidump -b` just spat back "Could not get ACPI table at index 1, AE_NOT_F= OUND" `acpidump -dt` worked just fine Also pulled the output of `acpiview` from the EFI shell again since we're u= sing Jon's latest tables.