Date: Fri, 22 May 2020 19:23:45 +0200 From: Marcin Wojtas <mw@semihalf.com> To: Greg V <greg@unrelenting.technology> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X Message-ID: <CAPv3WKd-tnQuZwop8Kuk2=v71_YhHFREWqj3piPj=X_LmqS8aQ@mail.gmail.com> In-Reply-To: <d502d4e13727bdde1e6e755a0ccea951@unrelenting.technology> References: <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> <LqTdXCGMiTFwSobCq9LtV5QVLOZ42AiBDUTC9UrdM67cUlD_I8Y7no-8F7d_vs3VDJwIFJLgHTSZVrbkIXXeZ_-hcU0FxfWj0dr-GvhKXHA=@a9development.com> <b04385d558850dc1dfa60fc398c9ac6c@unrelenting.technology> <CAPv3WKdyOzegfK4NJjKzXQTp9jGV9VkDRWxY%2BhDudzWQKkRfEQ@mail.gmail.com> <d502d4e13727bdde1e6e755a0ccea951@unrelenting.technology>
next in thread | previous in thread | raw e-mail | index | archive | help
wt., 19 maj 2020 o 19:45 <greg@unrelenting.technology> napisa=C5=82(a): > > May 19, 2020 7:57 PM, "Marcin Wojtas" <mw@semihalf.com> wrote: > > > wt., 19 maj 2020 o 18:42 <greg@unrelenting.technology> napisa=C5=82(a): > > > >> May 19, 2020 7:11 PM, "Dan Kotowski" <dan.kotowski@a9development.com> = wrote: > >> > >> Getting closer... > >> dmesg.boot: https://gist.github.com/agrajag9/99d26385be0f49a8a4f046f15= a2c0f08 > >> > >> "iicbus0: <unknown card> at addr 0x77" nice! > >> Would be great if you could run `i2c -s` also. > >> > >> 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 [..] > >> > >> Hey look at that! A bunch of numbers! Hopefully they mean more to you = than they do to me... > >> > >> hmm, it shouldn't report all numbers as present. oh well. > >> > >> sdhci_acpi0-slot0 seems to have hung the boot process for almost 5min = waiting for various timeouts. > >> > >> oops, so they didn't really make generic sdhci work :D > >> > >> Well turns out we do have a Freescale ESDHC driver already. > >> It doesn't have DMA so performance won't be great (but SD/MMC is bad s= tuff anyway lol). > >> (interesting dev note: NetBSD gets away with just some quirks in the s= dhci acpi driver: > >> SDHC_FLAG_HAVE_DVS|SDHC_FLAG_NO_PWR0|SDHC_FLAG_32BIT_ACCESS|SDHC_FLAG_= ENHANCED) > >> > >> No worries - once I can get a reliable install, I hope to never need t= o touch those again anyways. > >> I mostly am hoping to get eMMC so I can flash updated firmware, assumi= ng the errata list is correct > >> and my silicon rev CAN boot from firmware on eMMC and it was a layer 8= failure. > >> > >> Trying to add ACPI support to it: > >> > >> https://send.firefox.com/download/926c72b043182c40/#49y3TaeL7_hif_YEHU= FQ2g > >> > >> Latest dmesg.boot: https://gist.github.com/agrajag9/f4e8186e4cea7da1e5= d8887a8d74dd7a > >> > >> "mmcsd0: 32GB <SDHC SB32G 8.0 SN DD1242F8 MFG 09/2017 by 3 SD> at mmc0= 43.7MHz/4bit/65535-block" > >> is better than before, but controller timeouts are sad. Welp. > >> > >> If anyone is interested in debugging this (with the device in hand), m= y ACPI attachment patch is: > >> https://github.com/myfreeweb/freebsd/commit/4abb60611c53b6bf109e8854f6= 0ecc697419cf1c > >> > >> Once again, maybe NetBSD's way of supporting this (slight quirks in th= e generic ACPI SDHCI driver) > >> would be better than fsl_sdhci. > > > > Do you have a knowledge if LS2KX controller is common with the one > > found in LS1046? If that may help, we are going to upstream it (need > > some rework after rebasing from 11.x). > > From a quick look at Linux, should be very similar. > LX2160 uses just "fsl,esdhc" which is handled by the same driver as "fsl,= ls1046a-esdhc" > but w/o any specific clock data. > > https://github.com/torvalds/linux/blob/master/drivers/mmc/host/sdhci-of-e= sdhc.c > https://github.com/SolidRun/edk2-platforms/blob/eec706c2d693be0b3793d9180= e7d1a4813a526cf/Silicon/NXP/LX2160A/Include/DeviceTreeInclude/fsl-lx2160a.d= tsi#L364-L387 > > The changes you're going to upstream, are they for fsl_sdhci or generic s= dhci? In the original patch, the fsl_sdhci did not work well, due to endianness issues and really significant register differences between ppc and arm64 QoriQ sdhci controllers. I hope it will be submitted some time in June by its author, you will be added to review.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPv3WKd-tnQuZwop8Kuk2=v71_YhHFREWqj3piPj=X_LmqS8aQ>