From: Peter Tyser <ptyser@xes-inc.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/5] 8xxx: Add 'ecc' command
Date: Sat, 24 Oct 2009 16:30:15 -0500 [thread overview]
Message-ID: <4AE371E7.3000209@xes-inc.com> (raw)
In-Reply-To: <20091024172110.D07EF185D4A5@gemini.denx.de>
Hi Wolfgang,
> In message <1256258353-25589-1-git-send-email-ptyser@xes-inc.com> you wrote:
>> Add a new 'ecc' command to interact with the 85xx and 86xx DDR ECC
>> registers. The 'ecc' command can inject data/ECC errors to simulate
>> errors and provides an 'info' subcommand which displays ECC error
>> information such as failure address, read vs expected data/ECC,
>> physical signal which failed, single-bit error count, and multiple bit
>> error occurrence. An example of the 'ecc info' command follows:
>
> We already have similar commands for other architectures, see for
> example cpu/mpc83xx/ecc.c
>
> I'm not sure if it's possible to use a common implementation, but I
> would like to ask you to check if this is possible.
83xx, 85xx, and 86xx could all share an implementation I believe. I
didn't integrate the 83xx in this patch because it seemed to have a
different "goal" than the patch I submitted. The 83xx implementation
supported a high degree of tweaking registers which I personally find
unnecessary for general use. I think that if someone wants that level
of control, they could just modify the registers directly since they
have to have the 83xx user's manual handy anyway.
The implementation I submitted has limited, common features and much
better error reporting. The error reporting is the feature that would
be used 98% of the time, not the tweaking of registers. I'd be happy to
include the 83xx implementation in this patch, but I'd vote to strip out
most of the current 83xx features - ie basically remove the 83xx ecc
code and replace it with the 85/86xx implementation I submitted. Would
83xx people be OK with this? Or have any suggestions on what the
combined implementation should look like?
> In any case I ask that we use a common user interface for both
> implementations. It makes no sense that the same command name behaves
> differently on different boards (even from the same vendor).
I see your point. As far as a common implementation, what did you have
in mind? Are you referring to only consolidating the 83xx/85xx/86xx
implementations? I'm fine with that, but don't think you could expand
the "common interface" much past them as ECC reporting/injection
features vary greatly from architecture to architecture.
Best,
Peter
next prev parent reply other threads:[~2009-10-24 21:30 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-23 0:39 [U-Boot] [PATCH 1/5] 8xxx: Add 'ecc' command Peter Tyser
2009-10-23 0:39 ` [U-Boot] [PATCH 2/5] Add check for ECC errors during SDRAM POST and mtest Peter Tyser
2009-10-23 0:39 ` [U-Boot] [PATCH 3/5] xes: Enable the 'ecc' command Peter Tyser
2009-11-23 22:35 ` Wolfgang Denk
2009-11-24 4:36 ` Peter Tyser
2009-10-23 0:39 ` [U-Boot] [PATCH 4/5] xes: Enable memory POST Peter Tyser
2009-10-23 0:39 ` [U-Boot] [PATCH 5/5] xes: Enable ECC error checks during SDRAM POST and mtest Peter Tyser
2009-10-24 15:41 ` [U-Boot] [PATCH 1/5] 8xxx: Add 'ecc' command Kumar Gala
2009-10-24 21:14 ` Peter Tyser
2009-10-24 17:21 ` Wolfgang Denk
2009-10-24 21:30 ` Peter Tyser [this message]
2009-10-24 21:37 ` Wolfgang Denk
2009-10-24 21:43 ` Peter Tyser
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=4AE371E7.3000209@xes-inc.com \
--to=ptyser@xes-inc.com \
--cc=u-boot@lists.denx.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.