Is the SD card slot on a DM365 EVM accessible as a mmc block device in linux?

Yes, it typically shows up as an /dev/mmcblk# (where # could be 0, 1, 2, ...).

Not sure if you have seen this, but it may be useful: http://wiki.davincidsp.com/index.php/DM3xx_SD_card_boot_and_flashing_program

Juan,

I actually used Constantine's program to restore my EVM, as it shipped without uBoot by accident.

I did some more testing, and see that it can see standard SD cards, but I was attempting to use an SDHC card.  The SPI interface between SD and SDHC is not terribly different, so I would be surprised if it were not supported by a kernel as recent as 2.6.18.

Best Regards,

Mark Deneen

Well now, I am surprised.  SDHC was added in 2.6.19.

Well, seems like you figured this out already, but for future reference this sort of information would be avilable in the LSP Driver Data manual included in the DVSDK (SPRS566.pdf in this case); there you shoud see

   "High-capacity SD support is not present in the driver."

That said, you can probrably port back SDHC support from newer kernels into our DVSDK kernel; I am not sure if anyone has done this yet.  We are gradually moving all our DM365 driver development to GIT (we should be there by year end); if you can wait a bit, then you may get SDHC support fro free with the GIT kernel.

Juan,

Thanks for the information.  Just so I am clear, the git kernel tree (git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git) -- does not have the davinci drivers in the source tree?  What do you consider davinci drivers?  cmemk, irqk and family?

Sorry, I just cracked the box open recently and I'm new to the world of TI.  I can backport the MMC driver if I have to.  I am just curious as to what I would get if I built the kernel from the git sources above.

I would not recommend getting GIT kernel yet; I do not believe it is ready for prime time.  What I would consider DaVinci drivers is any driver written for our EVM, for example, if our EVM has an SD/MMC slot, there will likely be a corresponding driver (if there is not one already).  In addition, since this is open source, external developers may contribute DaVinci compatible drivers for peripherals that are not on our EVM (e.g. a different audio codec part that interfaces to DaVinci part).  I would consider all of these drivers which touch at least part of the DaVinci hardware register set under the DaVinci driver umbrella. 

Also, please note that above, I used the term DaVinci part, which is generic an can ecompass many different parts.  This is because our GIT kernel is not specific to DM365, it will have support for other parts as well.  DM365 GIT kernel is being targeted for the end of the year, hence the reason I suggested it is not ready for prime time. 

mdeneen said:

I can backport the MMC driver if I have to.

Just a quick note on this, someone else was able to backport SDHC functionality for the DM365, and they listed the patches they used in this thread.

Bernie,

I am compiling now after manually applying all of those patches.  I'll let you know how it goes and post a patch against the latest LSP if it works.

Mark

"Thank you, my hard hatted friend!"

Well, that didn't work.

I updated to the latest LSP, and uBoot gets to "done, booting the kernel" and just hangs there.  The old kernel and a 2.6.31 kernel I built from the git repo work fine.

Is there any way to debug what happened?

mdeneen said:

uBoot gets to "done, booting the kernel" and just hangs there.

Most commonly this means that your console is messed up somehow by way of something wrong in the bootargs,  you may want to double check your bootargs.

Beyond that debugging what happened is not very easy, in general most kernel debugging I have done has involved printk() and was a very manual process, if nothing prints out at all when you try to boot you may want to take a step back and check what the patches you were applying actually are doing, in particular if they are changing anything in the deeper parts of the kernel that could impact the ability to print out to the serial terminal.

I built for DM355 by accident.  My image is booting, but it does not do anything when I insert a card.  Time to dig.  :-)

Found the bug (typo) on my end.  I'll make up a patch and post it on Monday.

Great work! Thank you for putting a consolidated patch out there for the community. I assume this is all working on your end now and is for the LSP 2.10.00.14 kernel included with the 2.10.01.18 DVSDK?

I may have to try this out myself next week, if I get a chance to verify it and put together some instructions would you mind if I posted this on the http://wiki.davincidsp.com? I think the work you have done here is certainly worth the effort of putting together an article on my end if it is ok with you, of course you could make one as well if you like.

Bernie,

It was definitely the LSP 2.10.00.14 kernel, and unless a new DVSDK was released in the last week it is against 2.10.01.18 DVSDK as well.

Feel free to put it up on the wiki after you give it a spin.  It should apply cleanly to the LSP.  I mounted a SanDisk 4GB SDHC card and tested reading and writing to files.  It worked fine, although I did not get a chance to test how fast it is.

Mark

It works on my end as well, the new wiki article is up at http://wiki.davincidsp.com/index.php/How_to_use_SDHC_on_DM365_with_MontaVista_5.0 and I am also attaching the .diff file to this post as a mirror to your site. Thanks again for putting the patch together.

Bernie,

Looks good.  On a related note, is the SD card slot on the bottom of the EVM accessible as well?  I didn't see a switch in the docs which would enable it.

Mark

I have never tried it, it is connected up to the second SD/MMC controller on the DM365 and I am not sure if the Linux drivers actually recognize the second SD/MMC controller. The 'switch' to enable it in hardware is actually a register in the CPLD on the EVM, see bit 6 of register 3 of the CPLD discussed in section 2.1.1.2.4 of the DM365 EVM Technical Reference.

Bernie,

From reading the documentation, the EMIF CE1 base address is 0x04000000.  Unfortunately, I don't see this mapped in /proc/iomem.  Do you have an example of reading / modifying the CPLD registers?

I don't know if I have to touch the CPLD or not; the bottom SD card works with the git kernel.  I can't wait until that is the preferred method.  :-)

/proc/iomap has the cpld mapped in the git kernel as well.

mdeneen said:

Do you have an example of reading / modifying the CPLD registers?

There is code buried in the driver source that does this but I don't think it is exposed to the user, in other words I am not sure there is an out of the box way to do this from the command line. I think a utility like this (which rebuilt works on DM365 as well) would let you do it as an alternative.

mdeneen said:

I don't know if I have to touch the CPLD or not; the bottom SD card works with the git kernel.  I can't wait until that is the preferred method.  :-)

It is good to hear that it works with the GIT kernel, someone must have added CPLD register modifying code into the low level SD/MMC driver, the only risk I see here is the potential conflict with a imager that uses the same pins for GPIO if such a driver should exist. I am also looking forward to the GIT migration, it just makes more sense to me.

Is there a fix available for the DM355 to get SDHC capability?

I tried this patch in the hope that the DM355 & DM365 kernels would be the same, but it looks like there's no file called davinci-mmc.c in the DM355 drivers/mmc directory like there is for DM365.

Interestingly the davinci-mmc.c file is present in the older MV-4.0.1 LSP 01 20 00 014 kernel directory, but
not in the newer MV-5.0 LSP 02 00 00 140 directory - was it removed for the newer LSP on DM355?

We'll need SDHC capability on our DM355 based product. Thanks.

it appears there is SDHC support in DVSDK 1.30 which includes  LSP 01 20 00 014 you mentioned above; unfortunately, there is no SDHC support in the newer DVSDK 2.0 nor is there a patch to add such support (at least to my knowledge).

I'm trying to apply the DM365 patch to the DM355 DVSDK V1.3 kernel. I just though I'd run the patch first on the DM355 V1.3 files to see what happened..........

$ patch -p1 -i sdhc_mvl.diff
patching file drivers/mmc/davinci_mmc.c
Hunk #1 succeeded at 352 (offset -281 lines).
Hunk #2 succeeded at 360 (offset -281 lines).
Hunk #3 succeeded at 629 (offset -122 lines).
Hunk #4 FAILED at 640.
Hunk #5 succeeded at 666 with fuzz 2 (offset -130 lines).
Hunk #6 succeeded at 808 (offset -128 lines).
Hunk #7 FAILED at 1458.
2 out of 7 hunks FAILED -- saving rejects to file drivers/mmc/davinci_mmc.c.rej
patching file drivers/mmc/mmc_block.c
Hunk #1 FAILED at 28.
Hunk #2 FAILED at 153.
Hunk #3 FAILED at 248.
Hunk #4 FAILED at 294.
Hunk #5 succeeded at 373 (offset 35 lines).
Hunk #6 succeeded at 523 (offset 36 lines).
Hunk #7 succeeded at 637 (offset 36 lines).
4 out of 7 hunks FAILED -- saving rejects to file drivers/mmc/mmc_block.c.rej
patching file drivers/mmc/mmc.c
Hunk #1 FAILED at 10.
Hunk #2 succeeded at 106 with fuzz 2 (offset 2 lines).
Hunk #3 succeeded at 160 (offset 2 lines).
Hunk #4 succeeded at 198 (offset 2 lines).
Hunk #5 FAILED at 292.
Hunk #6 succeeded at 278 (offset -47 lines).
Hunk #7 succeeded at 311 (offset -47 lines).
Hunk #8 succeeded at 327 (offset -59 lines).
Hunk #9 succeeded at 401 (offset -59 lines).
Hunk #10 succeeded at 422 with fuzz 1 (offset -59 lines).
Hunk #11 FAILED at 534.
Hunk #12 succeeded at 629 (offset -62 lines).
Hunk #13 FAILED at 1017.
Hunk #14 FAILED at 1165.
Hunk #15 succeeded at 1037 (offset -219 lines).
Hunk #16 FAILED at 1154.
Hunk #17 succeeded at 1176 (offset -226 lines).
Hunk #18 succeeded at 1190 (offset -226 lines).
Hunk #19 succeeded at 1204 (offset -226 lines).
Hunk #20 succeeded at 1260 (offset -226 lines).
Hunk #21 FAILED at 1286.
Hunk #22 succeeded at 1303 (offset -228 lines).
Hunk #23 succeeded at 1315 (offset -228 lines).
Hunk #24 succeeded at 1354 (offset -228 lines).
Hunk #25 succeeded at 1461 (offset -228 lines).
7 out of 25 hunks FAILED -- saving rejects to file drivers/mmc/mmc.c.rej
patching file drivers/mmc/mmc.h
patching file drivers/mmc/mmci.c
Hunk #1 succeeded at 499 (offset -6 lines).
patching file drivers/mmc/mmc_sysfs.c
Hunk #2 succeeded at 308 (offset -10 lines).
Hunk #3 succeeded at 353 (offset -10 lines).
can't find file to patch at input line 939
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -ru a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
|--- a/drivers/mmc/sdhci.c    2009-09-18 18:23:54.795782526 -0400
|+++ b/drivers/mmc/sdhci.c    2009-09-18 18:25:02.891809191 -0400
--------------------------

........... so there are a few things it doesn't like and there's at least one file missing. Where can I get the DM365 files so I can spot the differences and make the community a patch for the DM355, or maybe better still are the files available for the DM365 that have already been patched (so easier to do the differences). Many thanks.

SteveG said:

Where can I get the DM365 files so I can spot the differences and make the community a patch for the DM355, or maybe better still are the files available for the DM365 that have already been patched (so easier to do the differences).

All the various DVSDKs can be found within http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/dvsdk/ in particular for DM365 you would be looking at DVSDK 2.10, and the particular PSP/LSP that the patches for DM365 do apply cleanly to is 2.10.00.14, you should only really need to download/install this to get that source. With this source you could easily run that patch and than have both the original and un patched drivers if you want to look at differences as a whole.  

I was able to use the patch on the DM365 kernel and mount an sd card using psp 2 10 14

patch -p1 -i sdhc_mvl.diff

I followed the wiki, it worked well.

http://wiki.davincidsp.com/index.php/How_to_use_SDHC_on_DM365_with_MontaVista_5.0