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? 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? > So this is not pinmux related. The eMMC module really just drives the > line. Thanks for that. Cheers, Andre. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
