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.

Multi-block reads disabled in Adeneo 02.30.00 SDHC driver

Other Parts Discussed in Thread: OMAP3530, AM3358

Just wanted to point out this potential issue in version 02.30.00 of the A8 BSP - apologies if this has been discussed before.

C:\WINCE700\PLATFORM\COMMON\SRC\SOC\COMMON_TI_V1\COMMON_TI\SDHC\BASE\sdhc.cpp, line 601:

BOOL CSDIOControllerBase::IsMultipleBlockReadSupported()
{
    BOOL bVal = FALSE;//TRUE;
    // work around for a OMAP35XX silicon issue (data CRC error on READ_MULTIPLE_BLOCK command)
    // This is present in earley processor revisions
    if(m_dwCPURev <= CPU_FAMILY_35XX_REVISION_ES_3_0)
    {
        bVal = FALSE;
    }
    return bVal;
}

A few problems with this function:

1)
It always returns FALSE.
As a result, the SDHC driver passes SD_SLOT_USE_SOFT_BLOCK_CMD53_READ to the bus driver - an obvious performance problem.
I suspect the code was modified for testing, and someone forgot to change the bVal initialisation back to TRUE.

2)
The code assumes the CRC error occurs on ES3.0 silicon, but according to advisory 2.1.1.128 in my copy of the OMAP errata, it was actually fixed in 3.0.

3)
As far as I can see, all the SD interfaces on a given CPU would have block read operations disabled, even though only MMC1 and MMC2 are affected on the OMAP.

  • Hi,

    We are looking into this and we'll try to respond by the middle of next week.

    Regards,

  • Hi, Carsten.

    the simular issue present into WINCE6 :(

    http://e2e.ti.com/support/embedded/wince/f/353/p/169821/634760.aspx

  • Hi Carsten,

    The IsMultipleBlockReadSupported was created between the 6.15 BSP release and the WinCE6.0 TI Common BSP A8_01_00_00.  During that time the function was implement o return false all of the time.  In \PLATFORM\EVM_OMAP3530\SRC\DRIVERS\SDMEMORY\SDMemCardIO.cpp as there is a check for the CPU_FAMILY_35XX_REVISION_ES_3_0 related to multiblock reads.  This change existed in the 6.15 BSP and might go back further.  We expect because the original implementation of the multiblock read check in SDMemCardIO.cpp included the ES_3_0 processors any enhancement related to the multi-block read was updated to include the ES_3_0 processors as well.

    So in order to fully support the multiblock reads one would also need to update SDMemReadMultiple in SDMemCardIO.cpp and IsMultipleBlockReadSupported in sdhc.cpp.  

    These changes would be considered an enhancement to the BSP and would need to be planned into a future release.

    Regards,

  • No it is not an enhancement. The multiblock read feature is already implemented, in there and working, it is just the test for support is wrong as Carten correctly pointed out.

    As for #1 you are correct it is a bug and does hughly effect performance. I had corrected this some time back and seen a big jump in load times.You need 3.1 or later silicon which has been shipping for some time now.

    Not sure about #2.

    As for #3 I do not think so. MMC1 and MMC2 are the only two SD controllers on the 35XX, what other SDHC/SD interface could you be refering too? MMC3 maybe but they conviently left out support for that one (and you can not boot from it).

  • David,

    Regarding #2, it says on page 114 in the errata (SPRZ278E):

    Advisory 2.1.1.128         MMC: Multiple Block Read Operation Issue
    Revision(s) Affected     2.1 and earlier

    As for #3, yes I was referring to MMC3, which we actually used on a prototype device, but as you point out MMC3 is not supported at all in the standard BSP so one might argue it is missing functionality rather than a bug. I just wanted to mention it for completeness.

  • Hi,

    I'm afraid I don't entirely agree with this being an enhancement - as David already said, the functionality is already there, it's just never enabled.

    Please could I suggest you review the code again? It would appear to be a simple fix, and one which future users of the BSP are unlikely to come across unless they specifically suspect something is not right in this area.

    Cheers,
    Carsten

  • Hi Carsten/David,

    great info here; digging up this old thread. I am now diving into SDIO comms using SDHC in the same BSP on our custom AM3358 board; this is to talk to a WiFi module.  I have really noticed performance issues and failures when trying to talk to the connected SDIO Wifi Module.

    Unfortunately the driver for this is a third party DLL, so I am not familiar with what it is trying to do, but I do notice that the system freezes when it tries to do stuff with the Wifi module then comes to life again.  

    The issues you have raised sound like the culprit for the freezes at least, fingers crossed for my errors too though.

    So to fix this, I just need to set BOOL bVal = TRUE; in 

    BOOL CSDIOControllerBase::IsMultipleBlockReadSupported() ?

     

    This thread touches on a lack of BSP support for MMC3; guess which MMC interface our custom board has the WiFi module connected to? The 3rd slot (MMC2/MMC3 slot depending on who is doing the counting) :-).  Someone hates me somewhere out there.

    I managed to find some places to change in the code to get MMC3 working a bit, but I have realised that EDMA needs configured to add support for the MMC3 DMA and EDMA events and these events are CrossBar mapped (multiplexed), so it doesn't look like a straight forward exercise from what I can see so far.  If I ever get a full solution for adding in MMC3 support I will post a thread on how to do it.

     

    Thanks

     

    John

     

  • SDHC3 can be made to work with wifi, I have done it.

    Please email me direct at davidves-at-tampabay.rr.com