[U-Boot] OT: SD/MMC-over-SPI and speed in linux
Hi all,
sorry for the off-topic question, but I seemingly did not yet find the right search string and was hoping to find experienced embedded people here to point me in the right direction.
I have connected a SD card to a coldfire MCF54455 via SPI, accessible from both U-Boot and linux. The kernel is quite old, 2.6.25 from the freescale LTIB, because freescale did not push their coldfire changes back into any official tree.
In U-Boot, I can get read speeds with fatload of around 400 kBytes/second, which seems reasonable as the card can handle 25 MHz SPI speed. (And, it would be sufficient for our application.)
In the linux kernel, the read speed drops to around 35 kBytes/second, regardless of using a filesystem or not. This is not only quite ridiculous (as I would expect more optimized drivers in the kernel than in the bootloader), but would give us real performance problems when writing to the card. The SPI speed is detected and set correctly to 25 MHz by the driver.
Does anybody know if this is a known limitation in (older) linux mmc_spi implementation, or if this issue still exists? If it is solved, can anybody point me to a patch/discussion/keyword where I can find more information which part I would have to check or back-port?
Best regards, Wolfgang
Hello Wolfgang,
Am Donnerstag, 6. Mai 2010 15:13:14 schrieb Wolfgang Wegner:
In U-Boot, I can get read speeds with fatload of around 400 kBytes/second, which seems reasonable as the card can handle 25 MHz SPI speed. (And, it would be sufficient for our application.)
IIRC 400kBytes/second is the initial speed for SD cards on SPI. The card itself responds which max speed it can handle. Which could be adjusted later (up to 25MHz or even more).
In the linux kernel, the read speed drops to around 35 kBytes/second, regardless of using a filesystem or not. This is not only quite ridiculous (as I would expect more optimized drivers in the kernel than in the bootloader), but would give us real performance problems when writing to the card. The SPI speed is detected and set correctly to 25 MHz by the driver.
Does anybody know if this is a known limitation in (older) linux mmc_spi implementation, or if this issue still exists? If it is solved, can anybody point me to a patch/discussion/keyword where I can find more information which part I would have to check or back-port?
I backported this spi_mmc driver to 2.6.10 (yes, even older) and it is slow, nevertheless. I don't know how SPI is done in u-boot, but maybe the system interrupts in linux like ethernet and timer slow SPI transfer down.
Best regards Alexander
Hi Alexander,
On Thu, May 06, 2010 at 03:33:53PM +0200, Alexander Stein wrote: [...]
IIRC 400kBytes/second is the initial speed for SD cards on SPI. The card itself responds which max speed it can handle. Which could be adjusted later (up to 25MHz or even more).
the initial speed is 400 kBits/second, because there may be some (few) cards that could not handle more.
I backported this spi_mmc driver to 2.6.10 (yes, even older) and it is slow, nevertheless. I don't know how SPI is done in u-boot, but maybe the system interrupts in linux like ethernet and timer slow SPI transfer down.
Thanks for the confirmation! I just found a page from the blackfin linux project: http://docs.blackfin.uclinux.org/doku.php?id=linux-kernel:drivers:spi_mmc which suggests better values (using dd with bs=512 should be similar to what bonnie does in the block tests?). A hint I got from this page was to disable SPI DMA (which was also enabled on my coldfire), and this improved the situation to get around 115 kBytes/second.
Strange enough enabling DMA decreases performance, there still seems to be room for improvement. I will try to see if I can spot differences in the blackfin kernel that I could back-port - although I already saw there are many differences when back-porting the locking part.
Best regards, Wolfgang
Am Donnerstag, 6. Mai 2010 15:59:44 schrieb Wolfgang Wegner:
Hi Alexander,
On Thu, May 06, 2010 at 03:33:53PM +0200, Alexander Stein wrote: [...]
IIRC 400kBytes/second is the initial speed for SD cards on SPI. The card itself responds which max speed it can handle. Which could be adjusted later (up to 25MHz or even more).
the initial speed is 400 kBits/second, because there may be some (few) cards that could not handle more.
Yep, it's need to distinguish between SD and MMC. IIRC that's also the speed a MMC can handle (at maximum?).
I backported this spi_mmc driver to 2.6.10 (yes, even older) and it is slow, nevertheless. I don't know how SPI is done in u-boot, but maybe the system interrupts in linux like ethernet and timer slow SPI transfer down.
Thanks for the confirmation!
e.g. If I'm downloading something per FTP to the SD card I get a big burst at first and then several seconds 0bytes/s In this case I also detected a bug in the windows TCP stack if some packets get dropped... On a new AT91 board with integrated MCI interface it's much faster
I just found a page from the blackfin linux project: http://docs.blackfin.uclinux.org/doku.php?id=linux-kernel:drivers:spi_mmc which suggests better values (using dd with bs=512 should be similar to what bonnie does in the block tests?). A hint I got from this page was to disable SPI DMA (which was also enabled on my coldfire), and this improved the situation to get around 115 kBytes/second.
I can't say much about actual transfer rates. But i noticed a real slowdown when the filesystem buffer is about to be flushed. We are using a COldfire 5484 and AFAIK there is no DMA for SPI, at least we don't use it.
Best regards Alexander
Hi,
On Thu, May 06, 2010 at 04:13:41PM +0200, Alexander Stein wrote:
I can't say much about actual transfer rates. But i noticed a real slowdown when the filesystem buffer is about to be flushed. We are using a COldfire 5484 and AFAIK there is no DMA for SPI, at least we don't use it.
I used M54451EVB/M54455EVB as a starting point, both use eDMA for SPI by default. Sorry, don't know about MCF547x/548x.
Things are clearing up now: as far as I could see, there are no real timing-relevant things changed in mmc_spi code, BUT the underlying SPI driver is crucial.
Setting the same default timing values found in mcf5445x-devices.c in U-Boot (CONFIG_SYS_DSPI_CTAR0), I can degrade the performance of MMC-SPI in U-Boot by a factor of 3, approximately. However, setting the fast default values from U-Boot in the linux kernel (mcf5445x-devices.c) makes things even worse there, too.
After all, I am sure now it is only the SPI part I have to investigate further, most probably concerning latency between transfers.
Thanks for the comments and sorry for the noise!
Best regards, Wolfgang
participants (2)
-
Alexander Stein -
wolfgang＠leila.ping.de