Date: Fri, 05 Jun 2020 23:05:51 +0000 From: greg@unrelenting.technology To: "Dan Kotowski" <dan.kotowski@a9development.com> Cc: "freebsd-arm" <freebsd-arm@freebsd.org> Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X Message-ID: <940a6099e971e01bd6d04564d0982b9d@unrelenting.technology> In-Reply-To: <R2j5liajAUAH50q4pL84znc6wTWOGVOLk2flHaJdoyB2YBL0YDXknOZdgS3r2xkwwAZNO6EHjg-TGqDPUl-ZllK-e2P3_idpXxDCfAaEQsM=@a9development.com> References: <R2j5liajAUAH50q4pL84znc6wTWOGVOLk2flHaJdoyB2YBL0YDXknOZdgS3r2xkwwAZNO6EHjg-TGqDPUl-ZllK-e2P3_idpXxDCfAaEQsM=@a9development.com> <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
June 6, 2020 12:53 AM, "Dan Kotowski" <dan.kotowski@a9development.com> wr= ote:=0A=0A>>>> https://gist.github.com/agrajag9/749f504dcac741e902f87c2ea= 03ae9ac=0A>>>> From jnettlet:=0A>>>> BEGIN QUOTE=0A>>>> the V1 silicon ha= s 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 re= maining bits. Sometimes=0A>> just=0A>>>> unplugging and replugging your S= ATA cable will help to reseat the connector and help. Also it=0A>> is=0A>= >>> very sensitive to marginal SATA cables.=0A>>>> END QUOTE=0A>>>> I pla= yed around a bit and could create and destroy GPTs, make filesystems, rea= d and write to=0A>> said=0A>>>> filesystems, and hot-plug even seems to w= ork. But I'm not sure if jon's comment really explains=0A>>>> the=0A>>>> = AHCI error we're still seeing:=0A>>>> (aprobe3:ahcich3:0:15:0): NOP FLUSH= QUEUE. ACB: 00 00 00 00 00 00 00 00 00 00 00 00=0A>>>> (aprobe3:ahcich3:0= :15:0): CAM status: Command timeout=0A>>>> (aprobe3:ahcich3:0:15:0): Erro= r 5, Retries exhausted=0A>>> =0A>>> I experienced this issue on a cuple o= f targets (e.g. Zynq-MP or=0A>>> LS1046A). The port-multiplier quirk flag= helped - please try adding:=0A>>> ahci->quirks |=3D AHCI_Q_NOPMP;=0A>>> = Build with this + more ITS logging:=0A>>> https://send.firefox.com/downlo= ad/cf66ed7f48160529/#LpeMjccv7iqze5hAx_6BrQ=0A>>> The patch that lets AHC= I attach:=0A>>> https://reviews.freebsd.org/D25145=0A>>; =0A>> https://gis= t.github.com/agrajag9/129585436f01876cc4d799382e1c0fac=0A>> AHCI is looki= ng better and better! I'm going to do a little bit of poking at that SATA= HDD just to=0A>> see how stable it really is.=0A>> =0A>> Posted quirk pa= tch:https://reviews.freebsd.org/D25157=0A>>; =0A>> Back to PCI: hmm, maybe= the reason that IORT parsing weirdly picks SMMU up is that ranges with= =0A>> .NumIds=3D0 end up=0A>> with end before the beginning..=0A>> =0A>> = mapping->end =3D map_entry->InputBase + map_entry->IdCount - 1;=0A>> =0A>= > The ARM document DEN0049D says the field is "The number of IDs in the r= ange minus one".=0A>> If my brain still works at all: that means we have = to do plus one when interpreting it, not minus=0A>> one more!! :D=0A>> = =0A>> This causes the first mapping on the PCIe root complex to be used, = when we clearly want the second=0A>> one.=0A>> =0A>> Sooo NOW pcie should= work! I promise:=0A>> =0A>> https://send.firefox.com/download/05a4e22a34= 9f611f/#azClkvNDfZU-PczXSmNvaQ=0A> =0A> Sad trombone https://gist.github.= com/agrajag9/eddb36ad44898c070e464e7add59426d=0A=0Ahmm. The device ID loo= ks correct to me.. but we can check against NetBSD just in case.=0A=0ACan= you boot NetBSD with debug messages (boot -x)?=0AIt should print 'ACPI: = IORT mapped devid' messages among other things.=0A=0AAlso.. about the fac= t that it's showing up as if the PCIe root is outputting to the SMMU,=0Am= aybe that really doesn't sound like a bug, more like the firmware modifyi= ng the table?=0A(and the interrupt is *actually* going to the SMMU?)=0ABu= t I can't find anything like that in the firmware code.=0A=0AAn ACPI tabl= e dump from running FreeBSD might help: /usr/sbin/acpidump -dt=0AAnd for = a full binary dump, install acpica-tools=0A(if you don't want to bother w= ith USB Ethernet and package installs,=0Ajust wget the package on another= machine and extract it onto the live image):=0Ahttps://pkg.freebsd.org/F= reeBSD:13:aarch64/latest/All/acpica-tools-20200430.txz=0Aand with that, r= un: /usr/local/bin/acpidump -b=0A(creates a bunch of binary files in the = current directory)=0A=0AAlso.. try using your self built firmware again?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?940a6099e971e01bd6d04564d0982b9d>