Date: Thu, 18 Jun 2020 01:12:42 +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: <71481BF5-3972-45A3-8287-FCEB1FCCDC41@unrelenting.technology> In-Reply-To: <z-iiKTafA-iirmiH_wVWUM9BHEa9uhccyljIc5_buK8CgCdzAXdUgQuViiaULImI0BVmx9N3lKO_9_NN9IHfSYCv1H9W9P8n98ltXG02MT4=@a9development.com> References: <NkmJNP_BMdinQ07E7zvRW9EQtYTkHLISOPlALNNcbFXi7d0dsuvgHD2IW73ptiSh1kEml7_VHb9_eTIMaLAIeAici_qpz2UyIrBWzXR4mvE=@a9development.com> <c1788ee7f14b9236e0972909032cb8fd@unrelenting.technology> <940a6099e971e01bd6d04564d0982b9d@unrelenting.technology> <c1e4129989005bc9bfd117988019107d@unrelenting.technology> <XYXpaNQ3XeZR6g5RpmjR3qs56wTKfNi_OpPX53S3yYdPMNMWR0kme-Q7hmNpxzR6EL3DqKxUnG8BcW6ueHv82Kaexu1j4VSLtNtQgYuxX_g=@a9development.com> <eRSoUazwekUoXHKtXhs_unN_78Zp3ow_uJ8j-ODdb7mgzz3n8L18wonbrqkmPn2ulVXoUKxHLh8Cc0VU6KMeIEm3X0KsPn8NH-JiqKmq8fI=@a9development.com> <D2780D27-20F4-4706-9956-7E188AD73F62@unrelenting.technology> <iIPsVK-flf-29Ti4agFHulCx5v1aEOVnPY6tyxErDGGxUlRvonYC7xCUGxHNgH64ZOpBLbwzAubg8gARrYPgd8qLOVfFk1PmcxSp0QNB_js=@a9development.com> <BE2611FE-FC83-4E3D-9977-E502DE8537A7@unrelenting.technology> <z-iiKTafA-iirmiH_wVWUM9BHEa9uhccyljIc5_buK8CgCdzAXdUgQuViiaULImI0BVmx9N3lKO_9_NN9IHfSYCv1H9W9P8n98ltXG02MT4=@a9development.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On June 17, 2020 8:32:36 PM UTC, Dan Kotowski <dan=2Ekotowski@a9developmen= t=2Ecom> wrote: >> > > By the way, did you get any different firmware builds in the meanti= me? That don't have everything suspiciously routed to the SMMU in IORT=2E= =2E >> > >> > s/suspiciously/by design/ >> > BEGIN QUOTE >> > the PCIe root nodes are hidden from the rich OS with this configurati= on=2E To access the root nodes you need a quirk implemented=2E >> > eventually it will be an option for those that want to run custom ker= nels, but for now this is the solution for the most SBSA like configuration >> > END QUOTE >> >> And how are we supposed to get any MSI-X interrupts in this configurati= on? >> >> Our fallback code for when nothing was matched in IORT (i=2Ee=2E direct= ly using PCIe RID with no offset) did not result in working interrupts=2E >> >> IIRC legacy interrupts didn't work either, but maybe you should retest = them (disabling MSI, MSI-X)=2E > >NSTR, but here you go anyways: https://gist=2Egithub=2Ecom/agrajag9/d4d75= d7dca41b3cb64c0a4243eed4eb7 > >Forgive my n00bishness and feel free to correct me below, I'm still learn= ing my way around down here=2E=2E=2E What are we doing with all the GSIVs i= n the IORT SMMU node? > >Based on reading the table and dmesg=2Eboot, I'm seeing the following: > >* ITS node for gics >* 2 root complex nodes for pci0 and 1, >* Named component nodes for MCE, ugens, mmcs (if we still had that in), a= nd ahcis > >But then the SMMU node has: > >* 64 context interrupts, >* 10 PMU interrupts, and >* 5 ID mappings > >Where do these go? Are we perhaps not walking this section properly and t= hat's the quirk to which Jon is referring? We do not support the SMMU at all=2E (There is a patch for SMMUv3 support = but this chip has a v1/v2=2E) SMMU support should not be mandatory, it's an IOMMU used for virtualizatio= n or additional DMA security protection (like dmar on Intel)=2E NetBSD does not support it either, and they don't seem to have any interru= pt problems=2E=2E In public code (lx2160a master), PCIe interrupts are routed to the ITS aft= er all=2E
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?71481BF5-3972-45A3-8287-FCEB1FCCDC41>