FreeBSD on Layerscape/QorIQ LX2160X

[greg at unrelenting.technology]

June 6, 2020 3:28 AM, "Dan Kotowski" <dan.kotowski at a9development.com> wrote:

>>> 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.

> `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?

> [   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.