Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

I have enabled MMC via menuconfig per "Building Softare Components for OMAP-L138." Linux startup displays

"davinci_mmc davinci_mmc.0:using dma, 4-bit mode."

Does anybody know how to make the kernel probe for SD devices?

Thanks,
David Kasper

Hello Mr. Kasper,

We have used the MMC card with the Critical Link Carrier board here, mounting both a FAT as well as an ext2 partition. We've also been able to load/boot a kernel from it from u-Boot and mount a partition as a root filesystem. Are you just trying to mount a separate partition on an MMC card, or boot from it via u-Boot?

If you build from the latest version of the master branch on the Linux kernel for MityDSP-L138 repository and build using the mitydspl138_defconfig configuration, you should get a kernel image that will work with the industrial I/O carrier board that recognizes the MMC / SD card. There are instructions for doing this off of the same wiki site.

The SD/MMC interface is probed whenever a card is inserted into the slot (there is a GPIO pin that is connected to the driver that will initiate a probe / mount operation once the driver is installed). If you are running udev, you should get a mount point in /media/mmcblk0p1. When you insert or remove a card, you should also see messages on the console that that has happened.

If you are trying to mount an MMC partition as the rootfs, make sure that you are using the "rootwait" option, or the kernel will hang as the MMC driver may take a while to get itself registered and get the partition mounted through the init cycle.

If you still don't see any activity, could you please post a log of your boot-up (or a dmesg output)?

-Mike

Mike,

Thanks for your help and sorry for the late response. I determined that SD cards worked on the CriticalLink carrier board but not on our custom board. Everything is working fine on our board as the problem was due to a couple of hardware signals. However, the mount point is /media/mmcblk0 versus /media/mmcblk0p1 as noted in your e-mail. This doesn't present an issue.

Thanks,
Dave

Mike,

The micro SD card is functioning with a FAT filesystem in our system. However, the write bandwith is slower then expected at 200KB/s. Writing the same file to RAM yields 14MB/s. Do you have any suggestions on increasing the speed? I suspect the issue is the Linux driver. Do you know anything about the driver or if a faster version exists? Also do you know whether SDHC cards are supported?

Thanks,
David Kasper

Hi David,

What throughput do you need or expect to get? I don't think the SD card is ever going to be as fast as a RAM based file system. I'm not sure what performance you are trying to get to.

Thanks,
Tom

Tom,

Thanks for your response. We would desire 4MB/s. Do you know how close to that number we could achieve?

David Kasper

Hi David,

TI has published performance numbers for their basic kernel (which our port essentially sits on top of) here:

http://processors.wiki.ti.com/index.php/DaVinci_PSP_03.20.00.11_Device_Driver_Features_and_Performance_Guide#MMC.2FSD_Driver

For ext2fs, they are claiming 8 MB/sec write throughput is achievable, but that appears to require fairly large buffered writes and uses a large portion of the CPU (50%). I don't know what difference you might encounter between FAT and ext2fs performance, but I doubt it would be too much. Your 200 KB/sec suggests there may be some optimization you could apply. What size buffers are you writing, and how loaded is the ARM during your write operations?

Are you writing to a ramfs in order to compute the 14 MB/sec RAM throughput? That number seems a little lower than I would expect as well.

-Mike

Michael Williamson wrote:

Hi David,

TI has published performance numbers for their basic kernel (which our port essentially sits on top of) here:

http://processors.wiki.ti.com/index.php/DaVinci_PSP_03.20.00.11_Device_Driver_Features_and_Performance_Guide#MMC.2FSD_Driver

For ext2fs, they are claiming 8 MB/sec write throughput is achievable, but that appears to require fairly large buffered writes and uses a large portion of the CPU (50%). I don't know what difference you might encounter between FAT and ext2fs performance, but I doubt it would be too much. Your 200 KB/sec suggests there may be some optimization you could apply. What size buffers are you writing, and how loaded is the ARM during your write operations?

Are you writing to a ramfs in order to compute the 14 MB/sec RAM throughput? That number seems a little lower than I would expect as well.

-Mike

From the referenced page..
The performance numbers can be severely affected if the media is mounted in sync mode. Hot plug scripts in the filesystem mount removable media in sync mode to ensure data integrity. For performance sensitive applications, umount the auto-mounted filesystem and re-mount in async mode.
Something to look at/check...
cheers
/Tim

Tim,

Thanks, remounting the drive in async mode drastically increased performance. I am now getting 4.3MB/s using 1K block writes (versus 0.2 MB/s for sync mode). Where is the hot plug script located on the file system? I plan on modifying the script to add the async option.

Regards,
David Kasper

David
the mount is done by udev. The scripts for udev are in /etc/udev/scripts
the file mount.sh is the one that mounts the fs and sets the options
cheers
/Tim

Tim,

The script is listed below. Since I want to perform "mount /dev/mmcblk0p1 /media/mmcblk0p1 -o async" would I change the following line in the script below.

Thanks,
Dave

PROPOSED CHANGE:

if ! $MOUNT -t auto -o async $DEVNAME "/media/$name" 

ORIGINAL SYNTAX:

if ! $MOUNT -t auto -o sync $DEVNAME "/media/$name" 

SCRIPT:

#!/bin/sh
#
# Called from udev
# Attemp to mount any added block devices 
# and remove any removed devices
#

MOUNT="/bin/mount" 
PMOUNT="/usr/bin/pmount" 
UMOUNT="/bin/umount" 
name="`basename "$DEVNAME"`" 

for line in `cat /etc/udev/mount.blacklist | grep -v ^#`
do
    if ( echo "$DEVNAME" | grep -q "$line" )
    then
        logger "udev/mount.sh" "[$DEVNAME] is blacklisted, ignoring" 
        exit 0
    fi
done

automount() {    
    ! test -d "/media/$name" && mkdir -p "/media/$name" 

    if ! $MOUNT -t auto -o sync $DEVNAME "/media/$name" 
    then
        #logger "mount.sh/automount" "$MOUNT -t auto $DEVNAME \"/media/$name\" failed!" 
        rm_dir "/media/$name" 
    else
        logger "mount.sh/automount" "Auto-mount of [/media/$name] successful" 
        touch "/tmp/.automount-$name" 
    fi
}

rm_dir() {
    # We do not want to rm -r populated directories
    if test "`find "$1" | wc -l | tr -d " "`" -lt 2 -a -d "$1" 
    then
        ! test -z "$1" && rm -r "$1" 
    else
        logger "mount.sh/automount" "Not removing non-empty directory [$1]" 
    fi
}

if [ "$ACTION" = "add" ] && [ -n "$DEVNAME" ]; then
    if [ -x "$PMOUNT" ]; then
        $PMOUNT $DEVNAME 2> /dev/null
    elif [ -x $MOUNT ]; then
            $MOUNT $DEVNAME 2> /dev/null
    fi

    # If the device isn't mounted at this point, it isn't configured in fstab
    # 20061107: Small correction: The rootfs partition may be called just "rootfs" and not by
    #         its true device name so this would break. If the rootfs is mounted on two places
    #        during boot, it confuses the heck out of fsck. So Im auto-adding the root-partition
    #        to /etc/udev/mount.blacklist via postinst 

    cat /proc/mounts | awk '{print $1}' | grep -q "^$DEVNAME$" || automount 

fi

if [ "$ACTION" = "remove" ] && [ -x "$UMOUNT" ] && [ -n "$DEVNAME" ]; then
    for mnt in `cat /proc/mounts | grep "$DEVNAME" | cut -f 2 -d " " `
    do
        $UMOUNT $mnt
    done

    # Remove empty directories from auto-mounter
    test -e "/tmp/.automount-$name" && rm_dir "/media/$name" 
fi