Date: Wed, 01 Jul 2020 21:37:56 +0000 From: Dan Kotowski <dan.kotowski@a9development.com> To: myfreeweb <greg@unrelenting.technology> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X Message-ID: <aG_BP2g5oB3XsAIQofWKiBCgLpUrPkxZQ6y11ArFprHlTKKvnUDrXRcFPJBAhZWKJMGuGmkEP1QAaRijb4Yv0R2v_4RrmRWyPOtO6jQlAzE=@a9development.com> In-Reply-To: <A16FE19C-C34D-4100-9229-99FD098F8DE4@unrelenting.technology> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
> Well, normally PCIe devices can address all the space, unless you have te= rribly quirky hardware (on the RPi4, PCIe can address 3GB only..) > > Also I would guess that like.. yes, even if PCIe goes through the SMMU, i= f the SMMU is untouched by the OS, interrupts should arrive where the OS ex= pects 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. 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. 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 I'm also interested in acquiring one of those as well at some point, but yo= ur posts indicate that the net ifaces on that are basically dead weight und= er FreeBSD as well :( > Socionext SynQuacer has the PCI node pointed to the ITS node. 24x A53 cores... hmmm... > If I'm reading the table disassembly correctly, the Ampere eMAG has PCI n= odes 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 =E2=80=93 as evidenced by NetBSD working! > > Again.. can you flash the firmware where PCIe was working under NetBSD, d= ump the IORT there and also try patched (with D25179, e.g. any of my recent= builds I guess) FreeBSD there? https://gist.github.com/agrajag9/a59b6c440365745c5a4036e0faf6e23c With old and new firmwares: EFI shell acpiview output acpidump -b (tarred, gzipped, and uuencoded) acpidump -dt And in case you need it, here's the IORT aslc used in the old firmware buil= d: https://github.com/agrajag9/edk2-platforms/blob/master-lx2160a/Silicon/NXP/= LX2160A/AcpiTables/Iort.aslc
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?aG_BP2g5oB3XsAIQofWKiBCgLpUrPkxZQ6y11ArFprHlTKKvnUDrXRcFPJBAhZWKJMGuGmkEP1QAaRijb4Yv0R2v_4RrmRWyPOtO6jQlAzE=>