linux-sh.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Magnus Damm <magnus.damm@gmail.com>
To: linux-sh@vger.kernel.org
Subject: Re: SDHI polling
Date: Mon, 27 Dec 2010 01:47:46 +0000	[thread overview]
Message-ID: <AANLkTikw99ydXBJ0hRoLLDAEpGLy_UgU23vLkNA0Kutm@mail.gmail.com> (raw)
In-Reply-To: <20101226224506.GD21535@verge.net.au>

On Mon, Dec 27, 2010 at 10:36 AM, Paul Mundt <lethal@linux-sh.org> wrote:
> On Mon, Dec 27, 2010 at 10:03:06AM +0900, Magnus Damm wrote:
>> On Mon, Dec 27, 2010 at 9:10 AM, Paul Mundt <lethal@linux-sh.org> wrote:
>> > In any event, just because the boot loader people are useless doesn't
>> > mean you can't set the bar a bit higher for yourself when designing new
>> > features.
>>
>> Sure, but I don't think that raising the bar by implementing interrupt
>> support is a good idea in this case. This since all you're doing is
>> loading a kernel image from a single device.
>>
> I agree that things should be kept as simple as possible, we basically
> want as few variables that can lead to failure as possible at that stage.
> If this can be accomplished without having to model some sort of an
> asynchronous state machine, then of course that's the most
> straightforward.
>
> The entire point after all is to get away from this sort of boot loader
> ineptitude, so we don't really want to recreate a boot loader within the
> image loading stubs as a replacement.

Exactly.

> I don't know enough about how SDHI works to have any strong opinions on
> the matter one way or the other, but one does need to keep in mind that
> cards will degrade over time and will need to have recoverable errors
> handled for any sort of real-world application, whether this is something
> we will invariably have to install an exception handler for or not I
> don't know. Ideally if there is some retry logic in the mask ROM then
> this all gets much simpler.

There is most likely some retry logic in the Mask ROM. At least the
MMCIF Mask ROM code does retry according to the docs I've seen.

On top of that we do probably need to make the MMCIF/SDHI loader code
more robust. I suspect that most errors can be dealt with by just
implementing correct error handing of status flag bits in each
"driver", ie MMCIF/SDHI loader code. If that's not enough then we may
have to checksum the image as well. I don't think any exceptions will
be raised.

Just loading the image as a first step would most likely put us on a
similar level as U-boot.

/ magnus

      parent reply	other threads:[~2010-12-27  1:47 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-26 22:45 SDHI polling Simon Horman
2010-12-26 22:59 ` Magnus Damm
2010-12-26 23:24 ` Paul Mundt
2010-12-26 23:34 ` Magnus Damm
2010-12-27  0:10 ` Paul Mundt
2010-12-27  0:23 ` Simon Horman
2010-12-27  0:57 ` Magnus Damm
2010-12-27  1:03 ` Magnus Damm
2010-12-27  1:13 ` Simon Horman
2010-12-27  1:36 ` Paul Mundt
2010-12-27  1:44 ` Simon Horman
2010-12-27  1:47 ` Magnus Damm [this message]

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=AANLkTikw99ydXBJ0hRoLLDAEpGLy_UgU23vLkNA0Kutm@mail.gmail.com \
    --to=magnus.damm@gmail.com \
    --cc=linux-sh@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).