From owner-freebsd-arm@freebsd.org Thu Jun 18 01:12:54 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 E787E33CDD5 for ; Thu, 18 Jun 2020 01:12:54 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out0.migadu.com (out0.migadu.com [94.23.1.103]) (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 49nP7V0Krlz3YqM for ; Thu, 18 Jun 2020 01:12:53 +0000 (UTC) (envelope-from greg@unrelenting.technology) Date: Thu, 18 Jun 2020 01:12:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unrelenting.technology; s=default; t=1592442766; 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=uucSA8+zx96KHBHoSHR1YxMcUebXRa7asKJGbV8fR1Q=; b=EPhQm7EcuGMDhZgMOD0icY4u6Tn6AviwjGbcDJJmTXBxPfcPp2le/OHrvPPxrsOBhU5ojY qTdgIIvZ0w1rhNq151plXKrqHgENzTPG7fm9p1pPBSbalcu0LaBvtrlaNeyK2T3S5nkliP X9nLPdUoIE7s/36LgDe1CVT955C9tx0= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: myfreeweb To: Dan Kotowski CC: freebsd-arm Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X In-Reply-To: References: <940a6099e971e01bd6d04564d0982b9d@unrelenting.technology> Message-ID: <71481BF5-3972-45A3-8287-FCEB1FCCDC41@unrelenting.technology> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.10 X-Rspamd-Queue-Id: 49nP7V0Krlz3YqM X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=EPhQm7Ec; dmarc=pass (policy=none) header.from=unrelenting.technology; spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 94.23.1.103 as permitted sender) smtp.mailfrom=greg@unrelenting.technology X-Spamd-Result: default: False [-3.54 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.07)[-1.072]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=default]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:94.23.1.103]; NEURAL_HAM_LONG(-0.97)[-0.970]; 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]; DMARC_POLICY_ALLOW(-0.50)[unrelenting.technology,none]; NEURAL_HAM_SHORT(-0.49)[-0.494]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_VERYGOOD(0.00)[94.23.1.103:from]; ASN(0.00)[asn:16276, ipnet:94.23.0.0/16, 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: Thu, 18 Jun 2020 01:12:55 -0000 On June 17, 2020 8:32:36 PM UTC, Dan Kotowski wrote: >> > > By the way, did you get any different firmware builds in the meanti= me? That don't have everything suspiciously routed to the SMMU in IORT=2E= =2E >> > >> > s/suspiciously/by design/ >> > BEGIN QUOTE >> > the PCIe root nodes are hidden from the rich OS with this configurati= on=2E To access the root nodes you need a quirk implemented=2E >> > eventually it will be an option for those that want to run custom ker= nels, but for now this is the solution for the most SBSA like configuration >> > END QUOTE >> >> And how are we supposed to get any MSI-X interrupts in this configurati= on? >> >> Our fallback code for when nothing was matched in IORT (i=2Ee=2E direct= ly using PCIe RID with no offset) did not result in working interrupts=2E >> >> IIRC legacy interrupts didn't work either, but maybe you should retest = them (disabling MSI, MSI-X)=2E > >NSTR, but here you go anyways: https://gist=2Egithub=2Ecom/agrajag9/d4d75= d7dca41b3cb64c0a4243eed4eb7 > >Forgive my n00bishness and feel free to correct me below, I'm still learn= ing my way around down here=2E=2E=2E What are we doing with all the GSIVs i= n the IORT SMMU node? > >Based on reading the table and dmesg=2Eboot, I'm seeing the following: > >* ITS node for gics >* 2 root complex nodes for pci0 and 1, >* Named component nodes for MCE, ugens, mmcs (if we still had that in), a= nd ahcis > >But then the SMMU node has: > >* 64 context interrupts, >* 10 PMU interrupts, and >* 5 ID mappings > >Where do these go? Are we perhaps not walking this section properly and t= hat's the quirk to which Jon is referring? We do not support the SMMU at all=2E (There is a patch for SMMUv3 support = but this chip has a v1/v2=2E) SMMU support should not be mandatory, it's an IOMMU used for virtualizatio= n or additional DMA security protection (like dmar on Intel)=2E NetBSD does not support it either, and they don't seem to have any interru= pt problems=2E=2E In public code (lx2160a master), PCIe interrupts are routed to the ITS aft= er all=2E