On Sun, Nov 08, 2015 at 03:49:34AM -0500, Ian Sutton wrote: > > I tried enabling bits in the ccm, enabling clocks, making various > > changes to imxesdhc itself and didn't get anywhere. Similiar story > > with the usb otg port on the cubox. > > I have made some headway. Compiling with -DSDHC_DEBUG shows imxesdhc > follows all the nessecary steps for initialization, voltage select, > CID/CSD checking, etc. Only when the driver attempts the first actual > transfer (single block read at address 0, CMD 17) does it fail: > > imxesdhc0: start cmd 17 arg=0 data=0xccd94000 dlen=512 flags=0x1c50 > proc="sdmmc0" > imxesdhc0: wait_state 1 0 ff8d8088) > imxesdhc0: interrupt status=0x00000001 > imxesdhc0: intr status 0x1 error 0 > resp[0] 0x00000900 > imxesdhc0: resp=0x900 datalen=512 > imxesdhc0: intr status 0x107f0000 error 0 > imxesdhc0: software reset reg=0x6000000 > imxesdhc0: data transfer done (error=60) > imxesdhc0: cmd 17 done (flags=0x1c51 error=60) > root on rd0a swap on rd0b dump on rd0b > panic: cannot open disk, 0x1200/0x1202, error 2 > > This line in particular: > > imxesdhc0: intr status 0x107f0000 error 0 > > indicates many error interrupts were received during the time the driver > was waiting for the "buffer read ready" interrupt following the single > block read command. That interupt never comes and a ETIMEDOUT is > returned (error=60 2 lines down). This is due to the "internal DMA mode" > bit being set; according to the i.MX6 reference manual this stops our > target BRR interrupt from firing (page 5601): > > "When internal DMA is not used (DMAEN bit in Transfer Type register is > not set when the command is sent), the uSDHC asserts a DMA request when > the amount of data exceeds the value set in the RD_WML register, that is > available and ready for system fetching data. At the same time, the > uSDHC sets the BRR bit. The buffer read ready interrupt will be > generated if it is enabled by software. When internal DMA is used, the > uSDHC will not inform the system before all the required number of bytes > are transferred (if no error was encountered)." > > This bit is set on line 819 in imxesdhc.c. It shouldn't be: > > 819 HWRITE4(sc, SDHC_MIX_CTRL, > 820 (HREAD4(sc, SDHC_MIX_CTRL) & (0xf << 22)) | (command & 0xffff)); > 821 HWRITE4(sc, SDHC_CMD_XFR_TYP, command); > 822 > 823 splx(s); > 824 return 0; > > That doesn't look right. > > The rest of the driver defaults to using PIO, DMA mode must be > manually enabled with -DSDHC_DMA (It currently doesn't compile). All the > DMA mode-specific code is wrapped in #ifdefs except the line mentioned > above. Removing it advances our progress somewhat:
For a point of comparison the FreeBSD i.mx6 sdhc driver is pio "DMA is not really broken, I just haven't implemented it yet" and supposedly works. It also has some comments that seem to describe errata. https://svnweb.freebsd.org/base/head/sys/arm/freescale/imx/imx_sdhci.c?revision=HEAD&view=co
