Date: Sun, 24 May 2020 17:51:59 +0000 From: Dan Kotowski <dan.kotowski@a9development.com> To: "greg@unrelenting.technology" <greg@unrelenting.technology> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X Message-ID: <E--s8_xM_hJJRAijaqxUKLeL7ee6w3e6MiPuJVGhu4Xc1lmiRXbrPdOKFwJRN_Fc3EbNwoT3S96yjD_35P3NAgT0NXwxwIHMWURHBkjVZBE=@a9development.com> In-Reply-To: <b5105ce888b7a91eff50ec9118a910a8@unrelenting.technology> References: <YI70eszO0ei1z8fnsDWQ7Cwt9u63BkXvIDMcBQ0XYj6gwcloNfare1sgktdUeO9cgby8KQk8v7EVqIOVigIwlnrPlcFDYAxgEJKcbZUyi2w=@a9development.com> <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> <b5105ce888b7a91eff50ec9118a910a8@unrelenting.technology>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > I also looked more closely at mps, and actually "just polling I/O" do= es work. We see: > > > mps0: IOCCapabilities: 1285c<ScsiTaskFull,DiagTrace,SnapBuf,EEDP,Tran= sRetry,EventReplay,HostDisc> > > > and that means mps_request_sync (called by mps_get_iocfacts) has work= ed. > > > And the command completion actually seems to come from interrupts. > > > I've heard something about MSI(X) not working for the Linux people (n= ot NetBSD though!), > > > so I guess the next thing to try would be booting with hw.pci.enable_= msi=3D0 hw.pci.enable_msi=3D1 > > > lol, I mean, hw.pci.enable_msi=3D0 hw.pci.enable_msix=3D0 > > > > Still roughly the same: https://gist.github.com/agrajag9/9cb79fe1e53dd6= e8f7dc09fe5f6236e9 > > And NVMe still panics during boot, so pulled that at least for now. > > I wonder if PCIe devices are just not getting interrupts and if that's re= lated to AHCI not being able to configure interrupts. > > Added some debug logging for interrupts: > > https://send.firefox.com/download/828468ac751f8f69/#P1xKgL6IIqFOD-JBQFHnA= w > > (test with mps, don't disable msi I guess since it didn't help) > > Also, to rule out firmware bugs, would be good to test Linux and NetBSD w= ith the same firmware. > (with NVMe, it's something that would definitely get attempted at boot) > > NetBSD -CURRENT: http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/latest/ima= ges/NetBSD-9.99.63-evbarm-aarch64.iso > They don't have memstick images for arm, unfortunately -- idk whether dd'= ing an iso image to a usb drive > would boot, probably not, try tools like rufus maybe. > Or assemble your own memstick with what I assume is just the root filesys= tem image: > http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/latest/evbarm-aarch64/binar= y/gzimg/arm64.img.gz > plus the boot loader you'd have to place on the EFI partition manually > http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/latest/evbarm-aarch64/insta= llation/misc/bootaa64.efi https://gist.github.com/agrajag9/2e07426702d46aa086348b70be942397 Flashing NetBSD to a new card now...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E--s8_xM_hJJRAijaqxUKLeL7ee6w3e6MiPuJVGhu4Xc1lmiRXbrPdOKFwJRN_Fc3EbNwoT3S96yjD_35P3NAgT0NXwxwIHMWURHBkjVZBE=>