From owner-freebsd-arm@freebsd.org Tue Jun 30 19:40: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 60F85354B80 for ; Tue, 30 Jun 2020 19:40:35 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch [185.70.40.134]) (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 49xF820RQNz3cmy for ; Tue, 30 Jun 2020 19:40:33 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Date: Tue, 30 Jun 2020 19:40:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=a9development.com; s=protonmail; t=1593546031; bh=pMt/1RJYFC1Pzm5BkfGhw6Gs4jpghM3k8hYfACQc/aw=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=GDVHZ/vVGX/IrJobe1beR0qiMQDevdsPPdEU6MO3UXH2UQVkLlAJyOjJnrPatHxFC 1rjm4vjCa+9ZXN+eXfnY/GnTpam7uUfuwgwSt7SC6NTE2SqRSdEDW1qkT2zTLkYWFl vqM3zB4Q9yx0h5z1pKmbL+jd71fp7vf5ZF2n1emE= To: Dan Kotowski From: Dan Kotowski Cc: myfreeweb , freebsd-arm Reply-To: Dan Kotowski Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X Message-ID: In-Reply-To: References: =?us-ascii?Q?________<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-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: 49xF820RQNz3cmy X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=a9development.com header.s=protonmail header.b=GDVHZ/vV; dmarc=pass (policy=none) header.from=a9development.com; spf=pass (mx1.freebsd.org: domain of dan.kotowski@a9development.com designates 185.70.40.134 as permitted sender) smtp.mailfrom=dan.kotowski@a9development.com X-Spamd-Result: default: False [-3.34 / 15.00]; HAS_REPLYTO(0.00)[dan.kotowski@a9development.com]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[a9development.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; NEURAL_HAM_LONG(-0.97)[-0.973]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-0.99)[-0.987]; RWL_MAILSPIKE_POSSIBLE(0.00)[185.70.40.134:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[a9development.com:+]; DMARC_POLICY_ALLOW(-0.50)[a9development.com,none]; NEURAL_HAM_SHORT(-0.28)[-0.280]; 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.134: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: Tue, 30 Jun 2020 19:40:35 -0000 > > We do not support the SMMU at all. (There is a patch for SMMUv3 support= but this chip has a v1/v2.) > > Appologies for still being new to this, but the following revision implie= s to me that we do support SMMU? > > https://reviews.freebsd.org/D18002 > > I only barely know what I'm doing down at this level, so maybe I'm just n= ot reading it properly. I guess we could throw some debug prints in there t= oo? Appologies - you were right, the n00b was wrong. ``` #ifdef notyet /* * Not implemented, map a PCIe device to the SMMU it is associated with. */ int acpi_iort_map_smmu(u_int seg, u_int devid, void **smmu, u_int *sid) { =09/* XXX: convert oref to SMMU device */ =09return (ENXIO); } #endif ``` That's been effectively a stub since Nov 2018... I've been reading DEN 0029C on SBSA 6.0 but it's not clear to me whether we= need this for all SBSA-compliant systems or if this is just a decision Jon= and SR are making and claiming it's necessary. >From section 4.1.3: """ Non-secure off-chip devices that cannot directly address all of the Non-sec= ure address space must be placed behind a stage 1 System MMU compatible with the Arm SMMUv2 or SMMUv3 specif= ication """ And section 4.1.6 System MMU and Device Assignment """ If a device is assigned and passed through to an operating system under a h= ypervisor, then the memory transactions of the device must be subject to stage 2 translation, allocati= on of memory attributes, and application of permission checks, under the control of the hypervisor. This= specification collectively refers to this translation, attribution, and permission checking as policing. The act= of policing is referred to as stage 2 System MMU functionality. Stage 2 System MMU functionality must be provided by a System MMU compatibl= e with the Arm SMMUv2 specification """ I'm almost surprised that nobody has bumped into this before. How does the = IORT look on the MACCHIATObin if interrupts are NOT mapped behind SMMU?