• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 97 subscribers
  • Views 498 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

C6748 MMC Documentation Error

Norman Wong
Guru 26430 points
Other Parts Discussed in Thread: TMS320C6748

The response bit definitions in the TRM do not match actual usage in ARM Linux and U-Boot. Coding using the TRM bit positions will cause the SD Card to as the RCA will be wrong.

TMS320C6748 DSP
Technical Reference Manual
Literature Number: SPRUH79A
December 2011

Table 25-21. R1, R3, R4, R5, or R6 Response (48 Bits)
Bit Position of Response Register
47-40 MMCCIDX
39-24 MMCRSP7
23-8 MMCRSP6
7-0 MMCRSP5(1)
- MMCRSP4-0

I think the documentation should be:

31-16 MMCRSP7
15-0 MMCRSP6

U-Boot and Linux discard 47-32. Where would those bits be if I wanted to extract them from the response registers?

  • 0
    TI__Mastermind 43955 points

    Hi Norman,

    Please let us know the version of ARM Linux and U-Boot you are referring to. So that, we will also have a look and get back to you.

     

    Regards,

    Shankari

  • 0 in reply to Shankari G
    Guru 26430 points

    Any version. I don't think the code has changed in years.

    GIT: git.denx.de - head
    FILE: drivers/mmc/davinci_mmc.c
    FUNC:dmmc_send_cmd()
    LINE:cmd->response[0] = get_val(&regs->mmcrsp67);

    GIT: arago-project.org - u-boot-davinci head
    FILE: drivers/mmc/davinci_mmc.c
    FUNC:dmmc_send_cmd()
    LINE:cmd->response[0] = get_val(&regs->mmcrsp67);

    GIT: kernel.org - head
    FILE: drivers/mmc/host/davinci_mmc.c
    FUNC:mmc_davinci_cmd_done()
    LINE:cmd->resp[0] = readl(host->base + DAVINCI_MMCRSP67);

    GIT: arago-project.org - linux-davinci head
    FILE: drivers/mmc/host/davinci_mmc.c
    FUNC:mmc_davinci_cmd_done()
    LINE:cmd->resp[0] = readl(host->base + DAVINCI_MMCRSP67);

    I am porting the AM335x StarterWare MMC/SD example to C6748 and using the lowest 8 bits of MMCRSP45 for response bits 7:0 does not work. Wrong values causes the SD Card to hang.

  • 0 in reply to Norman Wong
    TI__Mastermind 43955 points

    Hi Norman,

    From my end, I have also checked in few versions of Davinci linux (file: "drivers/mmc/host/davinci_mmc.c" at function "mmc_davinci_cmd_done() ") and noticed exactly what you said. It leads me to the same questions. When I compared the two versions, it gives me a hint that according to the "Response type" ( i.e.., R1,R2,R3,R4,R5, R6, R1b e.t.c) and the length of the response type - 48 bits or 136 bits, the read to the number of response bits from the response registers varied. That is,  if the Response-Data-length  is 136, 120 bits are extracted from response registers and if the Response-Data-length  is 48, 32 bits are extracted from the response registers.

    When I referred to the  http://www.ti.com/lit/ug/spru765a/spru765a.pdf, it re-directed to "SD Host controller simplified specification" document. Page No: 42 explains what we are looking for. It says, only part of the response data is stored in the response registers to increase the response read efficiency by completing in one read cycle of 32-bit bus sytem and the rest will be extracted from the command registers.

     

     Regards,

    Shankari

     

    -------------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question.
    --------------------------------------------------------------------------------------------------------

  • 0 in reply to Shankari G
    Guru 26430 points

    Okay. That makes sense for u-boot and linux. For 48 bit messages, their code must store R[39:8] in array response[0] and all bitmasks are shifted to match. The famously lack of documentation in code doesn't say as much. For 136 bit messages, their code saves last 128 bits but appear to use first 120 bits of that 128 bits. That matches the SD spec. The C6748 documentation is correct.

    The AM335x code is still a bit of a puzzle as it appears to save R[31:0] in response[0] but the bitmasks used in StarterWare appear to match the shifted masks in u-boot/linux. A straight forward match of AM335x response registers to C6748 response register doesn't seem to work.