wandboard / imx6 / exynos4 / cortex-a9 "wrong-endian bug" fixed

[Ian Lepore]

On Wed, 2014-02-12 at 23:43 +0100, Bernd Walter wrote:
> 
> Am 12.02.2014 um 23:37 schrieb Ian Lepore <ian at FreeBSD.org>:
> 
> > On Wed, 2014-02-12 at 23:22 +0100, Bernd Walter wrote:
> >> On Tue, Feb 11, 2014 at 09:33:29PM -0700, Ian Lepore wrote:
> >>> On Tue, 2014-02-11 at 20:54 -0700, Ian Lepore wrote:
> >>>> On Tue, 2014-02-11 at 14:44 +0100, Bernd Walter wrote:
> >>>>> On Tue, Feb 11, 2014 at 02:07:33AM +0100, Bernd Walter wrote:
> >>>>>> I can't seen to get the second microSD-slot running.
> >>>>>> The controllers get attached, but mmc only to the onboard slot.
> >>>>>> The WiFi is SDIO, which I didn't compile into the kernel and I noticed
> >>>>>> there is a GPIO used to enable the chip.
> >>>>> 
> >>>>> Strange enough the 4th controller gets an mmc1 device attached:
> >>>>> sdhci_imx3: <Freescale uSDHC controller> mem 0x219c000-0x219ffff irq 57 on simplebus2
> >>>>> sdhci_imx3-slot0: 200MHz HS 4bits 3.3V 3.0V PIO
> >>>>> sdhci_imx3-slot0: ============== REGISTER DUMP ==============
> >>>>> sdhci_imx3-slot0: Sys addr: 0x00000000 | Version:  0x00000002
> >>>>> sdhci_imx3-slot0: Blk size: 0x00000000 | Blk cnt:  0x00000001
> >>>>> sdhci_imx3-slot0: Argument: 0x00000000 | Trn mode: 0x00000000
> >>>>> sdhci_imx3-slot0: Present:  0xf78d8088 | Host ctl: 0x00000000
> >>>>> sdhci_imx3-slot0: Power:    0x0000000d | Blk gap:  0x00000080
> >>>>> sdhci_imx3-slot0: Wake-up:  0x00000008 | Clock:    0x00000002
> >>>>> sdhci_imx3-slot0: Timeout:  0x00000080 | Int stat: 0x00000000
> >>>>> sdhci_imx3-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb
> >>>>> sdhci_imx3-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000
> >>>>> sdhci_imx3-slot0: Caps:     0x0377c800 | Max curr: 0x80000000
> >>>>> sdhci_imx3-slot0: ===========================================
> >>>>> mmc1: <MMC/SD bus> on sdhci_imx3
> >>>>> 
> >>>>> It hangs on probing, but it is my understanding that this controller
> >>>>> isn't wired at all on wandboard.
> >>>>> But why isn't there an attachment with the other two controllers.
> >>>>> 
> >>>> 
> >>>> I can't get the uSD slot on the carrier board to work either, but my
> >>>> symptoms are different.
> >>>> 
> >>>> Aha!  I just noticed that Freescale moved some bits around in the
> >>>> Present State register and defined some that are undefined in the spec
> >>>> and so on.  I completely overlooked that when I was writing the
> >>>> driver.  
> >>>> 
> >>>> I need to write some proper translation routines, which ain't happening
> >>>> tonight. :)  But, as proof of concept, the attached little crude hack
> >>>> makes it successfully probe both of my sd slots now.
> >>>> 
> >>>> -- Ian
> >>>> 
> >>>> differences between files attachment (imx_sdhci_detect_hack.diff)
> >>>> Index: sys/arm/freescale/imx/imx_sdhci.c
> >>>> ===================================================================
> >>>> --- sys/arm/freescale/imx/imx_sdhci.c    (revision 261700)
> >>>> +++ sys/arm/freescale/imx/imx_sdhci.c    (working copy)
> >>>> @@ -298,6 +298,9 @@ imx_sdhci_read_4(device_t dev, struct sdhci_slot *
> >>>>        val32 |= sc->r1bfix_intmask;
> >>>>    }
> >>>> 
> >>>> +    if (off == SDHCI_PRESENT_STATE && device_get_unit(dev) != 1)
> >>>> +        val32 |= SDHCI_CARD_PRESENT;
> >>>> +
> >>>>    return val32;
> >>>> }
> >>>> 
> >>> 
> >>> Just realized... that check for unit != 1 is only needed if you have the
> >>> wifi device enabled in the dts.  If only the sd slots are enabled, leave
> >>> that out.
> >> 
> >> With that both cards are probed now.
> >> 
> > 
> > The bad news is that I've just finished coding up the translation
> > between the freescale and standard definitions of the Present State
> > register, and the bit for card-detected didn't move.  So it's not fixed
> > yet.
> > 
> > The u-boot code uses gpios for card detect, and the wandboard schematic
> > agrees with that.  I have no idea why the sdhci controller thinks one
> > slot has a card inserted and the other doesn't.  Maybe there are just
> > some internal pads that aren't bonded and it's an accident of how the
> > lines are floating.
> 
> I will try to make tests on MarSboard soon.
> It has an onboard emmc and a slot.
> Not sure which controllers they use for which - will have to read schematic first.
> > 
> > There's a lot (a LOT) of work to be done to get to a proper solution.
> > The standard dev/sdhci driver has no concept of how to use a gpio to
> > check for card presence, so there's work to be done there.  On the imx6
> > side, we have nothing right now for pinmux or gpio support.
> > 
> > It should also be possible to use the DAT3 line for card detect, I'll
> > look into how to make that work.
> > 
> > -- Ian
> > 

I couldn't make the DAT3 detection work reliably.  U-boot turns on
pullups on the DATn lines (using pullups on SD clock and data lines has
become fashionable lately, I'm not sure why) and that interferes with
using them for card detect.  I tried modifying u-boot to turn off the
pullup, but it still didn't give reliable results.  Doh!  I just
noticed, not only does u-boot turn on pulllups on the DAT lines, the
wandboard has them in hardware as well.

For now, I updated the dts source to match the linux fdt standard, using
non-removable and cd-gpios properties to describe the card detect.  For
now, the driver will treat the "cd-gpios" property the same as
"non-removable" and force the card-is-present status.  That means
a /dev/mmc# is instantiated even if no card is present.  This is all as
of r261817.

Eventually when we get a gpio driver for imx6 that'll change to do the
card detection for real.

-- Ian