Date: Fri, 05 Jun 2020 21:53:10 +0000 From: Dan Kotowski <dan.kotowski@a9development.com> To: "greg@unrelenting.technology" <greg@unrelenting.technology> Cc: freebsd-arm <freebsd-arm@freebsd.org>, Marcin Wojtas <mw@semihalf.com> Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X Message-ID: <R2j5liajAUAH50q4pL84znc6wTWOGVOLk2flHaJdoyB2YBL0YDXknOZdgS3r2xkwwAZNO6EHjg-TGqDPUl-ZllK-e2P3_idpXxDCfAaEQsM=@a9development.com> In-Reply-To: <c1788ee7f14b9236e0972909032cb8fd@unrelenting.technology> References: <tNxLh7s3GHht_l2JBe9kNRfifHkl4bytVPRgGNV7c7s6YoRgcBoNjylO84lIowDaCjcGps4Ht5POo5ZkB3zInJCsOUmAowldM24Eo_XWeYI=@a9development.com> <31D3FA64-8296-4CA5-92A2-F7FE7C4AE981@unrelenting.technology> <ZdPk7zJSE8UvoonkTixa2gV04ujgKfY93A71fz8cTB6ZPjt2uSCD5TdvFzDAEIR9Tu5LoGrcZLmXqgyrCmzh8OIB2JLc4gNKr6xF0pe931M=@a9development.com> <32d1c173d986884efb9b28932c0ead52@unrelenting.technology> <5e1b4bfe845e62bbcd8b827fa37f2b98@unrelenting.technology> <a727f3c05b234218e053c53100b539f0@unrelenting.technology> <KwrTwABcfEzegUc4D8ZsCgFSxouYQIMOa9JoIbpe6d1HInlAX4G0OzdL_d_uug3gifKwFoh1C_EUd5MucQUgtvFy4T0qraW6riyZbje4Mw8=@a9development.com> <cbf5773a03d3c67e133096a0f826274d@unrelenting.technology> <c1788ee7f14b9236e0972909032cb8fd@unrelenting.technology>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > https://gist.github.com/agrajag9/749f504dcac741e902f87c2ea03ae9ac > > > > From jnettlet: > > > > BEGIN QUOTE > > > > the V1 silicon has a SATA errata. I have partially worked around th= e errata moving some > > > > configuration into the firmware, but I still need to sort out the r= emaining bits. Sometimes just > > > > unplugging and replugging your SATA cable will help to reseat the c= onnector 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 files= ystems, read and write to said > > > > filesystems, and hot-plug even seems to work. But I'm not sure if j= on'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 |=3D 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 poki= ng 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 u= p is that ranges with .NumIds=3D0 end up > with end before the beginning.. > > mapping->end =3D map_entry->InputBase + map_entry->IdCount - 1; > > The ARM document DEN0049D says the field is "The number of IDs in the ran= ge minus one". > If my brain still works at all: that means we have to do plus one when in= terpreting it, not minus one more!! :D > > This causes the first mapping on the PCIe root complex to be used, when w= e clearly want the second one. > > Sooo NOW pcie should work! I promise: > > https://send.firefox.com/download/05a4e22a349f611f/#azClkvNDfZU-PczXSmNva= Q Sad trombone https://gist.github.com/agrajag9/eddb36ad44898c070e464e7add594= 26d
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?R2j5liajAUAH50q4pL84znc6wTWOGVOLk2flHaJdoyB2YBL0YDXknOZdgS3r2xkwwAZNO6EHjg-TGqDPUl-ZllK-e2P3_idpXxDCfAaEQsM=>