[Bug 1001764] New: Enhancement of MMC/SD over SPI driver

[Bug 1001764] New: Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

            Bug ID: 1001764
           Summary: Enhancement of MMC/SD over SPI driver
           Product: eCos
           Version: CVS
            Target: All
  Architecture/Host Other
                OS:
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: low
         Component: Disk
          Assignee: unassigned@bugs.ecos.sourceware.org
          Reporter: ilijas@siva.com.mk
                CC: ecos-bugs@ecos.sourceware.org

Created attachment 2094
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2094&action=edit
Enhanced MMC/SD over SPI driver

Original MMC/SD driver supports only Standard Capacity SD cards, besides MMC.
SDSC is becoming increasingly hard to find on the market, while SDHC are
largely available. This bug introduces support for SDHC cards. No attempt was
made to support newer MMC cards. It's been tested with these cards:
MMC Standard 16MB
MMC Standard 32MB
SD Standard Capacity 512MB
SD Standard Capacity 2GB
SD High Capacity 8GB

All cards were tested on both ST32 and Kinetis K60 platforms. SD cards were
tested on Kinetis K70 platform too.

I had no SD Extended Capacity at hand, but, according to SD Physical Layer
Simplified Specification Ver_3.01, it should work also with SDEC cards.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

Mike Jones <mjones@linear.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjones@linear.com

--- Comment #1 from Mike Jones <mjones@linear.com> ---
I tested this with SD 2GB, SD 4GB, SD 8GB using Tower K60. Works fine.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #2 from Mike Jones <mjones@linear.com> ---
Worked with Micro 2GB and 8GB. Did not work with Micro 4GB.

All the cards I tested were SanDisk except the Micro 4GB which was Samsung. I
tested two brand new Samsung 4GB and they both mount on Linux properly and were
formatted by the Linux Disk Manager like the other cards. All FAT32.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #3 from Ilija Stanislevik <ilijas@siva.com.mk> ---
(In reply to comment #2)
> Worked with Micro 2GB and 8GB. Did not work with Micro 4GB.
> 
> All the cards I tested were SanDisk except the Micro 4GB which was Samsung.

Mike,

I am trying to repeat your test with 4GB card. Can you give me the model name
of the one you have tried?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #4 from Mike Jones <mjones@linear.com> ---
Samsung Model MB-MS4GB 
Class 4 Micro SDHC

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #5 from Ilija Stanislevik <ilijas@siva.com.mk> ---
(In reply to comment #4)
I couldn't find this model, so I can't repeat your test. Tried with Transcend
brand 4GB class 4 SDHC and it works.

Mike, can you locate the point where the driver fails? Maybe you can present
some printout with DEBUG enabled.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #8 from Ilija Stanislevik <ilijas@siva.com.mk> ---
Created attachment 2132
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2132&action=edit
Patch in light of bug 1001676

This might be related to bug 1001676. This is a patch suggested by Ilija Kocho.
Mike, can you try your 4GB card with this patch on dspi driver?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #9 from Mike Jones <mjones@linear.com> ---
I tried the patch but the behavior is exactly the same. I don't have other
cards with me, so I don't know if it impacted behavior of other cards.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #10 from Mike Jones <mjones@linear.com> ---
I have verified that this patch did not harm with a 2GB and 8GB SanDisk. I
don't have time to debug the Samsung card now. If the cost is not too great, I
can ship a 4GB Samsung card to someone interested in debugging it. If someone
is willing to debug, e-mail me an address so I can check the shipping costs.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEEDINFO
                 CC|                            |ilijak@siva.com.mk
     Ever confirmed|0                           |1

--- Comment #11 from Ilija Kocho <ilijak@siva.com.mk> ---
Mike

We need to figure-out where is the problem, The card or MMC driver or some of
SPI drivers. I tried to get Samsung SD card in several EU countries but failed.
Can you please do some tests for us?

Can you do post a screen capture of diagnostic output from minicom? (text
captyre preferable to screen).

Also if possible please try with different platforms: Kinetis, STM32, etc and
see if it makes difference.

Thanks
Ilija

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #12 from Mike Jones <mjones@linear.com> ---
Due to heavy load, I can't do much until first two weeks of May. I'll put this
on my priority list for early May. If there is some opportunity for free time,
I'll send what I can early.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #14 from Mike Jones <mjones@linear.com> ---
I took several micro cards and plugged them into the larger carrier and tested
on the K60 Tower, leaving the code to use response[3].

The SanDisk Ultra 8GB micro SDHC 1 does not respond to the init command 40 00
00 00 00 95.

The Samsung 4GB micro SDHC discussed earlier and having problems does not
respond to init command 40 00 00 00 00 95.

The SanDisk 2GB micro SD responds to the init command... and fails in this
code:

    if ( 1 == disk->sd_csd_version) {
      // There is information available about the file format, e.g.
      // partitioned vs. simple FAT. With the current version of the
      // generic disk code this needs to be known statically, via
      // the mbr field of the disk channel structure. If the card
      // is inappropriately formatted, reject the mount request.
      if ((0 != MMC_CSD_REGISTER_FILE_FORMAT_GROUP(&csd)) ||
          (0 != MMC_CSD_REGISTER_FILE_FORMAT(&csd))) {
          return -ENOTDIR;
      }
    } // Acco

Just like the SD 2GB mentioned in the last comment. Next steps will be to move
to my custom board with micro connector and test.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #15 from Mike Jones <mjones@linear.com> ---
On the hardware with micro SD, the return from 48 00 00 01 AA 87 on my 2GB
micro SD card puts the 01 in response[2] and the AA in response[3] which means
the original code works with my custom board..

So now differences. The Tower K60 is Rev 1 silicon and the custom board is Rev
2 silicon. The revisions in my CDL are correct.

The Tower is using a fx patched packages, and the custom is not, so I
differenced the trees and found no MMC/SD or SPI related differences.

So at this point the differences are silicon and board. The failing board is
the Tower K60 large SD card socket with old silicon, and the working board is a
custom K60 board with micro SD card socket.

I now move to the original problem Samsung card.

In this code:

  if (MMC_REPLY_ILLEGAL_COMMAND & reply) { // V1 cards do not understand CMD8
    disk->sd_version = 1;
    disk->sd_capacity = STANDARD_CAPACITY;
    mmc_spi_end_command(disk);
    return ENOERR;
  }

It enters as a V1 card. I don't have the Beagle attached yet. But this is the
difference from the working cards.

It then fails to enter the idle state.

I'll get the Beagle on it later.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #18 from Mike Jones <mjones@linear.com> ---
After brining up a custom K60 FXM board and testing, I have come to the
following conclusion:

1) My Tower hardware has been damaged 
2) The MMC patches are OK and problems I reported are related to the damaged
hardware
3) The 4GB Samsung card/s still do not work, even on the new board

Conclusion 2 is based on logical reasoning and observation, not a discovery of
root cause. It is always possible the problem is human error, or related to the
P1 K60 silicon.

I am traveling and will try to obtain other Samsung cards from the same vendor
so I can test them and find out if the problem is vendor or card specific.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #19 from Mike Jones <mjones@linear.com> ---
I am having some bad behavior in the SPI code when using MMC patch with FXM
with a stable application I used prior to FXM. Let me be upfront and say that I
did find some bad application code that was writing over memory when processing
some va_args, and I can't rule out other application errors, but I have
constrained the application code and very carefully looked at potential memory
issues, even looking at every sprintf for issues with formatting. So error free
application code is only an assumption.

(If anyone has suggestions on how to string process with type safety in an eCos
application, please offer advice. I assume it would have to be some C++
library, possibly with templates. I don't know what is practical within the
cortex tool chain.)

The application uses I2C, and an SD card. It reads lots of data from I2C and
writes to the SD card, but never at the same time.

The problem is a struct pointing to the SPI dev ends up with an address of
0xFFFFFFFF and this causes an exception 5. This happens in the SPI code inside
one call. During this call, all other threads are blocked.

I will describe where this happens in code and hope someone has ideas on how to
debug it, or perhaps the author might see something that indicates a possible
driver bug.

By instrumenting the code as follows:

cyg_spi_transaction_transfer(cyg_spi_device* device, cyg_bool polled,
                             cyg_uint32 count, const cyg_uint8* tx_data,
cyg_uint8* rx_data,
                             cyg_bool drop_cs)
{
    cyg_spi_bus*    bus;
    CYG_CHECK_DATA_PTR(device, "valid SPI device pointer required");

    if(tx_data == 0xFFFFFFFF || rx_data == 0xFFFFFFFF || device == 0xFFFFFFFF)
        return;

    if (device->spi_bus == 0xFFFFFFFF)
        return; 

    bus = device->spi_bus;

    if(bus->spi_transaction_transfer == NULL || bus->spi_transaction_transfer
== 0xFFFFFFFF)
        return;

    CYG_CHECK_DATA_PTR(bus, "SPI device does not point at a valid bus
structure");
    CYG_ASSERT(bus->spi_current_device == device, "SPI transfer requested
without claiming the bus");
    CYG_CHECK_FUNC_PTR(bus->spi_transaction_transfer, "SPI device has not
provided a transfer function");
    (*(bus->spi_transaction_transfer))(device, polled, count, tx_data, rx_data,
drop_cs);
}

Eventually it will break on the first return and device will be 0xFFFFFFFF.

By looking at the call chain, the problem occurs:

mmc_spi_send_command_start(cyg_mmc_spi_disk_info_t* disk, cyg_uint32 command,
cyg_uint32 arg)
{
    cyg_spi_device* dev = disk->mmc_spi_dev;
    cyg_uint8       request[7];
    cyg_uint8       response[7];
    cyg_uint8       reply;
    int             i;

...

    reply       = response[6];
    for (i = 0; (i < MMC_SPI_COMMAND_RETRIES) && (0 != (reply & 0x0080)); i++)
{
        cyg_spi_transaction_transfer(dev, cyg_mmc_spi_polled, 1,
mmc_spi_ff_data, response, 0);
        reply = response[0];

in the retry loop. Before this in the code with ... is also a
cyg_spi_transaction_transfer call. The bad address NEVER occurs on the first
use of transfer, and ALWAYS occurs in the second call to transfer, but only
after running a long time.

If I examine variables in mmc_spi_send_command_start, the disk->mmc_spi_dev has
a good address, and dev does not. This implies that somewhere between the
assignment at the top and the retry loop it gets overwritten.

The underlying code is using the request and reply arrays, possibly with DMA. I
don't see any simple way to explain the messed up address, as the dev address
is lower than the arrays. All F's is also an unusual value, other than the 512
byte buffer for sending FFs to the device to clear it. But that is pretty much
static data, so it would require a copy to cause this problem.

Also, note that the I2C is reading on a 100ms interval from a counter/timer,
and then writing to SD. The application runs for several minutes before the
problem occurs. So the code is basically performing the same operation every
100ms and then after some time fails.

I created some test code to malloc all 16M of the memory and test with 0x55 and
0xAA, and a counter, etc, and I don't get any memory failures. I basically
malloc in 100K chunks, test, and then free at the end, and then do it again,
etc. So I believe the underlying memory system is ok.

Does anyone have ideas that might help narrow this down?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #20 from Mike Jones <mjones@linear.com> ---
After getting some help from Ilija and a lot of debugging, I believe the
exception problem is limited only to FXM. My application is quite stable on
non-FXM hardware. My application is quite stable when I disable SPI DMA on FXM.
The problem seems to be related to DMA with FXM. Any further discussion from me
will be moved to the FXM bug.

Therefore, from my point of view, the only real issue with MMC is the problem
Samsung card, which I think could be ignored for now and the code could be
committed to CVS. The failing card came from a retailer that is known to sell
old products from time to time and I doubt anyone will have a problem.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

Ilija Stanislevik <ilijas@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2132|0                           |1
        is obsolete|                            |

--- Comment #21 from Ilija Stanislevik <ilijas@siva.com.mk> ---
Comment on attachment 2132
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2132
Patch in light of bug 1001676

Obsoleted as it's been proven useless.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #22 from Mike Jones <mjones@linear.com> ---
I have had more bench time on the MMC, so I have more information about its
operation under heavy use.

First, my setup is atypical. I have a cable on J5 of the Kinetis tower board
that connects to another board 30cm away. This board has its own power supply
off line. Therefore, because there is a ground connection in J5, there is a
ground loop. Furthermore, I am using the I2C lines in the J5 connector.

I have seen four problems:

1) Can't mount Samsung microSD
2) Can't mount any microSD
3) IO failure after three hours of intense operation (logging MB to card)
4) Can't get DMA to work reliably

I have some new information. I was debugging the TWR-DACADC-LTC and noticed
problem 2. When I removed the ground clips from my scope, problem 2 went away.
This leads me to the conclusion that problems 2 and 3 are related to grounding
problems. I can't prove grounding is causing 3 until I have a single board
version of my solution.

Problems 1 and 4 still seem to be problems that only affect me. I work around
them by not using DMA and not using the Samsung card. I am certain that problem
1 is not related to grounding. I have tested for that. I am reasonable certain
problem 4 is not related to grounding, I am pretty sure I have seen the problem
with my cable removed.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #23 from Ilija Kocho <ilijak@siva.com.mk> ---
It seem that the Samsung card is a kind of singularity as far I understand it's
a single instance. I couldn't find one to try. All other cards work properly. I
wouldn't hold the driver just for a single instance, so I am going to commit.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #24 from Mike Jones <mjones@linear.com> ---
Thank you. I see no reason not to commit it.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |RESOLVED
         Resolution|---                         |CURRENTRELEASE

--- Comment #25 from Ilija Kocho <ilijak@siva.com.mk> ---
Checked in.

Thanks to Ilija Stanislevik for the patch and to Muke Jones for testing.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |RESOLVED
         Resolution|---                         |CURRENTRELEASE

--- Comment #25 from Ilija Kocho <ilijak@siva.com.mk> ---
Checked in.

Thanks to Ilija Stanislevik for the patch and to Muke Jones for testing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #24 from Mike Jones <mjones@linear.com> ---
Thank you. I see no reason not to commit it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #23 from Ilija Kocho <ilijak@siva.com.mk> ---
It seem that the Samsung card is a kind of singularity as far I understand it's
a single instance. I couldn't find one to try. All other cards work properly. I
wouldn't hold the driver just for a single instance, so I am going to commit.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #22 from Mike Jones <mjones@linear.com> ---
I have had more bench time on the MMC, so I have more information about its
operation under heavy use.

First, my setup is atypical. I have a cable on J5 of the Kinetis tower board
that connects to another board 30cm away. This board has its own power supply
off line. Therefore, because there is a ground connection in J5, there is a
ground loop. Furthermore, I am using the I2C lines in the J5 connector.

I have seen four problems:

1) Can't mount Samsung microSD
2) Can't mount any microSD
3) IO failure after three hours of intense operation (logging MB to card)
4) Can't get DMA to work reliably

I have some new information. I was debugging the TWR-DACADC-LTC and noticed
problem 2. When I removed the ground clips from my scope, problem 2 went away.
This leads me to the conclusion that problems 2 and 3 are related to grounding
problems. I can't prove grounding is causing 3 until I have a single board
version of my solution.

Problems 1 and 4 still seem to be problems that only affect me. I work around
them by not using DMA and not using the Samsung card. I am certain that problem
1 is not related to grounding. I have tested for that. I am reasonable certain
problem 4 is not related to grounding, I am pretty sure I have seen the problem
with my cable removed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

Ilija Stanislevik <ilijas@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2132|0                           |1
        is obsolete|                            |

--- Comment #21 from Ilija Stanislevik <ilijas@siva.com.mk> ---
Comment on attachment 2132
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2132
Patch in light of bug 1001676

Obsoleted as it's been proven useless.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #20 from Mike Jones <mjones@linear.com> ---
After getting some help from Ilija and a lot of debugging, I believe the
exception problem is limited only to FXM. My application is quite stable on
non-FXM hardware. My application is quite stable when I disable SPI DMA on FXM.
The problem seems to be related to DMA with FXM. Any further discussion from me
will be moved to the FXM bug.

Therefore, from my point of view, the only real issue with MMC is the problem
Samsung card, which I think could be ignored for now and the code could be
committed to CVS. The failing card came from a retailer that is known to sell
old products from time to time and I doubt anyone will have a problem.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #19 from Mike Jones <mjones@linear.com> ---
I am having some bad behavior in the SPI code when using MMC patch with FXM
with a stable application I used prior to FXM. Let me be upfront and say that I
did find some bad application code that was writing over memory when processing
some va_args, and I can't rule out other application errors, but I have
constrained the application code and very carefully looked at potential memory
issues, even looking at every sprintf for issues with formatting. So error free
application code is only an assumption.

(If anyone has suggestions on how to string process with type safety in an eCos
application, please offer advice. I assume it would have to be some C++
library, possibly with templates. I don't know what is practical within the
cortex tool chain.)

The application uses I2C, and an SD card. It reads lots of data from I2C and
writes to the SD card, but never at the same time.

The problem is a struct pointing to the SPI dev ends up with an address of
0xFFFFFFFF and this causes an exception 5. This happens in the SPI code inside
one call. During this call, all other threads are blocked.

I will describe where this happens in code and hope someone has ideas on how to
debug it, or perhaps the author might see something that indicates a possible
driver bug.

By instrumenting the code as follows:

cyg_spi_transaction_transfer(cyg_spi_device* device, cyg_bool polled,
                             cyg_uint32 count, const cyg_uint8* tx_data,
cyg_uint8* rx_data,
                             cyg_bool drop_cs)
{
    cyg_spi_bus*    bus;
    CYG_CHECK_DATA_PTR(device, "valid SPI device pointer required");

    if(tx_data == 0xFFFFFFFF || rx_data == 0xFFFFFFFF || device == 0xFFFFFFFF)
        return;

    if (device->spi_bus == 0xFFFFFFFF)
        return; 

    bus = device->spi_bus;

    if(bus->spi_transaction_transfer == NULL || bus->spi_transaction_transfer
== 0xFFFFFFFF)
        return;

    CYG_CHECK_DATA_PTR(bus, "SPI device does not point at a valid bus
structure");
    CYG_ASSERT(bus->spi_current_device == device, "SPI transfer requested
without claiming the bus");
    CYG_CHECK_FUNC_PTR(bus->spi_transaction_transfer, "SPI device has not
provided a transfer function");
    (*(bus->spi_transaction_transfer))(device, polled, count, tx_data, rx_data,
drop_cs);
}

Eventually it will break on the first return and device will be 0xFFFFFFFF.

By looking at the call chain, the problem occurs:

mmc_spi_send_command_start(cyg_mmc_spi_disk_info_t* disk, cyg_uint32 command,
cyg_uint32 arg)
{
    cyg_spi_device* dev = disk->mmc_spi_dev;
    cyg_uint8       request[7];
    cyg_uint8       response[7];
    cyg_uint8       reply;
    int             i;

...

    reply       = response[6];
    for (i = 0; (i < MMC_SPI_COMMAND_RETRIES) && (0 != (reply & 0x0080)); i++)
{
        cyg_spi_transaction_transfer(dev, cyg_mmc_spi_polled, 1,
mmc_spi_ff_data, response, 0);
        reply = response[0];

in the retry loop. Before this in the code with ... is also a
cyg_spi_transaction_transfer call. The bad address NEVER occurs on the first
use of transfer, and ALWAYS occurs in the second call to transfer, but only
after running a long time.

If I examine variables in mmc_spi_send_command_start, the disk->mmc_spi_dev has
a good address, and dev does not. This implies that somewhere between the
assignment at the top and the retry loop it gets overwritten.

The underlying code is using the request and reply arrays, possibly with DMA. I
don't see any simple way to explain the messed up address, as the dev address
is lower than the arrays. All F's is also an unusual value, other than the 512
byte buffer for sending FFs to the device to clear it. But that is pretty much
static data, so it would require a copy to cause this problem.

Also, note that the I2C is reading on a 100ms interval from a counter/timer,
and then writing to SD. The application runs for several minutes before the
problem occurs. So the code is basically performing the same operation every
100ms and then after some time fails.

I created some test code to malloc all 16M of the memory and test with 0x55 and
0xAA, and a counter, etc, and I don't get any memory failures. I basically
malloc in 100K chunks, test, and then free at the end, and then do it again,
etc. So I believe the underlying memory system is ok.

Does anyone have ideas that might help narrow this down?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #18 from Mike Jones <mjones@linear.com> ---
After brining up a custom K60 FXM board and testing, I have come to the
following conclusion:

1) My Tower hardware has been damaged 
2) The MMC patches are OK and problems I reported are related to the damaged
hardware
3) The 4GB Samsung card/s still do not work, even on the new board

Conclusion 2 is based on logical reasoning and observation, not a discovery of
root cause. It is always possible the problem is human error, or related to the
P1 K60 silicon.

I am traveling and will try to obtain other Samsung cards from the same vendor
so I can test them and find out if the problem is vendor or card specific.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #17 from Mike Jones <mjones@linear.com> ---
At Ilija's suggestion I tried changing Tick-only drops CS. The Samsung card
does not work with this with either setting, and the SanDisk card works with
both settings.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #16 from Mike Jones <mjones@linear.com> ---
Now I have the micro SD custom board with a Beagle and the offending Samsung
card which is now known to not get in the idle state.

The init 40 00 00 00 00 95 is sent and the reply includes:

FF C0 7F, and the reply in the code is getting the 0x7F.

       // The card should reply with 0x01. FF suggests that there is
        // no card. Any other response indicates some synchronization
        // problem. For example the card might still be responding to
        // some request from a previous session which aborted at an
        // inconvenient moment. Some dummy traffic is generated in the
        // hope that this gets things back in sync.
        if (0x01 != reply) {
            DEBUG1("%s(): loop %d, card did not enter idle state, code %02x\n",
                __FUNCTION__, i, reply);
            if (0x0ff != reply) {
                cyg_spi_transfer(dev, cyg_mmc_spi_polled, 128, mmc_spi_ff_data,
(cyg_uint8*) 0);
            }
        }

Execution gets to the cog_spi_transfer. The assumption in the code is lack of
0xFF means there is a card, but there is trouble. The Beagle reports a log of
clocks with 0xFF.

The code loops back around and gets the same response to the init.

My understanding is CMD0 returns an R1 response with the bits meaning:

B0 Idle State 
B1 Erase Reset
B2 Illegal Command 
B3 Com CRC Error 
B4 Erase Seq Error 
B5 Address Error 
B6 Parameter Error
B7 0

C0 seems an unlikely real value because bit 7 is not zero. 7F indicates all
errors and idle state.

As an experiment:

        if (0x01 != (reply & 0x01)) {
            DEBUG1("%s(): loop %d, card did not enter idle state, code %02x\n",
                __FUNCTION__, i, reply);
            if (0x0ff != reply) {
                cyg_spi_transfer(dev, cyg_mmc_spi_polled, 128, mmc_spi_ff_data,
(cyg_uint8*) 0);
            }
        }

I changed the top line and added "& 0x01" to ignore the other error bits. Made
the same change a few lines below after the loop.

Now the code passes through to the version command 48 00 00 01 AA 87 and it
returns C1 7F. The code sees the 7F as the reply. The code assumes this is a V1
card that does not understand CMD8. But it also did not really seem to
understand the reset.

By continuing on it is clear the card returns 7F for every command.

I put in a working 2GMB SanDisk so I can compare its behavior.

It is interesting that the version command returns in the Beagle view 01 00 00
01 AA FF, but it places the second 01 at response[2]. This same card when
plugged into the larger SD carrier on the Tower board put that at response[3].
Therefore, it is clear that the Tower card, the one with V1 silicon, has the
same data, but shifted in the code.

Back to the Samsung card.

I slow down the clock to 1Mhz. Same result.

I tried to turn of double baud rate, but get a compile error in
spi_freescale_dspi.c line 194 

Description    Resource    Path    Location    Type
‘CYGHWR_DEVS_FREESCALEDSPI_DSPI_CTAR1_AUX_USE_DBR’ undeclared here (not in a
function)    Sidekick2-4        line 194, external location:
/opt/ecos/ecos-3.0/packages/devs/spi/freescale/dspi/current/src/spi_freescale_dspi.c
   C/C++ Problem

So that was a dead end.

Changed Normal chip select delay to 0. No difference.

As a final test, I plug the Samsung card into linux and it works.

I might have time for a short experiment before my trip. Near term, getting the
2GB card to work on the Tower is of higher value to me than fixing the Samsung
card. I will have more time in early May, but I am out of ideas other than
looking at the timing of the MOSI to make sure it is aligned with the SCLK.
However, running at 1Mhz should have eliminated that as a possibility. I also
verified with the Beagle that the bus ran slower. But did not verify this on
the scope.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From ecos-bugs-return-10218-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Apr 18 21:16:42 2013
Return-Path: <ecos-bugs-return-10218-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 7620 invoked by alias); 18 Apr 2013 21:16:42 -0000
Mailing-List: contact ecos-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <ecos-bugs.sourceware.org>
List-Subscribe: <mailto:ecos-bugs-subscribe@sourceware.org>
List-Post: <mailto:ecos-bugs@sourceware.org>
List-Help: <mailto:ecos-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: ecos-bugs-owner@sourceware.org
Delivered-To: mailing list ecos-bugs@sourceware.org
Received: (qmail 7581 invoked by uid 89); 18 Apr 2013 21:16:41 -0000
X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD autolearn=ham version=3.3.1
Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197)
    by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 18 Apr 2013 21:16:40 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id A15DC4680016; Thu, 18 Apr 2013 22:16:38 +0100 (BST)
X-Original-To: unassigned@bugs.ecos.sourceware.org
Delivered-To: unassigned@bugs.ecos.sourceware.org
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: unassigned@bugs.ecos.sourceware.org
Subject: [Bug 1001764] Enhancement of MMC/SD over SPI driver
Date: Thu, 18 Apr 2013 21:16:00 -0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: Disk
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: mjones@linear.com
X-Bugzilla-Status: NEEDINFO
X-Bugzilla-Priority: low
X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-1001764-777-qMdoEFX9lJ@http.bugs.ecos.sourceware.org/>
In-Reply-To: <bug-1001764-777@http.bugs.ecos.sourceware.org/>
References: <bug-1001764-777@http.bugs.ecos.sourceware.org/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://bugs.ecos.sourceware.org/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013/txt/msg00249.txt.bz2
Content-length: 4094

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #16 from Mike Jones <mjones@linear.com> ---
Now I have the micro SD custom board with a Beagle and the offending Samsung
card which is now known to not get in the idle state.

The init 40 00 00 00 00 95 is sent and the reply includes:

FF C0 7F, and the reply in the code is getting the 0x7F.

       // The card should reply with 0x01. FF suggests that there is
        // no card. Any other response indicates some synchronization
        // problem. For example the card might still be responding to
        // some request from a previous session which aborted at an
        // inconvenient moment. Some dummy traffic is generated in the
        // hope that this gets things back in sync.
        if (0x01 != reply) {
            DEBUG1("%s(): loop %d, card did not enter idle state, code %02x\n",
                __FUNCTION__, i, reply);
            if (0x0ff != reply) {
                cyg_spi_transfer(dev, cyg_mmc_spi_polled, 128, mmc_spi_ff_data,
(cyg_uint8*) 0);
            }
        }

Execution gets to the cog_spi_transfer. The assumption in the code is lack of
0xFF means there is a card, but there is trouble. The Beagle reports a log of
clocks with 0xFF.

The code loops back around and gets the same response to the init.

My understanding is CMD0 returns an R1 response with the bits meaning:

B0 Idle State 
B1 Erase Reset
B2 Illegal Command 
B3 Com CRC Error 
B4 Erase Seq Error 
B5 Address Error 
B6 Parameter Error
B7 0

C0 seems an unlikely real value because bit 7 is not zero. 7F indicates all
errors and idle state.

As an experiment:

        if (0x01 != (reply & 0x01)) {
            DEBUG1("%s(): loop %d, card did not enter idle state, code %02x\n",
                __FUNCTION__, i, reply);
            if (0x0ff != reply) {
                cyg_spi_transfer(dev, cyg_mmc_spi_polled, 128, mmc_spi_ff_data,
(cyg_uint8*) 0);
            }
        }

I changed the top line and added "& 0x01" to ignore the other error bits. Made
the same change a few lines below after the loop.

Now the code passes through to the version command 48 00 00 01 AA 87 and it
returns C1 7F. The code sees the 7F as the reply. The code assumes this is a V1
card that does not understand CMD8. But it also did not really seem to
understand the reset.

By continuing on it is clear the card returns 7F for every command.

I put in a working 2GMB SanDisk so I can compare its behavior.

It is interesting that the version command returns in the Beagle view 01 00 00
01 AA FF, but it places the second 01 at response[2]. This same card when
plugged into the larger SD carrier on the Tower board put that at response[3].
Therefore, it is clear that the Tower card, the one with V1 silicon, has the
same data, but shifted in the code.

Back to the Samsung card.

I slow down the clock to 1Mhz. Same result.

I tried to turn of double baud rate, but get a compile error in
spi_freescale_dspi.c line 194 

Description    Resource    Path    Location    Type
‘CYGHWR_DEVS_FREESCALEDSPI_DSPI_CTAR1_AUX_USE_DBR’ undeclared here (not in a
function)    Sidekick2-4        line 194, external location:
/opt/ecos/ecos-3.0/packages/devs/spi/freescale/dspi/current/src/spi_freescale_dspi.c
   C/C++ Problem

So that was a dead end.

Changed Normal chip select delay to 0. No difference.

As a final test, I plug the Samsung card into linux and it works.

I might have time for a short experiment before my trip. Near term, getting the
2GB card to work on the Tower is of higher value to me than fixing the Samsung
card. I will have more time in early May, but I am out of ideas other than
looking at the timing of the MOSI to make sure it is aligned with the SCLK.
However, running at 1Mhz should have eliminated that as a possibility. I also
verified with the Beagle that the bus ran slower. But did not verify this on
the scope.

-- 
You are receiving this mail because:
You are the assignee for the bug.
>From ecos-bugs-return-10220-listarch-ecos-bugs=sources.redhat.com@sourceware.org Fri Apr 19 16:17:27 2013
Return-Path: <ecos-bugs-return-10220-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 7708 invoked by alias); 19 Apr 2013 16:17:27 -0000
Mailing-List: contact ecos-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <ecos-bugs.sourceware.org>
List-Subscribe: <mailto:ecos-bugs-subscribe@sourceware.org>
List-Post: <mailto:ecos-bugs@sourceware.org>
List-Help: <mailto:ecos-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: ecos-bugs-owner@sourceware.org
Delivered-To: mailing list ecos-bugs@sourceware.org
Received: (qmail 7674 invoked by uid 89); 19 Apr 2013 16:17:27 -0000
X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD autolearn=ham version=3.3.1
Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197)
    by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 19 Apr 2013 16:17:25 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id D30134680007; Fri, 19 Apr 2013 17:17:23 +0100 (BST)
X-Original-To: unassigned@bugs.ecos.sourceware.org
Delivered-To: unassigned@bugs.ecos.sourceware.org
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: unassigned@bugs.ecos.sourceware.org
Subject: [Bug 1001764] Enhancement of MMC/SD over SPI driver
Date: Fri, 19 Apr 2013 16:17:00 -0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: Disk
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: mjones@linear.com
X-Bugzilla-Status: NEEDINFO
X-Bugzilla-Priority: low
X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-1001764-777-q7f2rhIGW2@http.bugs.ecos.sourceware.org/>
In-Reply-To: <bug-1001764-777@http.bugs.ecos.sourceware.org/>
References: <bug-1001764-777@http.bugs.ecos.sourceware.org/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://bugs.ecos.sourceware.org/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013/txt/msg00251.txt.bz2
Content-length: 414

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001764

--- Comment #17 from Mike Jones <mjones@linear.com> ---
At Ilija's suggestion I tried changing Tick-only drops CS. The Samsung card
does not work with this with either setting, and the SanDisk card works with
both settings.

--
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #15 from Mike Jones <mjones@linear.com> ---
On the hardware with micro SD, the return from 48 00 00 01 AA 87 on my 2GB
micro SD card puts the 01 in response[2] and the AA in response[3] which means
the original code works with my custom board..

So now differences. The Tower K60 is Rev 1 silicon and the custom board is Rev
2 silicon. The revisions in my CDL are correct.

The Tower is using a fx patched packages, and the custom is not, so I
differenced the trees and found no MMC/SD or SPI related differences.

So at this point the differences are silicon and board. The failing board is
the Tower K60 large SD card socket with old silicon, and the working board is a
custom K60 board with micro SD card socket.

I now move to the original problem Samsung card.

In this code:

  if (MMC_REPLY_ILLEGAL_COMMAND & reply) { // V1 cards do not understand CMD8
    disk->sd_version = 1;
    disk->sd_capacity = STANDARD_CAPACITY;
    mmc_spi_end_command(disk);
    return ENOERR;
  }

It enters as a V1 card. I don't have the Beagle attached yet. But this is the
difference from the working cards.

It then fails to enter the idle state.

I'll get the Beagle on it later.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #14 from Mike Jones <mjones@linear.com> ---
I took several micro cards and plugged them into the larger carrier and tested
on the K60 Tower, leaving the code to use response[3].

The SanDisk Ultra 8GB micro SDHC 1 does not respond to the init command 40 00
00 00 00 95.

The Samsung 4GB micro SDHC discussed earlier and having problems does not
respond to init command 40 00 00 00 00 95.

The SanDisk 2GB micro SD responds to the init command... and fails in this
code:

    if ( 1 == disk->sd_csd_version) {
      // There is information available about the file format, e.g.
      // partitioned vs. simple FAT. With the current version of the
      // generic disk code this needs to be known statically, via
      // the mbr field of the disk channel structure. If the card
      // is inappropriately formatted, reject the mount request.
      if ((0 != MMC_CSD_REGISTER_FILE_FORMAT_GROUP(&csd)) ||
          (0 != MMC_CSD_REGISTER_FILE_FORMAT(&csd))) {
          return -ENOTDIR;
      }
    } // Acco

Just like the SD 2GB mentioned in the last comment. Next steps will be to move
to my custom board with micro connector and test.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #13 from Mike Jones <mjones@linear.com> ---
I had new troubles with an SD Card so I spent some debug time.

My hardware is a standard K60 Tower with 2GB SD Card from SanDisk. The SPI is
rewired so the lines are connected properly.

The card cannot be recognized, on hardware that has worked before, with a card
that has worked before using this patch. The differences now are up to date
code base with FX patches, I2C, etc. Everything seems to work but this.

So I put my Beagle on the bus so I can see what is going on. So the details are
as follows.

- First, the clocking to clear the bus occurs.
- Second, there is an init command 40 00 00 00 95 which responds with an 01
- Third, there is a command to do a voltage check:
    48 00 00 01 AA 87

This means CMD8, voltage 01 (2.7V - 3.3V), test pattern AA

The card returns:

    01 00 00 01 AA FF

This means it echo's back the proper values. This is an R7 response.

In the spec https://www.sdcard.org/downloads/pls/simplified_specs/part1_410.pdf

On page 82 of the spec it describes this R7 response, and the 01 should be at
bit 16, pattern at bits 8:15 followed by crc and end bit.

Based on table 4-39 this seems malformed. I don't see the CMD8 at bits 40:45.
What is there is a 01. CRC also seems wrong unless FF is the real calculated
value. I have not tried to compute it.

The 01 and AA seem to be in the correct location.

Now in the code in mmc_spi.c:

  cyg_spi_transaction_transfer(dev, cyg_mmc_spi_polled,
      R7_RESPONSE_LENGTH, mmc_spi_ff_data, response, 0);
  DEBUG2("%s(): R7: %02x %02x %02x %02x %02x.\n", __FUNCTION__,
      response[0], response[1], response[2], response[3], response[4]);
  if (0 == (MMC_SPI_VHS & response[2])) {
    DEBUG1("%s(): card doesn't accept voltage %02x\n", __FUNCTION__,
MMC_SPI_VHS);
    mmc_spi_end_command(disk);
    return -ENOTSUP;
  }

It turns out the 01 is in response[3] and AA is in response[4]. If the transfer
with R7_RESPONSE_LENGTH does not include CRC, this positioning makes sense.
However, response[0] is 0. So it does not match the Beagle.

The code then returns an error because it is verifying the voltage with
response[2] rather than response[3].

So I then thought, well, let's change to response[3] and see if it works.

Now the code proceeds and sends command:

    77 00 00 00 00 00

This is 0x37 or CMD55, which is used because the code thinks this is a version
2 card. I have a SD card, so I think it is version 1, but I am new at this. The
code says it is V2 because it understands CMD8. So I guess it is V2.

Anyway, the code thinks the CMD55 App Command is ok and proceeds and sends
    69 40 00 00 00 FF

This is a 0x29 or CMD41, which is an initialization command. 40 means SDHC or
SDXC supported. However, this is an SD card. So perhaps the CMD8 should have
failed so that this would be a V1 card. Except, the CMD8 check for V1 occurs
before the voltage check and the code believes it worked.

  if (MMC_REPLY_ILLEGAL_COMMAND & reply) { // V1 cards do not understand CMD8
    disk->sd_version = 1;
    disk->sd_capacity = STANDARD_CAPACITY;
    mmc_spi_end_command(disk);
    return ENOERR;
  }

This code does not detect an illegal command. And the Beagle produced a reply.

Back to things, the code proceeds to:

    if ( 1 == disk->sd_csd_version) {
      // There is information available about the file format, e.g.
      // partitioned vs. simple FAT. With the current version of the
      // generic disk code this needs to be known statically, via
      // the mbr field of the disk channel structure. If the card
      // is inappropriately formatted, reject the mount request.
      if ((0 != MMC_CSD_REGISTER_FILE_FORMAT_GROUP(&csd)) ||
          (0 != MMC_CSD_REGISTER_FILE_FORMAT(&csd))) {
          return -ENOTDIR;
      }
    } // Accord

and we fail the mount request.

So I reformat the drive...

And the result is the same.

Now that I have a setup, perhaps I can take a look my working microSD stuff
which is on a custom board and look at a card that works and the failing
Samsung card, etc. I also have an SDHC card I can check on this Tower hardware.
All for now.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #12 from Mike Jones <mjones@linear.com> ---
Due to heavy load, I can't do much until first two weeks of May. I'll put this
on my priority list for early May. If there is some opportunity for free time,
I'll send what I can early.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEEDINFO
                 CC|                            |ilijak@siva.com.mk
     Ever confirmed|0                           |1

--- Comment #11 from Ilija Kocho <ilijak@siva.com.mk> ---
Mike

We need to figure-out where is the problem, The card or MMC driver or some of
SPI drivers. I tried to get Samsung SD card in several EU countries but failed.
Can you please do some tests for us?

Can you do post a screen capture of diagnostic output from minicom? (text
captyre preferable to screen).

Also if possible please try with different platforms: Kinetis, STM32, etc and
see if it makes difference.

Thanks
Ilija

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #10 from Mike Jones <mjones@linear.com> ---
I have verified that this patch did not harm with a 2GB and 8GB SanDisk. I
don't have time to debug the Samsung card now. If the cost is not too great, I
can ship a 4GB Samsung card to someone interested in debugging it. If someone
is willing to debug, e-mail me an address so I can check the shipping costs.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #9 from Mike Jones <mjones@linear.com> ---
I tried the patch but the behavior is exactly the same. I don't have other
cards with me, so I don't know if it impacted behavior of other cards.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #8 from Ilija Stanislevik <ilijas@siva.com.mk> ---
Created attachment 2132
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2132&action=edit
Patch in light of bug 1001676

This might be related to bug 1001676. This is a patch suggested by Ilija Kocho.
Mike, can you try your 4GB card with this patch on dspi driver?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #5 from Ilija Stanislevik <ilijas@siva.com.mk> ---
(In reply to comment #4)
I couldn't find this model, so I can't repeat your test. Tried with Transcend
brand 4GB class 4 SDHC and it works.

Mike, can you locate the point where the driver fails? Maybe you can present
some printout with DEBUG enabled.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #4 from Mike Jones <mjones@linear.com> ---
Samsung Model MB-MS4GB 
Class 4 Micro SDHC

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #3 from Ilija Stanislevik <ilijas@siva.com.mk> ---
(In reply to comment #2)
> Worked with Micro 2GB and 8GB. Did not work with Micro 4GB.
> 
> All the cards I tested were SanDisk except the Micro 4GB which was Samsung.

Mike,

I am trying to repeat your test with 4GB card. Can you give me the model name
of the one you have tried?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #2 from Mike Jones <mjones@linear.com> ---
Worked with Micro 2GB and 8GB. Did not work with Micro 4GB.

All the cards I tested were SanDisk except the Micro 4GB which was Samsung. I
tested two brand new Samsung 4GB and they both mount on Linux properly and were
formatted by the Linux Disk Manager like the other cards. All FAT32.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

Mike Jones <mjones@linear.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjones@linear.com

--- Comment #1 from Mike Jones <mjones@linear.com> ---
I tested this with SD 2GB, SD 4GB, SD 8GB using Tower K60. Works fine.

-- 
You are receiving this mail because:
You are on the CC list for the bug.