Date: Fri, 03 Jul 2020 14:52:10 +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: <kkodEYp_933GKBWBelm63luHcdDwaJ9WtfRtjVABbaYbQRXhH1W3w45T4PALvtMXXo6NNWbB7pgRdYZxJDNUHFKibY1FuHqIpPjiXZBAnxs=@a9development.com> In-Reply-To: <C4EFD0F3-FFD0-4789-B976-3DBA00395CCC@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> <aG_BP2g5oB3XsAIQofWKiBCgLpUrPkxZQ6y11ArFprHlTKKvnUDrXRcFPJBAhZWKJMGuGmkEP1QAaRijb4Yv0R2v_4RrmRWyPOtO6jQlAzE=@a9development.com> <C4EFD0F3-FFD0-4789-B976-3DBA00395CCC@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 hav= e terribly quirky hardware (on the RPi4, PCIe can address 3GB only..) > > > Also I would guess that like.. yes, even if PCIe goes through the SMM= U, if the SMMU is untouched by the OS, interrupts should arrive where the O= S 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 u= nder 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 unles= s I intend to use bhyve or something like that? > > > > > > I'm almost surprised that nobody has bumped into this before. How d= oes the IORT look on the MACCHIATObin if interrupts are NOT mapped behind S= MMU? > > > > > > 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, bu= t your posts indicate that the net ifaces on that are basically dead weight= under FreeBSD as well :( > > For a desktop, USB Ethernet is enough :D > > > > Socionext SynQuacer has the PCI node pointed to the ITS node. > > > > 24x A53 cores... hmmm... > > Yeah, very low single core perf, especially for that price :/ > > > > If I'm reading the table disassembly correctly, the Ampere eMAG has P= CI nodes pointing to SMMU (v1/v2). But FreeBSD works there fine! > > > That means the "fallback" non-IORT calculation of RIDs works fine the= re. 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 NetBS= D, dump the IORT there and also try patched (with D25179, e.g. any of my re= cent builds I guess) FreeBSD there? > > > > https://gist.github.com/agrajag9/a59b6c440365745c5a4036e0faf6e23c > > Yeah, so the "old" does have "Output reference : 0x30" under the PCIe roo= ts. For my own edification, let me know if I'm reading this all correctly. >From DEN0049D: "A reference to the output IORT Node. This field contains the address offs= et of the IORT Node relative to the start of the IORT. For example, if this= ID mapping is for a root complex outputting to an SMMU, the value of this field isthe difference between the start ofthe SMMU IORTnode and the start of the IORT." In the old firmware, under the Root Complex Nodes, `Output reference: 0x30`= points to the ITS Node with node offset 0x30. Then in the new firmware, under the Root Copmlex Nodes, `Output reference: 0x48` points to the SMMU with node offset 0x48. Is this what you meant when you said everything is "behind the SMMU"? > So does NetBSD PCIe only work on "old"? Correct. > FreeBSD still not working anywhere? Also correct :( > I guess another interesting thing to check would be Linux configured with= out any SMMU support.. Probably a good test! I'll see if I can make a build without it. As for building my own world... What patches are we applying right now? I think some new builds would be go= od, including one with all the stuff we've fixed - like AHCI - but with the= NXP PCIe code so I can test on the old firmware. If I'm keeping track corr= ectly, this includes: - D20835: enable tagged pointers - D20974: Port sbsawdt drive from NetBSD - D21017: armv8crypto: add AES-XTS support - D24423: arm/pmu: add ACPI attachment, more FDT names - D25145: acpi_resource: support multiple IRQs - D25157: ahci_generic: add quirk for NXP0004 - D25179: acpi_iort: fix mapping end calculation Any others?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?kkodEYp_933GKBWBelm63luHcdDwaJ9WtfRtjVABbaYbQRXhH1W3w45T4PALvtMXXo6NNWbB7pgRdYZxJDNUHFKibY1FuHqIpPjiXZBAnxs=>