FreeBSD on Layerscape/QorIQ LX2160X

[greg at unrelenting.technology]

May 24, 2020 10:08 PM, "Dan Kotowski" <dan.kotowski at a9development.com> wrote:

> Booted with NetBSD -current
> Generic 64-bit
> Build: 202005232000Z
> SHA256: c64278c292489674215f9ecd335f2cbf01b99c2886f03a76b24415cd1c24d255
> 
> https://gist.github.com/agrajag9/6f2c986c99fbca413e60cf608a453a00
> 
> Found the onboard eMMC (sdmmc1), so that's nice. But it panicked with the SAS HBA attached. Removed
> it and wired a drive straight up to the SATA ports, but fdisk doesn't like it. Smelling more like a
> firmware problem now...

What was the panic? How about with the NVMe drive?

It's quite possible that the SATA controller on this hardware is buggy and
not fully standards compliant (there are fsl_ahci drivers after all for NXP stuff),
but what's weird is that we're failing so early, with interrupt configuration.
It's.. interesting that there are *three* interrupts for the controller.
I do have a suspicion related to this now..

https://send.firefox.com/download/e2f1b3825db111ff/#hOc-bD4J3Wj1yyJSb-3pSQ

This new build might do something about AHCI.
Also PMU should be fixed, I would appreciate it if you tested it
(kldload hwpmc; pmcstat -S INST_RETIRED -T; wait a few seconds, it should show samples)

Back to your previous FreeBSD log:

> https://gist.github.com/agrajag9/2e07426702d46aa086348b70be942397

MPS INTERRUPT!
intr_setup_irq(): irq 288 add handler error 0 on mps0

I'm not sure why the interrupt handler prints before intr_setup_irq o_0
but it was called, right after the IOCCapabilities line when we want it,
so now I'm less inclined to think that the PCIe bug is interrupts not working..

Maybe some config writes aren't taking effect after all but in that case I would expect
more spectacular explosions earlier in the boot process.

I've sent a link to a known firmware build before:
https://drive.google.com/file/d/1yXSS1O1U8CmtwaIPfxNDkzhAClJGvErK/view
Have you tried it? Any difference in FreeBSD/NetBSD, with NVMe?