Date: Sun, 24 May 2020 16:46:23 +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: <b5105ce888b7a91eff50ec9118a910a8@unrelenting.technology> In-Reply-To: <YI70eszO0ei1z8fnsDWQ7Cwt9u63BkXvIDMcBQ0XYj6gwcloNfare1sgktdUeO9cgby8KQk8v7EVqIOVigIwlnrPlcFDYAxgEJKcbZUyi2w=@a9development.com> References: <YI70eszO0ei1z8fnsDWQ7Cwt9u63BkXvIDMcBQ0XYj6gwcloNfare1sgktdUeO9cgby8KQk8v7EVqIOVigIwlnrPlcFDYAxgEJKcbZUyi2w=@a9development.com> <f5e74382291265f01b2dd29ce9180a55@unrelenting.technology> <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> <664db38a87ea8803be72af9738534994@unrelenting.technology>
next in thread | previous in thread | raw e-mail | index | archive | help
May 24, 2020 6:11 PM, "Dan Kotowski" <dan.kotowski@a9development.com> wro= te:=0A=0A>> I also looked more closely at mps, and actually "just polling= I/O" does work. We see:=0A>> mps0: IOCCapabilities: 1285c<ScsiTaskFull,D= iagTrace,SnapBuf,EEDP,TransRetry,EventReplay,HostDisc>=0A>> and that mean= s mps_request_sync (called by mps_get_iocfacts) has worked.=0A>> And the = command completion actually seems to come from interrupts.=0A>> I've hear= d something about MSI(X) not working for the Linux people (not NetBSD tho= ugh!),=0A>> so I guess the next thing to try would be booting with hw.pci= .enable_msi=3D0 hw.pci.enable_msi=3D1=0A>> =0A>> lol, I mean, hw.pci.enab= le_msi=3D0 hw.pci.enable_msix=3D0=0A> =0A> Still roughly the same: https:= //gist.github.com/agrajag9/9cb79fe1e53dd6e8f7dc09fe5f6236e9=0A> =0A> And = NVMe still panics during boot, so pulled that at least for now.=0A=0AI wo= nder if PCIe devices are just not getting interrupts and if that's relate= d to AHCI not being able to configure interrupts.=0A=0AAdded some debug l= ogging for interrupts:=0A=0Ahttps://send.firefox.com/download/828468ac751= f8f69/#P1xKgL6IIqFOD-JBQFHnAw=0A=0A(test with mps, don't disable msi I gu= ess since it didn't help)=0A=0AAlso, to rule out firmware bugs, would be = good to test Linux and NetBSD with the same firmware.=0A(with NVMe, it's = something that would definitely get attempted at boot)=0A=0ANetBSD -CURRE= NT: http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/latest/images/NetBSD-9.= 99.63-evbarm-aarch64.iso=0AThey don't have memstick images for arm, unfor= tunately -- idk whether dd'ing an iso image to a usb drive=0Awould boot, = probably not, try tools like rufus maybe.=0AOr assemble your own memstick= with what I assume is just the root filesystem image:=0Ahttp://nycdn.net= bsd.org/pub/NetBSD-daily/HEAD/latest/evbarm-aarch64/binary/gzimg/arm64.im= g.gz=0Aplus the boot loader you'd have to place on the EFI partition manu= ally=0Ahttp://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/latest/evbarm-aarch6= 4/installation/misc/bootaa64.efi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b5105ce888b7a91eff50ec9118a910a8>