FreeBSD on Layerscape/QorIQ LX2160X

[greg at unrelenting.technology]

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

>>>> https://gist.github.com/agrajag9/749f504dcac741e902f87c2ea03ae9ac
>>>> From jnettlet:
>>>> BEGIN QUOTE
>>>> the V1 silicon has a SATA errata. I have partially worked around the errata moving some
>>>> configuration into the firmware, but I still need to sort out the remaining bits. Sometimes
>> just
>>>> unplugging and replugging your SATA cable will help to reseat the connector and help. Also it
>> is
>>>> very sensitive to marginal SATA cables.
>>>> END QUOTE
>>>> I played around a bit and could create and destroy GPTs, make filesystems, read and write to
>> said
>>>> filesystems, and hot-plug even seems to work. But I'm not sure if jon's comment really explains
>>>> the
>>>> AHCI error we're still seeing:
>>>> (aprobe3:ahcich3:0:15:0): NOP FLUSHQUEUE. ACB: 00 00 00 00 00 00 00 00 00 00 00 00
>>>> (aprobe3:ahcich3:0:15:0): CAM status: Command timeout
>>>> (aprobe3:ahcich3:0:15:0): Error 5, Retries exhausted
>>> 
>>> I experienced this issue on a cuple of targets (e.g. Zynq-MP or
>>> LS1046A). The port-multiplier quirk flag helped - please try adding:
>>> ahci->quirks |= AHCI_Q_NOPMP;
>>> Build with this + more ITS logging:
>>> https://send.firefox.com/download/cf66ed7f48160529/#LpeMjccv7iqze5hAx_6BrQ
>>> The patch that lets AHCI attach:
>>> https://reviews.freebsd.org/D25145
>> 
>> 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?