On Thu, 24 Jan 2019 13:07:54 +0100 Alexander Graf <ag...@suse.de> wrote:
> On 24.01.19 12:31, Andre Przywara wrote: > > On Thu, 24 Jan 2019 12:21:17 +0100 > > Alexander Graf <ag...@suse.de> wrote: > > > >> On 24.01.19 12:07, Andre Przywara wrote: > >>> On Thu, 24 Jan 2019 11:59:32 +0100 > >>> Alexander Graf <ag...@suse.de> wrote: > >>> > >>>> On 24.01.19 11:57, Andre Przywara wrote: > >>>>> On Thu, 24 Jan 2019 11:17:03 +0100 > >>>>> Alexander Graf <ag...@suse.de> wrote: > >>>>> > >>>>>> On 22.01.19 17:37, Alexander Graf wrote: > >>>>>>> > >>>>>>> > >>>>>>> On 22.01.19 17:28, Alexander Graf wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> On 22.01.19 17:17, Oskari Lemmelä wrote: > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> On 22.1.2019 16.54, Alexander Graf wrote: > >>>>>>>>>> > >>>>>>>>>> On 05.01.19 18:52, Oskari Lemmela wrote: > >>>>>>>>>>> Minimal changes to support sun6i based Allwinner SOCs > >>>>>>>>>>> Changes are based to SPL driver > >>>>>>>>>>> arch/arm/mach-sunxi/spl_spi_sunxi.c > >>>>>>>>>>> > >>>>>>>>>>> Signed-off-by: Oskari Lemmela <osk...@lemmela.net> > >>>>>>>>>> I just tried to see if this patch gives me "sf" access on a > >>>>>>>>>> SoPine system. Unfortunately, it seems as if the sun4i_spi > >>>>>>>>>> driver doesn't even get probed? > >>>>>>>>>> > >>>>>>>>>> How did you manage to actually make use of this driver? > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Alex > >>>>>>>>> > >>>>>>>>> You need to add spi0 alias to dts and enable needed drivers > >>>>>>>>> to defconfig. You can take look from Jagan's patch [1]. > >>>>>>>>> > >>>>>>>>> I didn't include those changes as Maxime already commented > >>>>>>>>> [2] that Kconfig depends/defaults should be modified > >>>>>>>>> first. > >>>>>>>> > >>>>>>>> I don't see any relation between the dts change and the > >>>>>>>> Kconfig dependency issues? > >>>>>>>> > >>>>>>>> But thanks for the pointer, I'll give this patch a > >>>>>>>> try. > >>>>>>> > >>>>>>> Ok, so I now get the SPI controller initialized, but it seems > >>>>>>> to only returns zeros when trying to access the SPI flash > >>>>>>> device. > >>>>>>> > >>>>>>> In other words, it doesn't work for me :). But maybe I'm > >>>>>>> missing all the other clk patches to actually get it > >>>>>>> working? > >>>>>> > >>>>>> Ok, so turns out the problem is that you can't have eMMC and > >>>>>> SPI both working. I don't quite know yet whether this is just a > >>>>>> pinmux problem (so potentially software workaroundable) or if > >>>>>> it's a hardware limitation (eMMC pulling a line required for > >>>>>> SPI). > >>>>> > >>>>> The line that is shared is "DS", which is only needed for higher > >>>>> (e)MMC modes (HS-400). At the moment neither Linux nor U-Boot > >>>>> implement this mode, and probably U-Boot will never need it: it > >>>>> adds software complexity for a questionable performance benefit, > >>>>> especially if the flash chips can't keep up with the high > >>>>> interface speed anyway. > >>>>> > >>>>> We addressed this in the DTs (kernel commit fa59dd2ef755). > >>>>> > >>>>> I am a bit puzzled here as why this happens: I can't find where > >>>>> U-Boot would configure PC1 to use the MMC2 function: the > >>>>> hard-coded mmc_pinmux_setup() doesn't touch PC1 at all. Maybe > >>>>> it's the BootROM configuring this line? So we would need to > >>>>> reset it? > >>>>> > >>>>> As I don't have an eMMC module here at hand right now, this has > >>>>> to wait till tonight for further insights. > >>>> > >>>> A few more data points: > >>>> > >>>> When I boot w/o eMMC module attached, SPI flash works > >>>> When I then plug in the eMMC module, SPI flash still works > >>> > >>> Plug in with power off (which you should always do)? So it goes > >>> through the BootROM? > >>> > >>>> When I that start initializing the eMMC module, SPI flash > >>>> fails > >>> > >>> What do you mean by that, exactly? Accessing eMMC from U-Boot? > >> > >> Yes, "mmc part" to be precise. > >> > >>> Because that is the interesting data point, somehow this makes the > >>> eMMC module drive the pin. > >>> > >>>> When I then unplug the eMMC module, SPI flash works again > >>> > >>> Again, at runtime? > >> > >> Yup, all of it at runtime. I felt darey and ignored the fact that > >> you should really only plug the eMMC module at boot time ;). > >> > >> The last step definitely did not change pinmux. Hence the > >> conclusion that this is line drive collision, not pinmux. > >> > >> So I guess you're saying that forcing the eMMC into 4-DAT mode > >> would make things work? > > > > Technically DS is for HS-400, which is a step beyond 8-bit bus > > width. So just enabling 8 bit should not affect the DS line. There > > is a bit in the MMC controller to enable HS-400, but I don't see > > that we would set it (we actually don't even define the register). > > You could try to force eMMC to 4 bit to check this theory, by > > hack-removing the MMC_MODE_8BIT line in sunxi_mmc_init() in > > drivers/mmc/sunxi-mmc.c (we don't use DM_MMC yet, so it's in the > > hacky part and ignores the DT property) > > Ok, that did not help. I guess the next best useful thing to do now > would be to measure what the MISO line shows in each situation. > Unfortunately I don't have my oscilloscope handy :). Can't you configure PC1 as a gpio, and read that? Not sure the "gpio" command works with PC1 being a "function pin", but you could always hack it to GPIO-in by clearing bits[7:4] in 0x01C20848, with md.l/mw.l. Cheers, Andre. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
