Date: Sat, 06 Jun 2020 02:16:43 +0000 From: Dan Kotowski <dan.kotowski@a9development.com> To: "greg@unrelenting.technology" <greg@unrelenting.technology> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X Message-ID: <XYXpaNQ3XeZR6g5RpmjR3qs56wTKfNi_OpPX53S3yYdPMNMWR0kme-Q7hmNpxzR6EL3DqKxUnG8BcW6ueHv82Kaexu1j4VSLtNtQgYuxX_g=@a9development.com> In-Reply-To: <c1e4129989005bc9bfd117988019107d@unrelenting.technology> References: <NkmJNP_BMdinQ07E7zvRW9EQtYTkHLISOPlALNNcbFXi7d0dsuvgHD2IW73ptiSh1kEml7_VHb9_eTIMaLAIeAici_qpz2UyIrBWzXR4mvE=@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> <c1e4129989005bc9bfd117988019107d@unrelenting.technology>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > 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=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 t= he range minus one". > > > > If my brain still works at all: that means we have to do plus one w= hen 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-Pcz= XSmNvaQ > > > > > > Sad trombone https://gist.github.com/agrajag9/eddb36ad44898c070e464e7= add59426d > > > hmm. The device ID looks correct to me.. but we can check against Net= BSD just in case. > > > Can you boot NetBSD with debug messages (boot -x)? > > > It should print 'ACPI: IORT mapped devid' messages among other things= . > > > Also.. about the fact that it's showing up as if the PCIe root is out= putting to the SMMU, > > > maybe that really doesn't sound like a bug, more like the firmware mo= difying the table? > > > (and the interrupt is actually going to the SMMU?) > > > But I can't find anything like that in the firmware code. > > > An ACPI table dump from running FreeBSD might help: /usr/sbin/acpidum= p -dt > > > And for a full binary dump, install acpica-tools > > > (if you don't want to bother with USB Ethernet and package installs, > > > just wget the package on another machine and extract it onto the live= image): > > > https://pkg.freebsd.org/FreeBSD:13:aarch64/latest/All/acpica-tools-20= 200430.txz > > > and with that, run: /usr/local/bin/acpidump -b > > > (creates a bunch of binary files in the current directory) > > > Also.. try using your self built firmware again? > > > > https://gist.github.com/agrajag9/bce229ac6527b21f91c8337d79e1dae9 > > Well, my own self-built firmware seems to be misbehaving - it's failing= to see the SD reader or > > throwing errors about `EFI ASSERT` or things like this: > > `Synchronous Exception at 0x00000000ED7BD93C` > > So continuing to use Jon's for now... > > `acpidump -b` just spat back "Could not get ACPI table at index 1, AE_N= OT_FOUND" > > That's normal, it still creates files in the current directory.. > But okay, the acpiview is good enough. D'oh! > > `acpidump -dt` worked just fine > > Also pulled the output of `acpiview` from the EFI shell again since we'= re using Jon's latest > > tables. > > lol, 0x30 =3D=3D decimal 48. ITS node is at 0x30, SMMU at 0x48 (72). How = not confusing! > > Yeah so the PCIe root nodes are indeed pointing at the SMMU, while that's= not supposed to be the case in the public code: > https://github.com/SolidRun/edk2-platforms/blob/eec706c2d693be0b3793d9180= e7d1a4813a526cf/Silicon/NXP/LX2160A/AcpiTables/Iort.aslc#L220 > > Hence my hypothesis that Jon was experimenting with enabling the SMMU in = that build :) > > Maybe try the firmware from that google drive link? My old one worked this time? I really couldn't tell you what I did differen= tly, but this isn't the first time where I had seemingly non-deterministic = boot problems that go away when I swap firmwares. > > [ 1.0000030] panic: Trap: Data Abort (EL1): Translation Fault L0 with r= ead access for 0000000000000300: pc ffffc000004aca34: opcode f8607a74: ldr = x20, [x19,x0,lsl #3] > > Right, damn, Jon said that on the new firmware, OSes with the custom laye= rscape PCIe driver won't work. D'oh again! Now, here's something different - this time when loading the mps driver, it= failed back to the shell. In all prior testing it would just hang forever. Also, bye-bye ahci without Jon's ECAM fix :/ https://gist.github.com/agrajag9/64c7070a40135f397a9dc8d841954590
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XYXpaNQ3XeZR6g5RpmjR3qs56wTKfNi_OpPX53S3yYdPMNMWR0kme-Q7hmNpxzR6EL3DqKxUnG8BcW6ueHv82Kaexu1j4VSLtNtQgYuxX_g=>