Date: Thu, 02 Jul 2020 01:55:02 +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: <C4EFD0F3-FFD0-4789-B976-3DBA00395CCC@unrelenting.technology> In-Reply-To: <aG_BP2g5oB3XsAIQofWKiBCgLpUrPkxZQ6y11ArFprHlTKKvnUDrXRcFPJBAhZWKJMGuGmkEP1QAaRijb4Yv0R2v_4RrmRWyPOtO6jQlAzE=@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> <I1KXMCQnSlZ49JcvIWbgOokJWv657vtAL4qs6eukqNEgvruGhpXhShgMklyEt525b191cDqiUxEvCFmaS_SakxoFijsFRYe0pWoGebD7BDs=@a9development.com> <A16FE19C-C34D-4100-9229-99FD098F8DE4@unrelenting.technology> <aG_BP2g5oB3XsAIQofWKiBCgLpUrPkxZQ6y11ArFprHlTKKvnUDrXRcFPJBAhZWKJMGuGmkEP1QAaRijb4Yv0R2v_4RrmRWyPOtO6jQlAzE=@a9development.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On July 1, 2020 9:37:56 PM UTC, Dan Kotowski <dan=2Ekotowski@a9development= =2Ecom> wrote: >> Well, normally PCIe devices can address all the space, unless you have = terribly 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 S= MMU, 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 und= er a hypervisor, then the memory >> >> We're running on bare metal, this is about VMs=2E > >So even though that stub only returns ENXIO, it should not matter unless = I intend to use bhyve or something like that? > >> > I'm almost surprised that nobody has bumped into this before=2E How d= oes the IORT look on the MACCHIATObin if interrupts are NOT mapped behind S= MMU? >> >> There is no IORT on the mcbin=2E=2E armada8k has a GICv2 not v3 :D > >I'm also interested in acquiring one of those as well at some point, but = your posts indicate that the net ifaces on that are basically dead weight u= nder FreeBSD as well :( For a desktop, USB Ethernet is enough :D >> Socionext SynQuacer has the PCI node pointed to the ITS node=2E > >24x A53 cores=2E=2E=2E hmmm=2E=2E=2E Yeah, very low single core perf, especially for that price :/ >> If I'm reading the table disassembly correctly, the Ampere eMAG has PCI= nodes 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) = on this NXP chip =E2=80=93 as evidenced by NetBSD working! >> >> Again=2E=2E can you flash the firmware where PCIe was working under Net= BSD, dump the IORT there and also try patched (with D25179, e=2Eg=2E any of= my recent builds I guess) FreeBSD there? > >https://gist=2Egithub=2Ecom/agrajag9/a59b6c440365745c5a4036e0faf6e23c Yeah, so the "old" does have "Output reference : 0x30" under the PCIe root= s=2E So does NetBSD PCIe only work on "old"? FreeBSD still not working anywhere? I guess another interesting thing to check would be Linux configured witho= ut any SMMU support=2E=2E
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C4EFD0F3-FFD0-4789-B976-3DBA00395CCC>