LKML Archive on
help / color / mirror / Atom feed
From: Andreas Mohr <>
To: Pierre Ossman <>
Cc: Adam Wysocki <>,,
Subject: [semi-solved] Re: [sdhci] mmc0: unrecognised SCR structure version 1
Date: Thu, 7 Feb 2008 00:10:16 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>


On Sat, Sep 29, 2007 at 10:35:16AM +0200, Pierre Ossman wrote:
> On Sat, 29 Sep 2007 05:42:37 +0200 (CEST)
> Adam Wysocki <> wrote:
> > [CCd to possibly interested Pierre Ossman and Rodolfo Giometti]
> > 
> > Hi there,
> > 
> > First, sorry for my poor english - I am not a native.
> > 
> > I know there have been a thread about this problem few months ago,
> > but as far as I see it did not led to any results: 
> >
> > 
> > I have the same problem, as described there, with Kingston 2GB SD
> > card. My card reader is embedded into Fujitsu-Siemens AMILO Pro V3505
> > notebook and Linux sees it as:
> > 
> If it's just this card, then I would have to conclude that it is indeed
> broken. You'd have to return it to the store and get a new one.

My Toshiba SD-512-T card (Toshiba-specific specs are available as
TOSHIBA_SD_Card_Specification.pdf) shows the same "SCR structure version 1"
error message with 2.6.24 on a Motorola E680 (PXAMCI), whereas
on 2.6.21 it did _NOT_ have it (and all SCR values there are a 1:1 match
with the values listed in the spec .pdf!).

For me at least it turned out that while on 2.6.21, raw_scr had
0x00a50000 0x10011602
on 2.6.24 raw_scr had
0x10011602 0x00000000

IOW, the whole thing is simply shifted by one unsigned int, rendering any
SCR interpretation fatally wrong (which, I believe, could be a
_permanent_ error in the SD stack itself which randomly -
depending on the exact bit content of a card's SCR dump -
causes the SCR version check to trigger for various cards).
Is this unsigned int shifting due to a transfer setup issue in the
highlevel SD stack or do you think it is due to a setup issue in the
lower-level pxamci driver in my case? If so, what setting could have
distorted it?
Weak voltage settings are not to blame, I believe (removed some configs to
increase a bit from minimum supported voltage).
If you don't have any specific ideas yet, any hints on how to proceed
with tracking this down?

I'd advise at least adding dumping the raw_scr values
in the SCR version error to be able to track such error postings better
in the future.

I'm now giving up on tracking this down myself (I'll just bail the check for
now to have it boot properly) since originally I had more productive things
in mind ;)
(note that disabling the check on 2.6.24 makes the card boot ok
up to a full mobile desktop)


Andreas Mohr

  parent reply	other threads:[~2008-02-06 23:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-29  3:42 Adam Wysocki
2007-09-29  8:35 ` Pierre Ossman
2007-09-29 12:27   ` Adam Wysocki
2008-02-06 23:10   ` Andreas Mohr [this message]
2008-02-07 19:41     ` [semi-solved] " 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:

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

  git send-email \ \ \ \ \ \ \
    --subject='[semi-solved] Re: [sdhci] mmc0: unrecognised SCR structure version 1' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).