From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 968 invoked by alias); 17 Apr 2013 17:43:44 -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 864 invoked by uid 89); 17 Apr 2013 17:43:43 -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; Wed, 17 Apr 2013 17:43:42 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 998354680001 for ; Wed, 17 Apr 2013 18:43:40 +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 tfJHMogDVe2j; Wed, 17 Apr 2013 18:43:40 +0100 (BST) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-bugs@ecos.sourceware.org Subject: [Bug 1001397] I2C driver for Kinetis microcontrollers Date: Wed, 17 Apr 2013 17:43:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: Patches and contributions X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: ilijak@siva.com.mk X-Bugzilla-Status: NEEDINFO X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: ilijak@siva.com.mk 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/msg00241.txt.bz2 Please do not reply to this email, use the link below. http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1001397 --- Comment #52 from Ilija Kocho --- Created attachment 2185 --> http://bugs.ecos.sourceware.org/attachment.cgi?id=3D2185&action=3Dedit Best fit aggressive clocking (incremantal). (In reply to comment #51) > I tested the patches at different frequencies using code like this: >=20 >=20 > cyg_i2c_device device =3D { \ > .i2c_bus =3D &cyg_i2c0_bus, \ > .i2c_address =3D 0x0C, \ > .i2c_flags =3D 0, \ > .i2c_delay =3D i2c_bus_time \ > }; >=20 > It works at 100/400Khz properly. The there is more error in the frequency > than some end users will want. It seems to run about 10% too slow. The frequency divider calculator is conservative, if exact frequency is not available, it will pick the previous (lower) frequency. Since there are more such combinations, in the CDL you can select up to which FIT to look, (takes more time). It will still be lower or equal, but may be closer. If it is permissible, here is a (non tested) incremental patch with somewhat aggress= ive approach, it will pick the closest frequency even if it overclocks. We can = give user a chance to (dis)allow aggressive clocking by means of CDL. Please advise. >=20 > In the CDL "SMB register options" is misspelled. register is missing an r. >=20 Thanks, I'll fix. > I don't have means at the moment to test SMB options. I suggest this is > tested after releasing this code. When the STM32 I2C is in a similar state > to this code, I can build hardware that supports built in ALERTB processi= ng > for both processors and test the SMB support. The current patches seem > adequate for I2C and work fine with my large application. I agree, then I would remove SMB CDL from current release since it may be misleading. >=20 > I would like to test default clock speed, meaning the frequency in the CD= L. > How do I write code that uses the default rather than .i2c_delay. Yes, I = am > being lazy and not digging into the code. I don't think that there's such option, I guess the idea is that every devi= ce on the bus has it's own clocking requirement. Frankly I don't know what is = it for. --=20 You are receiving this mail because: You are on the CC list for the bug. >>From ecos-bugs-return-10212-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Apr 18 17:33:46 2013 Return-Path: Delivered-To: listarch-ecos-bugs@sources.redhat.com Received: (qmail 17669 invoked by alias); 18 Apr 2013 17:33:46 -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 17657 invoked by uid 89); 18 Apr 2013 17:33:46 -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 17:33:44 +0000 Received: by mail.ecoscentric.com (Postfix, from userid 48) id 5AAD44680007; Thu, 18 Apr 2013 18:33:42 +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 17:33: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/msg00243.txt.bz2 Content-length: 4327 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 --- 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 the assignee for the bug.