FreeBSD on Layerscape/QorIQ LX2160X

[Dan Kotowski]

> > 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 implies 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 not reading it properly. I guess we could throw some debug prints in there too?

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)
{
	/* XXX: convert oref to SMMU device */
	return (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-secure address space must be placed
behind a stage 1 System MMU compatible with the Arm SMMUv2 or SMMUv3 specification
"""

And section 4.1.6 System MMU and Device Assignment
"""
If a device is assigned and passed through to an operating system under a hypervisor, then the memory
transactions of the device must be subject to stage 2 translation, allocation 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 compatible 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?