• State
  • Locked Locked
  • Replies 9 replies
  • Subscribers 101 subscribers
  • Views 1669 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

OMAP-L138: MMC Access - JEDEC 4.51 works but JEDEC 4.41 does not

Derek Wilson
Intellectual 380 points
Part Number: OMAP-L138
Other Parts Discussed in Thread: OMAPL138, CSD

Hi,

We have a custom board on which which are interfacing a Micron MMC (specifically, MTFC4GACAANA-4M IT implementing JEDEC Standard No. 84-B451).  We have had this up and working for a couple years now.  We have now found that we are unable to obtain any more of these Micron chips, so we found what we believe is a pin for pin compatible device (Micron MTFC4GLGDQ-AIT Z implementing JEDEC A441).

The problem I am seeing is that when we use the new part, I don't seem to get a response from the MMC chip.  The SYS/BIOS driver detects it as an MMC, but an IOCTL_START never responds from the chip.  We assumed that moving from the 4.51 standard to the 4.41 standard would be fine without any changes to the driver or to our initialization code.  Am I missing something, or does someone have any idea where to look for more information regarding the OMAP-L138's compatibility with the older JEDEC standard?

Specifically, we have a small DSP only application which we first load over JTAG during board checkout and which is responsible for programming a Linux kernel to the MMC.  From here on out, the ARM core boots from the MMC.

Could we consider a later JEDEC standard to which the OMAP-L138 IP is compatible?

Many thanks in advance for your responses!

  • 0
    TI__Guru 65405 points
    Hi Derek,

    I've forwarded your query to the hardware design team. Their feedback should be posted here.

    BR
    Tsvetolin Shulev
  • 0 in reply to Cvetolin Shulev-XID
    Intellectual 380 points

    Thanks, Tsvetolin.  I wasn't quite sure in which forum to post my question, but hopefully they have some ideas!

  • 0
    TI__Guru* 78325 points
    Hi Derek
    The MMC IP on OMAPL138 is v4.0 compliant , however as you know with every rev up there is backward compatibility and as you saw you have v4.5 cards working but some issues with v4.4.
    It is likely some software or hardware issue is what is my guess.

    Do you have the ability to try MMC from other vendors?
    What is the software base you are using for your development?

    You may find posts like the following relevant
    e2e.ti.com/.../255685

    There were several posters mentioning some troubles with various cards (MMC or eMMC) but eventually I think most had them working and I have not heard of any issues lately.

    Hope this helps some.

    Regards
    Mukul
  • 0 in reply to Mukul Bhatnagar
    Intellectual 380 points
    Thank you, Mukul. These are custom boards, and we were looking for a pin compatible replacement part to replace a chip which Micron seems to have discontinued. The MMC is soldered to the board, and this is the only pin compatible device we have found. We simply removed the existing v4.5 chip and soldered on the new v4.4 (replacement) chip and expected it to work.

    I believe it may be a hardware or software issue as you noted. I guess my question is:
    - If my software works with a v4.5 card, shouldn't it work with a v4.4 card without modification? As far as bus width and total memory, there are no differences between the 2 cards.
  • 0 in reply to Derek Wilson
    TI__Guru* 78325 points
    Hi Derek
    Yes I would've expected it to work.
    I will point this thread to some of the software developers to see if they have any further guidance based on their experience.

    I remember when we were trying v5.0 cards (which also seem to work) , there was a change needed in the card revision field ( I do not have the jedec spec handy to see if there is any difference between v4.5 vs v4.4)



    git.kernel.org/.../mmc.c
    /*
    * The EXT_CSD format is meant to be forward compatible. As long
    * as CSD_STRUCTURE does not change, all values for EXT_CSD_REV
    * are authorized, see JEDEC JESD84-B50 section B.8.



    Regards
    Mukul
  • 0
    TI__Guru* 78325 points

    Hi Derek

    The software team still wanted to understand your exact testing.

    'The problem I am seeing is that when we use the new part, I don't seem to get a response from the MMC chip.  The SYS/BIOS driver detects it as an MMC, but an IOCTL_START never responds from the chip.  We assumed that moving from the 4.51 standard to the 4.41 standard would be fine without any changes to the driver or to our initialization code.  Am I missing something, or does someone have any idea where to look for more information regarding the OMAP-L138's compatibility with the older JEDEC standard?

    Specifically, we have a small DSP only application which we first load over JTAG during board checkout and which is responsible for programming a Linux kernel to the MMC.  From here on out, the ARM core boots from the MMC."

     


    Is the SYS/BIOS driver a custom driver or based on some TI release? Even if the DSP only (diagnostic?) program fails, is MMC functioning from ARM/ Linux side? When you say ARM core boot from MMC, is it primary/device boot load (using RBL) or is your primary device boot mode something else and then you pull the rest of the image via eMMC ?

  • 0 in reply to Mukul Bhatnagar
    Intellectual 380 points

    Hi Mukul,

    I am using the MMC driver from BIOSPSP v3.0.1.0 unmodified.

    I am unable to tell if the MMC is functioning from the Linux side because I cannot load a kernel to the ARM core without the MMC.  I have never figured out how to load the ARM Linux kernel (or uBoot) over JTAG.

    Our custom OMAP-L138 board has 2 boot switch configurations (selectable by a switch): 1 is for booting over JTAG, and the other is for booting from an MMC.  To program the MMC, I first select the JTAG boot switch configuration then load a small custom application onto the DSP.  This application contains the linux kernel and uBoot as binary data, and upon execution, the DSP writes the binary data to the MMC at the proper load addresses.  I then switch the boot switches to the MMC boot configuration and power cycle the board.  At that point, the ARM starts uBoot which then autoboots the Linux kernel.

    It's possible that we have a soldering issue with the new MMC chip.  I was just curious if there was something I might be missing in the software configuration/initialization of the MMC between the JEDEC versions.

  • 0 in reply to Derek Wilson
    Intellectual 380 points

    I've received the board back with the MMC memory chip being swapped back to the old production version we've been using, and I am able to program it and boot from it.  Our tech indicated that when he pulled the previous MMC off, there didn't appear to be any soldering issues with it.  So we're further convinced it wasn't a hardware issue preventing us from accessing the chip.

    Could there be some additional reason why the 4.51 chip works fine but 4.41 chip does not?  I'm not sure spending several days aimlessly digging through the spec and driver code is worth the considerable amount of effort, but we'd like to understand this issue.  Thanks in advance!

    Derek

  • 0 in reply to Derek Wilson
    TI__Guru* 78325 points
    Derek
    Sorry for the late response. I will discuss this further with the software team to see if they have any suggestions.
    The BIOS PSP that you are using is pretty old and does not have much support around it.

    Would it be possible for you to see the latest driver offerings for MMC for OMAPL138 from the Processor SDK RTOS package

    software-dl.ti.com/.../index_FDS.html

    Not sure on how different the package maybe , but perhaps a diff on the source files may help some.

    additionally Do you have more boards with v4.41 memory to test out the failure. Don't think you shared info on where it failed, was it able to read anything out of the MMC and or did you see any data/commands on the bus?