FreeBSD on Layerscape/QorIQ LX2160X

[myfreeweb]

On June 30, 2020 7:40:26 PM UTC, Dan Kotowski <dan.kotowski at a9development.com> wrote:
>> > 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
>"""

Well, normally PCIe devices can address all the space, unless you have terribly quirky hardware (on the RPi4, PCIe can address 3GB only..)

Also I would guess that like.. yes, even if PCIe goes through the SMMU, if the SMMU is untouched by the OS, interrupts should arrive where the OS expects it normally.

>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

We're running on bare metal, this is about VMs.

>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?

There is no IORT on the mcbin.. armada8k has a GICv2 not v3 :D

Socionext SynQuacer has the PCI node pointed to the ITS node.

If I'm reading the table disassembly correctly, the Ampere eMAG has PCI nodes pointing to SMMU (v1/v2). But FreeBSD works there fine!
That means the "fallback" non-IORT calculation of RIDs works fine there. But maybe it doesn't on the NXP chip because it's buggy.

But there was *some* way to get the interrupts (without supporting SMMU) on this NXP chip – as evidenced by NetBSD working!

Again.. can you flash the firmware **where PCIe was working under NetBSD**, dump the IORT there and also try patched (with D25179, e.g. any of my recent builds I guess) FreeBSD there?