Date: Sun, 24 May 2020 14:03:16 +0000 From: greg@unrelenting.technology To: "Warner Losh" <imp@bsdimp.com>, "Dan Kotowski" <dan.kotowski@a9development.com> Cc: "freebsd-arm" <freebsd-arm@freebsd.org> Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X Message-ID: <f5e74382291265f01b2dd29ce9180a55@unrelenting.technology> In-Reply-To: <6E6E4F0C-F85B-428B-B221-C5F704677076@unrelenting.technology> References: <6E6E4F0C-F85B-428B-B221-C5F704677076@unrelenting.technology> <SBSqkdZA-3beqJyVy2tMuk5GRmV22DVVnz_8sNDhYCNOjNPe1wgoiSCoOitGhtlBspk-Gk2MKFv4sUyJKy58mKOBpXrGtZoRQKqmDvB1xIg=@a9development.com> <LqTdXCGMiTFwSobCq9LtV5QVLOZ42AiBDUTC9UrdM67cUlD_I8Y7no-8F7d_vs3VDJwIFJLgHTSZVrbkIXXeZ_-hcU0FxfWj0dr-GvhKXHA=@a9development.com> <b04385d558850dc1dfa60fc398c9ac6c@unrelenting.technology> <CAPv3WKdyOzegfK4NJjKzXQTp9jGV9VkDRWxY%2BhDudzWQKkRfEQ@mail.gmail.com> <3e81db774e0fc1a3c2251c89b7629e1b@unrelenting.technology> <86119565e5927716a9feebabcb611871@unrelenting.technology> <f801aa134da12d1b4a34b87dbc180b4a@unrelenting.technology> <37858865a8ebddd3fe1e3a228a19ef62@unrelenting.technology> <7066da0bc417ed047dc27b4741c90e81@unrelenting.technology> <xoiJF1ZUP3-rgbxC8ZmJGQNpsJSyK4zsAXhbLl8Ml96Da1lBPGwPqn0ANf7q-GgthPAWePSR9QDCM5vKysd_3e2aGtp-0egUXu6AW3bhLDg=@a9development.com> <CANCZdfqbd_u35toFYKr4LKkCBwnRhutM5knjnVcGR018Jfo1Vw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
May 23, 2020 4:46 AM, "myfreeweb" <greg@unrelenting.technology> wrote:=0A= =0A> You can see that in the gist: "NVME polled command failed to complet= e within 1s"=0A> =0A> Same as before (with straight ECAM).=0A> =0A> Looks= like straight ECAM *is* supposed to work, after all (with limitations on= bifurcation or=0A> something, I've heard). The code I'm porting from Net= BSD does use that same ECAM space when=0A> touching non-0 busses.=0A> =0A= > Whoops, I might've been working on increasing features instead of fixin= g bugs.. :D=0A> =0A> It's odd that what's failing is just polling I/O wit= h the devices, and after successful reads. Does=0A> that smell like cache= issues or something?=0A=0AI was wondering about NetBSD's usage of _ARM_B= US_SPACE_MAP_STRONGLY_ORDERED,=0Abut that's just their flag for using Dev= ice_nGnRnE instead of Device_nGnRE.=0AWe always use Device_nGnRnE.=0A(Pro= bably leaving some performance on the table for non-PCIe devices..)=0A=0A= =0AAlso, comparing the dsdt for the LX2160A vs. Armada8k:=0A=0Ahttps://gi= thub.com/SolidRun/edk2-platforms/blob/eec706c2d693be0b3793d9180e7d1a4813a= 526cf/Silicon/NXP/LX2160A/AcpiTables/Dsdt/Pci.asl=0Ahttps://github.com/ti= anocore/edk2-platforms/blob/7a4035e9efd890215c88ccbc645b7e9e3671779f/Sili= con/Marvell/Armada7k8k/AcpiTables/Armada80x0McBin/Dsdt.asl#L308=0A=0ALX21= 60A only offers bus numbers and 64-bit MMIO, while Armada8k also offers 3= 2-bit MMIO and translated I/O ports.=0ASo some of the pci_host_generic_co= re_alloc_resource FAILs are expected I guess.=0A=0AInterestingly, NetBSD = has never complained about this, see dmesgs:=0A=0Aearly: http://www.netbs= d.org/~jmcneill/lx2k.txt=0Aafter adding special support: https://dmesgd.n= ycbug.org/index.cgi?do=3Dview&id=3D5335=0A=0Aand the config space support= seems to have fixed everything for them (??)=0A=0A=0AI also looked more = closely at mps, and actually "just polling I/O" does work. We see:=0Amps0= : IOCCapabilities: 1285c<ScsiTaskFull,DiagTrace,SnapBuf,EEDP,TransRetry,E= ventReplay,HostDisc>=0Aand that means mps_request_sync (called by mps_get= _iocfacts) has worked.=0A=0AAnd the command completion actually seems to = come from interrupts.=0A=0AI've heard something about MSI(X) not working = for the Linux people (not NetBSD though!),=0Aso I guess the next thing to= try would be booting with hw.pci.enable_msi=3D0 hw.pci.enable_msi=3D1
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f5e74382291265f01b2dd29ce9180a55>