FreeBSD on Layerscape/QorIQ LX2160X

[greg at unrelenting.technology]

June 5, 2020 10:18 PM, "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