FreeBSD on Layerscape/QorIQ LX2160X

[Dan Kotowski]

> > > > https://gist.github.com/agrajag9/129585436f01876cc4d799382e1c0fac
> > > > AHCI is looking better and better! I'm going to do a little bit of poking at that SATA HDD just
> > > > to
> > > > see how stable it really is.
> > > > Posted quirk patch:https://reviews.freebsd.org/D25157
> > > > Back to PCI: hmm, maybe the reason that IORT parsing weirdly picks SMMU up is that ranges with
> > > > .NumIds=0 end up
> > > > with end before the beginning..
> > > > mapping->end = map_entry->InputBase + map_entry->IdCount - 1;
> > > > The ARM document DEN0049D says the field is "The number of IDs in the range minus one".
> > > > If my brain still works at all: that means we have to do plus one when interpreting it, not minus
> > > > one more!! :D
> > > > This causes the first mapping on the PCIe root complex to be used, when we clearly want the
> > > > second
> > > > one.
> > > > Sooo NOW pcie should work! I promise:
> > > > https://send.firefox.com/download/05a4e22a349f611f/#azClkvNDfZU-PczXSmNvaQ
> > >
> > > Sad trombone https://gist.github.com/agrajag9/eddb36ad44898c070e464e7add59426d
> > > hmm. The device ID looks correct to me.. but we can check against NetBSD just in case.
> > > Can you boot NetBSD with debug messages (boot -x)?
> > > It should print 'ACPI: IORT mapped devid' messages among other things.
> > > Also.. about the fact that it's showing up as if the PCIe root is outputting to the SMMU,
> > > maybe that really doesn't sound like a bug, more like the firmware modifying the table?
> > > (and the interrupt is actually going to the SMMU?)
> > > But I can't find anything like that in the firmware code.
> > > An ACPI table dump from running FreeBSD might help: /usr/sbin/acpidump -dt
> > > And for a full binary dump, install acpica-tools
> > > (if you don't want to bother with USB Ethernet and package installs,
> > > just wget the package on another machine and extract it onto the live image):
> > > https://pkg.freebsd.org/FreeBSD:13:aarch64/latest/All/acpica-tools-20200430.txz
> > > and with that, run: /usr/local/bin/acpidump -b
> > > (creates a bunch of binary files in the current directory)
> > > Also.. try using your self built firmware again?
> >
> > https://gist.github.com/agrajag9/bce229ac6527b21f91c8337d79e1dae9
> > Well, my own self-built firmware seems to be misbehaving - it's failing to see the SD reader or
> > throwing errors about `EFI ASSERT` or things like this:
> > `Synchronous Exception at 0x00000000ED7BD93C`
> > So continuing to use Jon's for now...
> > `acpidump -b` just spat back "Could not get ACPI table at index 1, AE_NOT_FOUND"
>
> That's normal, it still creates files in the current directory..
> But okay, the acpiview is good enough.

D'oh!

> > `acpidump -dt` worked just fine
> > Also pulled the output of `acpiview` from the EFI shell again since we're using Jon's latest
> > tables.
>
> lol, 0x30 == decimal 48. ITS node is at 0x30, SMMU at 0x48 (72). How not confusing!
>
> Yeah so the PCIe root nodes are indeed pointing at the SMMU, while that's not supposed to be the case in the public code:
> https://github.com/SolidRun/edk2-platforms/blob/eec706c2d693be0b3793d9180e7d1a4813a526cf/Silicon/NXP/LX2160A/AcpiTables/Iort.aslc#L220
>
> Hence my hypothesis that Jon was experimenting with enabling the SMMU in that build :)
>
> Maybe try the firmware from that google drive link?

My old one worked this time? I really couldn't tell you what I did differently, but this isn't the first time where I had seemingly non-deterministic boot problems that go away when I swap firmwares.

> > [ 1.0000030] panic: Trap: Data Abort (EL1): Translation Fault L0 with read access for 0000000000000300: pc ffffc000004aca34: opcode f8607a74: ldr x20, [x19,x0,lsl #3]
>
> Right, damn, Jon said that on the new firmware, OSes with the custom layerscape PCIe driver won't work.

D'oh again!

Now, here's something different - this time when loading the mps driver, it failed back to the shell. In all prior testing it would just hang forever.

Also, bye-bye ahci without Jon's ECAM fix :/

https://gist.github.com/agrajag9/64c7070a40135f397a9dc8d841954590