public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pierre Ossman <drzeus-list@drzeus.cx>
To: unlisted-recipients:;;@mail-zipworld.pacific.net.au (no
	To-header on input)
Cc: Matt Reimer <mattjreimer@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: 2GB MMC/SD cards
Date: Tue, 06 Jun 2006 00:52:30 +0200	[thread overview]
Message-ID: <4484B5AE.8060404@drzeus.cx> (raw)
In-Reply-To: <4481FB80.40709@drzeus.cx>

Pierre Ossman wrote:
> Matt Reimer wrote:
>> I suspect that a lot of these readers are broken, assuming 512 byte
>> blocks.
>>
> 
> That's what I thought until I looked closer at the Sandisk specs. Until
> we can see what the official specs say, we won't really know what the
> correct behaviour is. The Nokia boys working on the 770 have a copy.
> Perhaps someone here knows how to get in touch with one of them that can
> have a look?
> 

With the help of Khasim Syed, who happens to have access to the MMC
spec, we now know what's in the spec. Unfortunately, what's in there is
the same text that's in Russell's card specs, which state that only
WRITE_BL_LEN is supported.

However! In the simplified SD physical spec (which you can find on the
SDA home page), we can find:

4.3.2 2GByte Card
To make 2GByte card, the Maximum Block Length (READ_BL_LEN=WRITE_BL_LEN)
shall be set to
1024 bytes. But Block Length set by CMD16 shall be up to 512 bytes to
keep consistency with 512
bytes Maximum Block Length cards (Less than and equal 2GByte cards).

It even has an example with WRITE_BL_PARTIAL=0, still setting block
length to 512. Now I know this is SD and not MMC, but the debug dump
from Serge earlier seems to suggest that MMC cards follow the same rule.

Even though this breaks the MMC spec, my vote is for 512 bytes at all
times. If the entire industry decided to violate the spec, I don't see
much gain in being stubborn here.

Rgds
Pierre


  parent reply	other threads:[~2006-06-05 22:52 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-29 14:00 2GB MMC/SD cards Pierre Ossman
2006-06-03 14:15 ` Russell King
2006-06-03 15:02   ` Russell King
2006-06-03 18:40   ` Matt Reimer
2006-06-03 21:13     ` Pierre Ossman
2006-06-05 22:29       ` Jordan Crouse
2006-06-06  7:17         ` Richard Purdie
2006-06-05 22:52       ` Pierre Ossman [this message]
2006-06-07  9:08         ` Pierre Ossman
2006-06-07 16:58           ` Russell King
2006-06-07 20:36             ` Pierre Ossman
2006-06-08 23:01               ` Pierre Ossman
2006-06-22 15:08                 ` Marcin Juszkiewicz
2006-08-13 10:14                 ` Daniel Drake
2006-08-22 15:19                   ` Juha Yrjola
2006-08-22 17:00                     ` Jeff Chua
2006-08-23 18:28                     ` Pierre Ossman
2006-08-25  9:07                     ` Russell King
2006-06-03 21:11   ` Pierre Ossman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4484B5AE.8060404@drzeus.cx \
    --to=drzeus-list@drzeus.cx \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mattjreimer@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox