From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7595 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: List-Subscribe: List-Post: List-Help: , Sender: ecos-bugs-owner@sourceware.org Received: (qmail 7579 invoked by uid 89); 18 Apr 2013 21:16:41 -0000 X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW 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: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 6FFA94680013 for ; Thu, 18 Apr 2013 22:16:38 +0100 (BST) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdlmfB-sanKX; Thu, 18 Apr 2013 22:16:36 +0100 (BST) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-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: CC 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: In-Reply-To: References: 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/msg00248.txt.bz2 Please do not reply to this email, use the link below. http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1001764 --- Comment #16 from Mike Jones --- 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 !=3D reply) { DEBUG1("%s(): loop %d, card did not enter idle state, code %02x= \n", __FUNCTION__, i, reply); if (0x0ff !=3D reply) { cyg_spi_transfer(dev, cyg_mmc_spi_polled, 128, mmc_spi_ff_d= ata, (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=20 B1 Erase Reset B2 Illegal Command=20 B3 Com CRC Error=20 B4 Erase Seq Error=20 B5 Address Error=20 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 !=3D (reply & 0x01)) { DEBUG1("%s(): loop %d, card did not enter idle state, code %02x= \n", __FUNCTION__, i, reply); if (0x0ff !=3D reply) { cyg_spi_transfer(dev, cyg_mmc_spi_polled, 128, mmc_spi_ff_d= ata, (cyg_uint8*) 0); } } I changed the top line and added "& 0x01" to ignore the other error bits. M= ade 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=20 Description Resource Path Location Type =E2=80=98CYGHWR_DEVS_FREESCALEDSPI_DSPI_CTAR1_AUX_USE_DBR=E2=80=99 undeclar= ed here (not in a function) Sidekick2-4 line 194, external location: /opt/ecos/ecos-3.0/packages/devs/spi/freescale/dspi/current/src/spi_freesca= le_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 Sams= ung 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 al= so verified with the Beagle that the bus ran slower. But did not verify this on the scope. --=20 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: 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: List-Subscribe: List-Post: List-Help: , 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: In-Reply-To: References: 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=3D1001764 --- Comment #16 from Mike Jones --- 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 !=3D reply) { DEBUG1("%s(): loop %d, card did not enter idle state, code %02x= \n", __FUNCTION__, i, reply); if (0x0ff !=3D reply) { cyg_spi_transfer(dev, cyg_mmc_spi_polled, 128, mmc_spi_ff_d= ata, (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=20 B1 Erase Reset B2 Illegal Command=20 B3 Com CRC Error=20 B4 Erase Seq Error=20 B5 Address Error=20 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 !=3D (reply & 0x01)) { DEBUG1("%s(): loop %d, card did not enter idle state, code %02x= \n", __FUNCTION__, i, reply); if (0x0ff !=3D reply) { cyg_spi_transfer(dev, cyg_mmc_spi_polled, 128, mmc_spi_ff_d= ata, (cyg_uint8*) 0); } } I changed the top line and added "& 0x01" to ignore the other error bits. M= ade 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=20 Description Resource Path Location Type =E2=80=98CYGHWR_DEVS_FREESCALEDSPI_DSPI_CTAR1_AUX_USE_DBR=E2=80=99 undeclar= ed here (not in a function) Sidekick2-4 line 194, external location: /opt/ecos/ecos-3.0/packages/devs/spi/freescale/dspi/current/src/spi_freesca= le_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 Sams= ung 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 al= so verified with the Beagle that the bus ran slower. But did not verify this on the scope. --=20 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: 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: List-Subscribe: List-Post: List-Help: , 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: In-Reply-To: References: 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=1001764 --- Comment #17 from Mike Jones --- 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.