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"

`acpidump -dt` worked just fine

Also pulled the output of `acpiview` from the EFI shell again since we're using Jon's latest tables.