I've been lately throwing some serious time on this issue. It is a slow process because each trial-and-error iteration takes about 5 minutes (must write hundreds of MB to get the corruption to show up). I'm checking the SD/MMC code line by line with the aid of the leaked JZ4740 manuals (which are far far far from being clear), comparing the driver kernel code to the uCOS-II code also released by Ingenic (I've got the feeling it is a bit more up to date) and so on. I've fixed the DMA round robin prioriry bug, which was of course not the cause of the corruption, fixed some other apparent bugs in the jz_mmc.c code, and I'm testing everything that comes to my mind, including slowing down the SD/MMC clock. But it is a slow process, please be patient. There's also the possibility that I can have access to further Ingenic documentation (will comment on this in another post) which could help on this issue.
Well, the good news is that one of the things I tried worked: setting the SD/MMC interface in 1-bit mode (instead of 4-bit) seems to fix the corruption. The downside is that the throughput goes down the drain (yeah, you guessed it, one fourth of throughput of the 4-bit mode). I was about to say that this pretty much rules out a DMA related problem, but I'm not sure that's 100% true since lower throughput also means lower stress on the DMA subsystem which could avoid the glitch or corner case causing the corruption. Anyway, the main suspect is still the SD/MMC interface, either the silicon or the A320 hardware. My bet so far is that the code is not properly detecting and handling an error condition that arises during writes.
I'll be preparing today a new release of dual-boot and system packages. Besides the SD/MMC interface in 1-bit mode, it will include some other improvements like support for partitionless cards.
Well, the good news is that one of the things I tried worked: setting the SD/MMC interface in 1-bit mode (instead of 4-bit) seems to fix the corruption. The downside is that the throughput goes down the drain (yeah, you guessed it, one fourth of throughput of the 4-bit mode). I was about to say that this pretty much rules out a DMA related problem, but I'm not sure that's 100% true since lower throughput also means lower stress on the DMA subsystem which could avoid the glitch or corner case causing the corruption. Anyway, the main suspect is still the SD/MMC interface, either the silicon or the A320 hardware. My bet so far is that the code is not properly detecting and handling an error condition that arises during writes.
I'll be preparing today a new release of dual-boot and system packages. Besides the SD/MMC interface in 1-bit mode, it will include some other improvements like support for partitionless cards.
http://www.dingux.com/2009/08/workar...ard-write.html