Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 01 Jul 2020 17:44:55 +0000
From:      myfreeweb <greg@unrelenting.technology>
To:        Dan Kotowski <dan.kotowski@a9development.com>
Cc:        freebsd-arm <freebsd-arm@freebsd.org>
Subject:   Re: FreeBSD on Layerscape/QorIQ LX2160X
Message-ID:  <A16FE19C-C34D-4100-9229-99FD098F8DE4@unrelenting.technology>
In-Reply-To: <I1KXMCQnSlZ49JcvIWbgOokJWv657vtAL4qs6eukqNEgvruGhpXhShgMklyEt525b191cDqiUxEvCFmaS_SakxoFijsFRYe0pWoGebD7BDs=@a9development.com>
References:  <NkmJNP=5FBMdinQ07E7zvRW9EQtYTkHLISOPlALNNcbFXi7d0dsuvgHD2IW73ptiSh1kEml7=5FVHb9=5FeTIMaLAIeAici=5Fqpz2UyIrBWzXR4mvE=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>?= <I1KXMCQnSlZ49JcvIWbgOokJWv657vtAL4qs6eukqNEgvruGhpXhShgMklyEt525b191cDqiUxEvCFmaS_SakxoFijsFRYe0pWoGebD7BDs=@a9development.com>

next in thread | previous in thread | raw e-mail | index | archive | help


On June 30, 2020 7:40:26 PM UTC, Dan Kotowski <dan=2Ekotowski@a9developmen=
t=2Ecom> wrote:
>> > We do not support the SMMU at all=2E (There is a patch for SMMUv3 sup=
port but this chip has a v1/v2=2E)
>>
>> Appologies for still being new to this, but the following revision impl=
ies to me that we do support SMMU?
>>
>> https://reviews=2Efreebsd=2Eorg/D18002
>>
>> I only barely know what I'm doing down at this level, so maybe I'm just=
 not reading it properly=2E I guess we could throw some debug prints in the=
re too?
>
>Appologies - you were right, the n00b was wrong=2E
>
>```
>#ifdef notyet
>/*
> * Not implemented, map a PCIe device to the SMMU it is associated with=
=2E
> */
>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=2E=2E=2E
>
>I've been reading DEN 0029C on SBSA 6=2E0 but it's not clear to me whethe=
r 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=2E
>
>From section 4=2E1=2E3:
>"""
>Non-secure off-chip devices that cannot directly address all of the Non-s=
ecure address space must be placed
>behind a stage 1 System MMU compatible with the Arm SMMUv2 or SMMUv3 spec=
ification
>"""

Well, normally PCIe devices can address all the space, unless you have ter=
ribly quirky hardware (on the RPi4, PCIe can address 3GB only=2E=2E)

Also I would guess that like=2E=2E 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=2E

>And section 4=2E1=2E6 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=2E

>I'm almost surprised that nobody has bumped into this before=2E How does =
the IORT look on the MACCHIATObin if interrupts are NOT mapped behind SMMU?

There is no IORT on the mcbin=2E=2E armada8k has a GICv2 not v3 :D

Socionext SynQuacer has the PCI node pointed to the ITS node=2E

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

But there was *some* way to get the interrupts (without supporting SMMU) o=
n this NXP chip =E2=80=93 as evidenced by NetBSD working!

Again=2E=2E can you flash the firmware **where PCIe was working under NetB=
SD**, dump the IORT there and also try patched (with D25179, e=2Eg=2E any o=
f my recent builds I guess) FreeBSD there?



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A16FE19C-C34D-4100-9229-99FD098F8DE4>