Date: Fri, 05 Jun 2020 21:19:31 +0000 From: greg@unrelenting.technology To: "Dan Kotowski" <dan.kotowski@a9development.com> Cc: "freebsd-arm" <freebsd-arm@freebsd.org>, "Marcin Wojtas" <mw@semihalf.com> Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X Message-ID: <c1788ee7f14b9236e0972909032cb8fd@unrelenting.technology> In-Reply-To: <tNxLh7s3GHht_l2JBe9kNRfifHkl4bytVPRgGNV7c7s6YoRgcBoNjylO84lIowDaCjcGps4Ht5POo5ZkB3zInJCsOUmAowldM24Eo_XWeYI=@a9development.com> References: <tNxLh7s3GHht_l2JBe9kNRfifHkl4bytVPRgGNV7c7s6YoRgcBoNjylO84lIowDaCjcGps4Ht5POo5ZkB3zInJCsOUmAowldM24Eo_XWeYI=@a9development.com> <CAPv3WKcQFeMDs%2B7Pji5=8D_avua8TK_vHxGLofhoKZArXLyUpQ@mail.gmail.com> <ShdSNL8XDgj0KtPR4v8nn1ohjVssrnoUQGwNL-gHOpylio7Eo5J_WjA2Ko9YjV5md64MeFz017Ts01KUnpJa3Xpw4y_PncL4e5cfUcotRWM=@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>
next in thread | previous in thread | raw e-mail | index | archive | help
June 5, 2020 10:18 PM, "Dan Kotowski" <dan.kotowski@a9development.com> wr= ote:=0A=0A>>> https://gist.github.com/agrajag9/749f504dcac741e902f87c2ea0= 3ae9ac=0A>>> From jnettlet:=0A>>> BEGIN QUOTE=0A>>> the V1 silicon has a = SATA errata. I have partially worked around the errata moving some=0A>>> = configuration into the firmware, but I still need to sort out the remaini= ng bits. Sometimes just=0A>>> unplugging and replugging your SATA cable w= ill help to reseat the connector and help. Also it is=0A>>> very sensitiv= e to marginal SATA cables.=0A>>> END QUOTE=0A>>> I played around a bit an= d could create and destroy GPTs, make filesystems, read and write to said= =0A>>> filesystems, and hot-plug even seems to work. But I'm not sure if = jon's comment really explains=0A>> the=0A>>> AHCI error we're still seein= g:=0A>>> =0A>>> (aprobe3:ahcich3:0:15:0): NOP FLUSHQUEUE. ACB: 00 00 00 0= 0 00 00 00 00 00 00 00 00=0A>>> (aprobe3:ahcich3:0:15:0): CAM status: Com= mand timeout=0A>>> (aprobe3:ahcich3:0:15:0): Error 5, Retries exhausted= =0A>>> =0A>> =0A>> I experienced this issue on a cuple of targets (e.g. Z= ynq-MP or=0A>> LS1046A). The port-multiplier quirk flag helped - please t= ry adding:=0A>> ahci->quirks |=3D AHCI_Q_NOPMP;=0A>> =0A>> Build with thi= s + more ITS logging:=0A>> https://send.firefox.com/download/cf66ed7f4816= 0529/#LpeMjccv7iqze5hAx_6BrQ=0A>> =0A>> The patch that lets AHCI attach:= =0A>> https://reviews.freebsd.org/D25145=0A>; =0A> https://gist.github.com= /agrajag9/129585436f01876cc4d799382e1c0fac=0A> =0A> AHCI is looking bette= r and better! I'm going to do a little bit of poking at that SATA HDD jus= t to=0A> see how stable it really is.=0A=0APosted quirk patch: https://re= views.freebsd.org/D25157=0A=0ABack to PCI: hmm, maybe the reason that IOR= T parsing weirdly picks SMMU up is that ranges with .NumIds=3D0 end up=0A= with end before the beginning..=0A=0Amapping->end =3D map_entry->InputBas= e + map_entry->IdCount - 1;=0A=0AThe ARM document DEN0049D says the field= is "The number of IDs in the range minus one".=0AIf my brain still works= at all: that means we have to do *plus* one when interpreting it, not mi= nus one more!! :D=0A=0AThis causes the *first* mapping on the PCIe root c= omplex to be used, when we clearly want the second one.=0A=0ASooo NOW pci= e should work! I promise:=0A=0Ahttps://send.firefox.com/download/05a4e22a= 349f611f/#azClkvNDfZU-PczXSmNvaQ
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c1788ee7f14b9236e0972909032cb8fd>