Date: Tue, 19 May 2020 16:42:28 +0000 From: greg@unrelenting.technology To: "Dan Kotowski" <dan.kotowski@a9development.com> Cc: "John-Mark Gurney" <jmg@funkthat.com>, freebsd-arm@freebsd.org Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X Message-ID: <b04385d558850dc1dfa60fc398c9ac6c@unrelenting.technology> In-Reply-To: <LqTdXCGMiTFwSobCq9LtV5QVLOZ42AiBDUTC9UrdM67cUlD_I8Y7no-8F7d_vs3VDJwIFJLgHTSZVrbkIXXeZ_-hcU0FxfWj0dr-GvhKXHA=@a9development.com> References: <LqTdXCGMiTFwSobCq9LtV5QVLOZ42AiBDUTC9UrdM67cUlD_I8Y7no-8F7d_vs3VDJwIFJLgHTSZVrbkIXXeZ_-hcU0FxfWj0dr-GvhKXHA=@a9development.com> <TLwmTbuqZXh21TMiFjCu96O2fOIoWgPXE-0amhQa7y66As1E39i0v-nC7j1saPpCy8KrT63uE_W92527rywGhtxTKVATtYBSLfrLRdZ3faA=@a9development.com> <cjE8j_Tehwtmk7Aw0hzP-EZxwfAQC4ywIrgcqrarkCiRI_X5kacVsJHpaX_SMO9QHVCqfEdJH45eC4AE2cwzfx9nmHzWbhE7M-h09hDe8MA=@a9development.com> <7F9D7164-2C04-4E27-85F9-A495EAC8FC84@unrelenting.technology> <63b4f78ff4ee07359a345bcbc03afeaa@unrelenting.technology> <2053cd2299b81860deecc638ef839d1f@unrelenting.technology> <0012917d629a48e9fcd8589f4f002e1b@unrelenting.technology> <947c2f9bfaad823a2b104b8741502b40@unrelenting.technology> <c88780825e96fe583b32adf86416706e@unrelenting.technology> <d709b1aae3d33f49fadcce9817cb102a@unrelenting.technology>
next in thread | previous in thread | raw e-mail | index | archive | help
May 19, 2020 7:11 PM, "Dan Kotowski" <dan.kotowski@a9development.com> wro= te:=0A=0A>> Getting closer...=0A>> dmesg.boot: https://gist.github.com/ag= rajag9/99d26385be0f49a8a4f046f15a2c0f08=0A>> =0A>> "iicbus0: <unknown car= d> at addr 0x77" nice!=0A>> Would be great if you could run `i2c -s` also= .=0A> =0A> Scanning I2C devices on /dev/iic0: 01 02 03 04 05 06 07 08 09 = 0a 0b 0c 0d 0e 0f 10 11 12 13 14 [..]=0A> =0A> Hey look at that! A bunch = of numbers! Hopefully they mean more to you than they do to me...=0A=0Ahm= m, it shouldn't report all numbers as present. oh well.=0A=0A>> sdhci_acp= i0-slot0 seems to have hung the boot process for almost 5min waiting for = various timeouts.=0A>> =0A>> oops, so they didn't really make generic sdh= ci work :D=0A>> =0A>> Well turns out we do have a Freescale ESDHC driver = already.=0A>> It doesn't have DMA so performance won't be great (but SD/M= MC is bad stuff anyway lol).=0A>> (interesting dev note: NetBSD gets away= with just some quirks in the sdhci acpi driver:=0A>> SDHC_FLAG_HAVE_DVS|= SDHC_FLAG_NO_PWR0|SDHC_FLAG_32BIT_ACCESS|SDHC_FLAG_ENHANCED)=0A> =0A> No = worries - once I can get a reliable install, I hope to never need to touc= h those again anyways.=0A> I mostly am hoping to get eMMC so I can flash = updated firmware, assuming the errata list is correct=0A> and my silicon = rev CAN boot from firmware on eMMC and it was a layer 8 failure.=0A> =0A>= > Trying to add ACPI support to it:=0A>> =0A>> https://send.firefox.com/d= ownload/926c72b043182c40/#49y3TaeL7_hif_YEHUFQ2g=0A> =0A> Latest dmesg.bo= ot: https://gist.github.com/agrajag9/f4e8186e4cea7da1e5d8887a8d74dd7a=0A= =0A"mmcsd0: 32GB <SDHC SB32G 8.0 SN DD1242F8 MFG 09/2017 by 3 SD> at mmc0= 43.7MHz/4bit/65535-block"=0Ais better than before, but controller timeou= ts are sad. Welp.=0A=0AIf anyone is interested in debugging this (with th= e device in hand), my ACPI attachment patch is:=0Ahttps://github.com/myfr= eeweb/freebsd/commit/4abb60611c53b6bf109e8854f60ecc697419cf1c=0A=0AOnce a= gain, maybe NetBSD's way of supporting this (slight quirks in the generic= ACPI SDHCI driver)=0Awould be better than fsl_sdhci.=0A=0A> I can't find= the PCIe cables for my PSU right now, so the RX480 is out until I have t= ime to dig=0A> through The Cable Box Of Doom. But I do have a spare LSI S= AS HBA that I'll try after lunch!=0A=0AYeah, mpr/mps drivers are present,= would be an okay thing to try.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b04385d558850dc1dfa60fc398c9ac6c>