From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HSWgY-0008Gm-Qk for qemu-devel@nongnu.org; Sat, 17 Mar 2007 07:02:54 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HSWgX-0008Ga-98 for qemu-devel@nongnu.org; Sat, 17 Mar 2007 07:02:54 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HSWgX-0008GX-3j for qemu-devel@nongnu.org; Sat, 17 Mar 2007 06:02:53 -0500 Received: from nf-out-0910.google.com ([64.233.182.191]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HSWfI-0000N2-Ma for qemu-devel@nongnu.org; Sat, 17 Mar 2007 07:01:37 -0400 Received: by nf-out-0910.google.com with SMTP id c31so998774nfb for ; Sat, 17 Mar 2007 04:01:32 -0700 (PDT) Message-ID: Date: Sat, 17 Mar 2007 12:01:31 +0100 From: "andrzej zaborowski" Sender: balrogg@gmail.com Subject: Re: [Qemu-devel] [PATCH] SecureDigital card emulation. In-Reply-To: <200703171029.19713.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200703171029.19713.paul@codesourcery.com> Reply-To: balrogg@gmail.com, qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel@nongnu.org Hi, On 17/03/07, Paul Brook wrote: > On Friday 16 March 2007 20:59, andrzej zaborowski wrote: > > Emulates an SD card with the full command set (no SPI mode though). > > Should be more or less compliant with version 1.10 specification. > > I suspect your code only works on x86. Specifically things like: > > > +struct sd_response_r1_s { > > + uint8_t cmd; > > + uint32_t status; > > + uint8_t crc; > > +}; > > Will be a 12-byte struct on many hosts, and probably also breaks on big-endian > hosts. AFAICS there's no way for the caller of sd_write_cmdline to figure out > what type of response is returned (other than the length), so has to rely on > doing a bitwise copy. The card is supposed to return the type of response matching the command that was issued, so the the caller does know the type and doesn't do bitwise copy. If the card is broken and returns a different response then we get garbage, exactly like on the actual hardware. Regards, Andrew