> 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: imxesdhc0: start cmd 17 arg=0 data=0xccd94000 dlen=512 flags=0x1c50 proc="sdmmc0" imxesdhc0: wait_state 1 0 ff8d8088) imxesdhc0: interrupt status=0x00000011 imxesdhc0: intr status 0x1 error 0 resp[0] 0x00000900 imxesdhc0: resp=0x900 datalen=512 imxesdhc0: intr status 0x10 error 0 imxesdhc0: wait_state 800 800 ff8d858e) imxesdhc0: timeout waiting for 800, state ff8d858e imxesdhc0: data transfer done (error=60) imxesdhc0: cmd 17 done (flags=0x1c51 error=60) imxesdhc0: interrupt status=0x00000010 root on rd0a swap on rd0b dump on rd0b panic: cannot open disk, 0x1200/0x1202, error 2 We now get the BRR interrupt and move on to waiting for the state register's "buffer read enable" bit to go high. It doesn't, and we timeout again, this time without all the error interrupts firing: imxesdhc0: interrupt status=0x00000010 Just one interrupt this time, as you can see. It is the "buffer write ready" interrupt, analagous to the "buffer write enable" state bit we would be looking for in this situation were we peforming a write instead of a read. Groan. This is as far as I got today, I plan on working more on it next week. > The novena has two slots one internal one with a card detect line and > one without. I was told the one without card detect (external) has > working io and can be mounted the other one can not. I see 4 slots in the IMX6 dual/quad manual (uSDHC1-4). My cubox i4pro only seems to have one actual microSD peripheral port and no onboard eMMC, maybe one of those four slots could be an alternate slot referring to the peripheral port. fwiw the linux image it shipped with booted properly. Ian
