Date: Fri, 05 Jun 2020 00:18:17 +0000 From: 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: <a727f3c05b234218e053c53100b539f0@unrelenting.technology> In-Reply-To: <X6Vv06P26Vw5_LcsszpoJBBekBEtVOPLYn9JD5u7GmGzmpL19PqD21yZAb4Nm5-HpelPppbh8LAV7Cs5Amefzsx_kjJsy8LrmHH9mSRxuCY=@a9development.com> References: <X6Vv06P26Vw5_LcsszpoJBBekBEtVOPLYn9JD5u7GmGzmpL19PqD21yZAb4Nm5-HpelPppbh8LAV7Cs5Amefzsx_kjJsy8LrmHH9mSRxuCY=@a9development.com> <ePx99n--NpqSdQxbdbM3B2qgpSXi0Gjvhspj566br-72pDug8bfXbCXAjnd68jPO2h1bWxkyPDpq5y2BzStbS38-MKkhwMzJI3uHhWcmP_g=@a9development.com> <b5105ce888b7a91eff50ec9118a910a8@unrelenting.technology> <8951311F-77F7-40B8-AEA0-F8CBCB1A05DE@yahoo.com> <4ad62e6669044f82e71a9d86fd493356@unrelenting.technology> <ShdSNL8XDgj0KtPR4v8nn1ohjVssrnoUQGwNL-gHOpylio7Eo5J_WjA2Ko9YjV5md64MeFz017Ts01KUnpJa3Xpw4y_PncL4e5cfUcotRWM=@a9development.com> <31D3FA64-8296-4CA5-92A2-F7FE7C4AE981@unrelenting.technology> <ZdPk7zJSE8UvoonkTixa2gV04ujgKfY93A71fz8cTB6ZPjt2uSCD5TdvFzDAEIR9Tu5LoGrcZLmXqgyrCmzh8OIB2JLc4gNKr6xF0pe931M=@a9development.com> <32d1c173d986884efb9b28932c0ead52@unrelenting.technology> <5e1b4bfe845e62bbcd8b827fa37f2b98@unrelenting.technology>
next in thread | previous in thread | raw e-mail | index | archive | help
June 5, 2020 12:37 AM, "Dan Kotowski" <dan.kotowski@a9development.com> wr= ote:=0A=0A>> Oops, I've been adding some debug prints to gicv2 not gicv3.= =0A>> =0A>> One thing I noticed is the interesting irq number the nvme ad= min queue gets..=0A>> it's the same as gic_nirqs.=0A>> =0A>> gic0: SPIs: = 288, IDs: 65535=0A>> nvme0: attempting to allocate 17 MSI-X vectors (33 s= upported)=0A>> nvme0: using IRQs 21-37 for MSI-X=0A>> acpi0: allocating v= ia sysres: res 0xfffffd0000726280, start 21 + count 1 - 1 =3D? end 21=0A>= > intr_setup_irq(): irq 288 add handler error 0 on nvme0=0A>> =0A>> maybe= that's just like.. the first ITS handled interrupt?=0A>> (funnily enough= , NetBSD lists MSIs as IRQs starting from 8192)=0A>> =0A>> More SATA debu= gging: https://send.firefox.com/download/9de5357a2e58edd9/#s9ZaU_k2NHlO-t= LdyGk5iA=0A> =0A> https://gist.github.com/agrajag9/1aaf18f48ee883b917907d= d417803711=0A> =0A> We have SATA!=0A=0AWow that was silly.=0A=0AFreeBSD d= id not support multiple interrupts in an ACPI device, at all.=0ASince for= ever, nobody else has needed this, apparently.=0AIt's really stupid that = the error was returned this quietly >_<=0A=0AIn the build below, it would= try to attach all interrupts, not just the first one.=0AIf that succeeds= , I'll post that as a patch.=0A=0A> NVMe and mps still cause hangs, but p= rogress is progress!=0A=0AWell I didn't say I've tried to actually fix PC= Ie interrupts yet,=0Abut I did add some debug logging that seems to be us= eful.=0ANamely, IORT stuff. IORT is the ACPI table describing how interru= pts flow.=0A=0AAaaand this is concerning:=0A=0Aiort: Found PCI RC node wi= th segment and device ID. its? 1 smmu3? 0 smmu? 1 | nxtid 6400 rid 256=0A= iort: entry lookup fail=0A=0AWait a second, SMMU, that's not what IORT sa= ys the PCI nodes output to!=0A=0Ahttps://github.com/SolidRun/edk2-platfor= ms/blob/eec706c2d693be0b3793d9180e7d1a4813a526cf/Silicon/NXP=0ALX2160A/Ac= piTables/Iort.aslc=0A=0A.PciRcNode[0] =3D { .PciRcIdMapping =3D { ...=0A.= OutputReference =3D OFFSET_OF (NXP_EFI_ACPI_6_0_IO_REMAPPING_TABLE, ItsNo= de), },=0A=0ALooks like our IORT parsing might be busted!=0A=0AThe new bu= ild should output more info and force usage of the ITS node.=0ASo if that= was the issue, and I did the forcing correctly, you should have PCIe int= errupts working now :)=0A=0A(btw: NetBSD for now doesn't care about Outpu= tReference at all, lol)=0A=0Ahttps://send.firefox.com/download/d655b27c2b= d73021/#O9tR6di9HbS8FHp0isgFkA
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a727f3c05b234218e053c53100b539f0>