Thank you for your response. Using the iMX6 SDK, and the code you sent I got it to compile and run. There were no reported errors. This is what the code you sent read back from sector 0 (FAT 32 MBR) of a good SD card:
Here is what is actually on the (same) card, same sector:
This was read using a Vybrid processor. How do I get from point A to point B? Again - the board is a Boundary Devices (known good, boots and run linux from an SD card (obviously not the card above).
This is my frustration - what is causing the controller to incorrectly read the card? Again, this is using the code you sent.
After searching for awhile I found the "main" u-boot usdhc file. Depending on whose download you use it's called by different names; but try fsl_usdhc.c or fsl_usdhc_imx.c. In comparing the SDK files that I had previously to the ones Jodi sent, I found a small difference - on the later ones I found the later one does a dcache flush and invalidate of the read buffer depending on the state of the dcache. In my standalone driver I don't turn on the caches or the mmu:
The above is from the debugger when it starts up. I do this to avoid having to set up the caches. My question is do the caches need to be functional before the sdhc will work properly?
I can find no differences between my driver and any of the SDKs, or the u-boot driver (except the u-boot driver does use caches/mmu). The only issue with my driver is that data is read incorrectly. That means to me that there is something going on that the manual doesn't mention or there is an errata regarding reads and writes I haven't found. I know that the sdhc cannot burst into/out of OCRAM - only system (DDR) memory. I also know that the buffer must start on a 32-bit boundary. Any comments??
