| To: | Ashish anand <ashish.anand@inspiretech.com> |
|---|---|
| Subject: | Re: low ram as source of good parity data..? |
| From: | Ralf Baechle <ralf@linux-mips.org> |
| Date: | Thu, 5 Jun 2003 13:27:22 +0200 |
| Cc: | linux-mips@linux-mips.org |
| In-reply-to: | <200306051027.h55ARnI9031919@smtp.inspirtek.com> |
| Original-recipient: | rfc822;linux-mips@linux-mips.org |
| References: | <200306051027.h55ARnI9031919@smtp.inspirtek.com> |
| Sender: | linux-mips-bounce@linux-mips.org |
| User-agent: | Mutt/1.4.1i |
On Thu, Jun 05, 2003 at 03:16:41PM +0530, Ashish anand wrote: > I have seen it a common practice to assume low RAM as source > of good parity data and use it to fill the caches with good parity > data in firmware during elementary hardware initialisation process. > > why it is always safe to assume that low RAM contains good parity data .? > Is it always true..? > this question came in picture after I got cacheparity error sometimes. For the general case it's not safe. Some systems need memory to be initialized by writing to it first because before the parity or ECC bits may have an undefined state. The safe way to initalize the caches is using the Index_Store_Tag_D etc. cacheops but of course that requires knowledge about the particular processor's exactly cache architecture. Ralf |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [RFC] synchronized CPU count registers on SMP machines, Maciej W. Rozycki |
|---|---|
| Next by Date: | Re: mips64 LOAD_KPTE2 fix, Maciej W. Rozycki |
| Previous by Thread: | low ram as source of good parity data..?, Ashish anand |
| Next by Thread: | 64bit gcc, David Kesselring |
| Indexes: | [Date] [Thread] [Top] [All Lists] |