Date: Sat, 06 Jun 2020 00:44:00 +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: <c1e4129989005bc9bfd117988019107d@unrelenting.technology> In-Reply-To: <NkmJNP_BMdinQ07E7zvRW9EQtYTkHLISOPlALNNcbFXi7d0dsuvgHD2IW73ptiSh1kEml7_VHb9_eTIMaLAIeAici_qpz2UyIrBWzXR4mvE=@a9development.com> References: <NkmJNP_BMdinQ07E7zvRW9EQtYTkHLISOPlALNNcbFXi7d0dsuvgHD2IW73ptiSh1kEml7_VHb9_eTIMaLAIeAici_qpz2UyIrBWzXR4mvE=@a9development.com> <R2j5liajAUAH50q4pL84znc6wTWOGVOLk2flHaJdoyB2YBL0YDXknOZdgS3r2xkwwAZNO6EHjg-TGqDPUl-ZllK-e2P3_idpXxDCfAaEQsM=@a9development.com> <ZdPk7zJSE8UvoonkTixa2gV04ujgKfY93A71fz8cTB6ZPjt2uSCD5TdvFzDAEIR9Tu5LoGrcZLmXqgyrCmzh8OIB2JLc4gNKr6xF0pe931M=@a9development.com> <32d1c173d986884efb9b28932c0ead52@unrelenting.technology> <5e1b4bfe845e62bbcd8b827fa37f2b98@unrelenting.technology> <a727f3c05b234218e053c53100b539f0@unrelenting.technology> <KwrTwABcfEzegUc4D8ZsCgFSxouYQIMOa9JoIbpe6d1HInlAX4G0OzdL_d_uug3gifKwFoh1C_EUd5MucQUgtvFy4T0qraW6riyZbje4Mw8=@a9development.com> <cbf5773a03d3c67e133096a0f826274d@unrelenting.technology> <c1788ee7f14b9236e0972909032cb8fd@unrelenting.technology> <940a6099e971e01bd6d04564d0982b9d@unrelenting.technology>
next in thread | previous in thread | raw e-mail | index | archive | help
June 6, 2020 3:28 AM, "Dan Kotowski" <dan.kotowski@a9development.com> wro= te:=0A=0A>>> https://gist.github.com/agrajag9/129585436f01876cc4d799382e1= c0fac=0A>>> AHCI is looking better and better! I'm going to do a little b= it of poking at that SATA HDD just=0A>> to=0A>>> see how stable it really= is.=0A>>> Posted quirk patch:https://reviews.freebsd.org/D25157=0A>>>; Ba= ck 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 be= ginning..=0A>>> mapping->end =3D map_entry->InputBase + map_entry->IdCoun= t - 1;=0A>>> The ARM document DEN0049D says the field is "The number of I= Ds in the range minus one".=0A>>> If my brain still works at all: that me= ans we have to do plus one when interpreting it, not minus=0A>>> one more= !! :D=0A>>> This causes the first mapping on the PCIe root complex to be = used, when we clearly want the=0A>> second=0A>>> one.=0A>>> Sooo NOW pcie= should work! I promise:=0A>>> https://send.firefox.com/download/05a4e22a= 349f611f/#azClkvNDfZU-PczXSmNvaQ=0A>> =0A>> Sad trombone https://gist.git= hub.com/agrajag9/eddb36ad44898c070e464e7add59426d=0A>> =0A>> hmm. The dev= ice ID looks correct to me.. but we can check against NetBSD just in case= .=0A>> =0A>> Can you boot NetBSD with debug messages (boot -x)?=0A>> It s= hould print 'ACPI: IORT mapped devid' messages among other things.=0A>> = =0A>> Also.. about the fact that it's showing up as if the PCIe root is o= utputting to the SMMU,=0A>> maybe that really doesn't sound like a bug, m= ore like the firmware modifying the table?=0A>> (and the interrupt is act= ually going to the SMMU?)=0A>> But I can't find anything like that in the= firmware code.=0A>> =0A>> An ACPI table dump from running FreeBSD might = help: /usr/sbin/acpidump -dt=0A>> And for a full binary dump, install acp= ica-tools=0A>> (if you don't want to bother with USB Ethernet and package= installs,=0A>> just wget the package on another machine and extract it o= nto the live image):=0A>> https://pkg.freebsd.org/FreeBSD:13:aarch64/late= st/All/acpica-tools-20200430.txz=0A>> and with that, run: /usr/local/bin/= acpidump -b=0A>> (creates a bunch of binary files in the current director= y)=0A>> =0A>> Also.. try using your self built firmware again?=0A> =0A> h= ttps://gist.github.com/agrajag9/bce229ac6527b21f91c8337d79e1dae9=0A> =0A>= Well, my own self-built firmware seems to be misbehaving - it's failing = to see the SD reader or=0A> throwing errors about `EFI ASSERT` or things = like this:=0A> =0A> `Synchronous Exception at 0x00000000ED7BD93C`=0A> =0A= > So continuing to use Jon's for now...=0A> =0A> `acpidump -b` just spat = back "Could not get ACPI table at index 1, AE_NOT_FOUND"=0A=0AThat's norm= al, it still creates files in the current directory..=0ABut okay, the acp= iview is good enough.=0A=0A> `acpidump -dt` worked just fine=0A> =0A> Als= o pulled the output of `acpiview` from the EFI shell again since we're us= ing Jon's latest=0A> tables.=0A=0Alol, 0x30 =3D=3D decimal 48. ITS node i= s at 0x30, SMMU at 0x48 (72). How not confusing!=0A=0AYeah so the PCIe ro= ot nodes are indeed pointing at the SMMU, while that's not supposed to be= the case in the public code:=0Ahttps://github.com/SolidRun/edk2-platform= s/blob/eec706c2d693be0b3793d9180e7d1a4813a526cf/Silicon/NXP/LX2160A/AcpiT= ables/Iort.aslc#L220=0A=0AHence my hypothesis that Jon was experimenting = with enabling the SMMU in that build :)=0A=0AMaybe try the firmware from = that google drive link?=0A=0A> [ 1.0000030] panic: Trap: Data Abort (EL= 1): Translation Fault L0 with read access for 0000000000000300: pc ffffc0= 00004aca34: opcode f8607a74: ldr x20, [x19,x0,lsl #3]=0A=0ARight, damn, J= on said that on the new firmware, OSes with the custom layerscape PCIe dr= iver won't work.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c1e4129989005bc9bfd117988019107d>