Date: Tue, 30 Jun 2020 19:40:26 +0000 From: Dan Kotowski <dan.kotowski@a9development.com> To: Dan Kotowski <dan.kotowski@a9development.com> Cc: myfreeweb <greg@unrelenting.technology>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X Message-ID: <I1KXMCQnSlZ49JcvIWbgOokJWv657vtAL4qs6eukqNEgvruGhpXhShgMklyEt525b191cDqiUxEvCFmaS_SakxoFijsFRYe0pWoGebD7BDs=@a9development.com> In-Reply-To: <eyZHRYLN2BiJyqcniJaXO3a9t3gYfu1ktXO1UrQPzs--VScA-7VyK6jXUSgZAo6vL95HydVFsLpWJ5I0tejqLsWgL2RrKT9ATWdRqyswKx8=@a9development.com> References: =?us-ascii?Q?<NkmJNP=5FBMdinQ07E7zvRW9EQtYTkHLISOPlALNNcbFXi7d0dsuvgHD2IW73ptiSh1kEml7=5FVHb9=5FeTIMaLAIeAici=5Fqpz2UyIrBWzXR4mvE=3D@a9development.com>_<c1e4129989005bc9bfd117988019107d@unrelenting.technology>_<XYXpaNQ3XeZR6g5RpmjR3qs56wTKfNi=5FOpPX53S3yYdPMNMWR0kme-Q7hmNpxzR6EL3DqKxUnG8BcW6ueHv82Kaexu1j4VSLtNtQgYuxX=5Fg=3D@a9development.com>_<eRSoUazwekUoXHKtXhs=5FunN=5F78Zp3ow=5FuJ8j-ODdb7mgzz3n8L18wonbrqkmPn2ulVXoUKxHLh8Cc0VU6KMeIEm3X0KsPn8NH-JiqKmq8fI=3D@a9development.com>_<D2780D27-20F4-4706-9956-7E188AD73F62@unrelenting.technology>_<iIPsVK-flf-29Ti4agFHulCx5v1aEOVnPY6tyxErDGGxUlRvonYC7xCUGxHNgH64ZOpBLbwzAubg8gARrYPgd8qLOVfFk1PmcxSp0QNB=5Fjs=3D@a9development.com>_<BE2611FE-FC83-4E3D-9977-E502DE8537A7@unrelenting.technology>_<z-iiKTafA-iirmiH=5FwVWUM9BHEa9uhccyljIc5=5FbuK8CgCdzAXdUgQuViiaULImI0BVmx9N3lKO=5F9=5FNN9IHfSYCv1H9W9P8n98ltXG02MT4=3D@a9development.com>_<71481BF5-3972-45A3-8287-FCEB1FCCDC41@unrelenting.technology>_<eyZHRYLN2BiJyqcniJaXO3a9t3gYfu1ktXO1UrQPzs--VScA-7VyK6?= =?us-ascii?Q?jXUSgZAo6vL95HydVFsLpWJ5I0tejqLsWgL2RrKT9ATWdRqyswKx8=3D@a9development.com>?=
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?I1KXMCQnSlZ49JcvIWbgOokJWv657vtAL4qs6eukqNEgvruGhpXhShgMklyEt525b191cDqiUxEvCFmaS_SakxoFijsFRYe0pWoGebD7BDs=>