* [U-Boot] [PATCH] POST: Added ECC memory test for mpc83xx.
@ 2010-04-02 14:49 Michael Zaidman
2010-04-03 0:22 ` Timur Tabi
0 siblings, 1 reply; 23+ messages in thread
From: Michael Zaidman @ 2010-04-02 14:49 UTC (permalink / raw)
To: u-boot
---
post/cpu/mpc83xx/Makefile | 30 +++++++++
post/cpu/mpc83xx/ecc.c | 160 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 190 insertions(+), 0 deletions(-)
create mode 100644 post/cpu/mpc83xx/Makefile
create mode 100644 post/cpu/mpc83xx/ecc.c
diff --git a/post/cpu/mpc83xx/Makefile b/post/cpu/mpc83xx/Makefile
new file mode 100644
index 0000000..86d8784
--- /dev/null
+++ b/post/cpu/mpc83xx/Makefile
@@ -0,0 +1,30 @@
+#
+# (C) Copyright 2002-2007
+# Wolfgang Denk, DENX Software Engineering, wd at denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+include $(OBJTREE)/include/autoconf.mk
+
+LIB = libpostmpc83xx.a
+
+AOBJS-$(CONFIG_HAS_POST) +=
+COBJS-$(CONFIG_HAS_POST) += ecc.o
+
+include $(TOPDIR)/post/rules.mk
diff --git a/post/cpu/mpc83xx/ecc.c b/post/cpu/mpc83xx/ecc.c
new file mode 100644
index 0000000..83dfcf6
--- /dev/null
+++ b/post/cpu/mpc83xx/ecc.c
@@ -0,0 +1,160 @@
+/*
+ * (C) Copyright 2010
+ * Eastman Kodak Company, <www.kodak.com>
+ * Michael Zaidman, <michael.zaidman@kodak.com>
+ *
+ * The code is based on the cpu/mpc83xx/ecc.c written by
+ * Dave Liu <daveliu@freescale.com>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <common.h>
+#include <mpc83xx.h>
+#include <post.h>
+#include <watchdog.h>
+
+#if CONFIG_POST & CONFIG_SYS_POST_ECC
+
+inline static void ecc_clear(volatile ddr83xx_t *ddr)
+{
+ /* clear capture registers */
+ ddr->capture_address = 0;
+ ddr->capture_data_hi = 0;
+ ddr->capture_data_lo = 0;
+ ddr->capture_ecc = 0;
+ ddr->capture_attributes = 0;
+
+ /* Clear SBEC and set SBET to 1 */
+ ddr->err_sbe = (1 << ECC_ERROR_MAN_SBET_SHIFT);
+
+ /* Clear Error Detect register */
+ ddr->err_detect = (ECC_ERROR_DETECT_MME |
+ ECC_ERROR_DETECT_MBE |
+ ECC_ERROR_DETECT_SBE |
+ ECC_ERROR_DETECT_MSE);
+
+ __asm__ __volatile__("sync");
+ __asm__ __volatile__("isync");
+}
+
+int ecc_post_test(int flags)
+{
+ int ret = 0;
+ int int_state;
+ int errbit;
+ u32 pattern[2], writeback[2], retval[2];
+ volatile immap_t *immap = (immap_t *) CONFIG_SYS_IMMR;
+ volatile ddr83xx_t *ddr = &immap->ddr;
+ volatile u64 * addr = (u64 *)CONFIG_SYS_POST_ECC_START_ADDR;
+
+ /* The pattern is written into memory to generate error */
+ pattern[0] = 0xfedcba98UL;
+ pattern[1] = 0x76543210UL;
+
+ /* After injecting error, re-initialize the memory with the value */
+ writeback[0] = ~pattern[0];
+ writeback[1] = ~pattern[1];
+
+ /* Check if ECC is enabled */
+ if (ddr->err_disable & ECC_ERROR_ENABLE) {
+ debug("DDR's ECC is not enabled, skipping the ECC POST.\n");
+ return 0;
+ }
+
+ int_state = disable_interrupts();
+
+ icache_enable();
+
+#ifdef CONFIG_DDR_32BIT
+ /* It seems like no one really uses the CONFIG_DDR_32BIT mode */
+#error "Add the ECC POST support for CONFIG_DDR_32BIT here."
+#else
+ for (addr = (u64 *)CONFIG_SYS_POST_ECC_START_ADDR, errbit = 0;
+ addr < (u64 *)CONFIG_SYS_POST_ECC_STOP_ADDR; addr++, errbit++) {
+
+ WATCHDOG_RESET();
+
+ /* Test for correctable error by creating a one-bit error */
+ ecc_clear(ddr);
+
+ /* enable injects */
+ ddr->ecc_err_inject |= ECC_ERR_INJECT_EIEN;
+
+ /* Inject single bit error */
+ if (errbit < 32) {
+ ddr->data_err_inject_lo = 1 << errbit;
+ ddr->data_err_inject_hi = 0;
+ }
+ else {
+ ddr->data_err_inject_lo = 0;
+ ddr->data_err_inject_hi = 1 << (errbit-32);
+ }
+ __asm__ __volatile__("sync");
+ __asm__ __volatile__("isync");
+
+ /* write memory location injecting error */
+ ppcDWstore((u32*)addr, pattern);
+ __asm__ __volatile__("sync");
+
+ /* disable injects */
+ ddr->ecc_err_inject &= ~ECC_ERR_INJECT_EIEN;
+ __asm__ __volatile__("sync");
+ __asm__ __volatile__("isync");
+
+ /* read data, this generates ECC error */
+ ppcDWload((u32*)addr, retval);
+ __asm__ __volatile__("sync");
+
+ if (!(ddr->err_detect & ECC_ERROR_DETECT_SBE) ||
+ ((pattern[0] ^ ddr->capture_data_hi) !=
+ ddr->data_err_inject_hi) ||
+ ((pattern[1] ^ ddr->capture_data_lo) !=
+ ddr->data_err_inject_lo)) {
+
+ post_log("ECC failed to detect SBE error at %08x, "
+ "SBE injection mask %08x-%08x, "
+ "wrote %08x-%08x, read %08x-%08x\n", addr,
+ ddr->data_err_inject_hi, ddr->data_err_inject_lo,
+ pattern[0], pattern[1], retval[0], retval[1]);
+ debug("ERR_DETECT Reg: %08x\n", ddr->err_detect);
+ debug("ECC CAPTURE_DATA Reg: %08x-%08x\n",
+ ddr->capture_data_hi, ddr->capture_data_lo);
+ ret = 1;
+ break;
+ }
+
+ /* re-initialize the ECC memory */
+ ppcDWstore((u32*)addr, writeback);
+ __asm__ __volatile__("sync");
+
+ errbit %= 63;
+ }
+#endif /* !CONFIG_DDR_32BIT */
+
+ ecc_clear(ddr);
+
+ icache_disable();
+
+ if (int_state)
+ enable_interrupts();
+
+ return ret;
+}
+#endif
--
1.6.3.3
^ permalink raw reply related [flat|nested] 23+ messages in thread* [U-Boot] [PATCH] POST: Added ECC memory test for mpc83xx.
2010-04-02 14:49 [U-Boot] [PATCH] POST: Added ECC memory test for mpc83xx Michael Zaidman
@ 2010-04-03 0:22 ` Timur Tabi
2010-04-06 9:28 ` Michael Zaidman
0 siblings, 1 reply; 23+ messages in thread
From: Timur Tabi @ 2010-04-03 0:22 UTC (permalink / raw)
To: u-boot
On Fri, Apr 2, 2010 at 8:49 AM, Michael Zaidman
<michael.zaidman@gmail.com> wrote:
> +inline static void ecc_clear(volatile ddr83xx_t *ddr)
Please use I/O accessors instead of "volatile".
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply [flat|nested] 23+ messages in thread
* [U-Boot] [PATCH] POST: Added ECC memory test for mpc83xx.
2010-04-03 0:22 ` Timur Tabi
@ 2010-04-06 9:28 ` Michael Zaidman
2010-04-06 14:40 ` Timur Tabi
0 siblings, 1 reply; 23+ messages in thread
From: Michael Zaidman @ 2010-04-06 9:28 UTC (permalink / raw)
To: u-boot
On Sat, Apr 3, 2010 at 3:22 AM, Timur Tabi <timur.tabi@gmail.com> wrote:
> On Fri, Apr 2, 2010 at 8:49 AM, Michael Zaidman
> <michael.zaidman@gmail.com> wrote:
>
>> +inline static void ecc_clear(volatile ddr83xx_t *ddr)
>
> Please use I/O accessors instead of "volatile".
>
> --
> Timur Tabi
> Linux kernel developer at Freescale
>
I do not question the rationale behind the requirement to use the I/O
accessors. My question is - if there are any exceptions to the rule?
Just for curiosity I compared the assembly code generated by both
versions of ecc_clear routine - original and using I/O accessors. The
original is of 0x3C size while "accessors" version has 0x74 size.
Rewriting code to use accessors API added 56 bytes or 14 opcodes. It
doubled the routine's execution time. The routine is called in the
loop per each ecc word, that significantly increased execution time of
the ECC POST test and consequently board startup time.
-michael
^ permalink raw reply [flat|nested] 23+ messages in thread
* [U-Boot] [PATCH] POST: Added ECC memory test for mpc83xx.
2010-04-06 9:28 ` Michael Zaidman
@ 2010-04-06 14:40 ` Timur Tabi
2010-04-06 15:29 ` Michael Zaidman
0 siblings, 1 reply; 23+ messages in thread
From: Timur Tabi @ 2010-04-06 14:40 UTC (permalink / raw)
To: u-boot
On Tue, Apr 6, 2010 at 4:28 AM, Michael Zaidman
<michael.zaidman@gmail.com> wrote:
> I do not question the rationale behind the requirement to use the I/O
> accessors. My question is - if there are any exceptions to the rule?
Not really. The problem is that volatile does not take the PowerPC
execution ordering into account. So even if you use volatile, the
read write might not actually be performed when you think it should be
performed.
> Just for curiosity I compared the assembly code generated by both
> versions of ecc_clear routine ?- original and using I/O accessors. The
> original is of 0x3C size while "accessors" version has 0x74 size.
That's not surprising. The I/O accessors are not very efficient,
since they sync after ever write.
> Rewriting code to use accessors API added 56 bytes or 14 opcodes. It
> doubled the routine's execution time. The routine is called in the
> loop per each ecc word, that significantly increased execution time of
> the ECC POST test and consequently board startup time.
If this is really a problem, you can modify the code to perform the
writes without the I/O accessors, and then terminate the block with a
sync. You should add a comment explaining why you're not using I/O
accessors. At this point, I'm not 100% clear whether the use of
volatile is okay.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply [flat|nested] 23+ messages in thread
* [U-Boot] [PATCH] POST: Added ECC memory test for mpc83xx.
2010-04-06 14:40 ` Timur Tabi
@ 2010-04-06 15:29 ` Michael Zaidman
2010-04-06 15:45 ` Timur Tabi
2010-04-07 0:40 ` Kim Phillips
0 siblings, 2 replies; 23+ messages in thread
From: Michael Zaidman @ 2010-04-06 15:29 UTC (permalink / raw)
To: u-boot
>> Rewriting code to use accessors API added 56 bytes or 14 opcodes. It
>> doubled the routine's execution time. The routine is called in the
>> loop per each ecc word, that significantly increased execution time of
>> the ECC POST test and consequently board startup time.
>
> If this is really a problem, you can modify the code to perform the
> writes without the I/O accessors, and then terminate the block with a
> sync.
I thought that is what I actually do in this patch...
> You should add a comment explaining why you're not using I/O
> accessors.
Ok, I will add the explanation.
Thanks for your comments.
-michael
^ permalink raw reply [flat|nested] 23+ messages in thread
* [U-Boot] [PATCH] POST: Added ECC memory test for mpc83xx.
2010-04-06 15:29 ` Michael Zaidman
@ 2010-04-06 15:45 ` Timur Tabi
2010-04-07 0:40 ` Kim Phillips
1 sibling, 0 replies; 23+ messages in thread
From: Timur Tabi @ 2010-04-06 15:45 UTC (permalink / raw)
To: u-boot
On Tue, Apr 6, 2010 at 10:29 AM, Michael Zaidman
<michael.zaidman@gmail.com> wrote:
> I thought that is what I actually do in this patch...
Not quite. You're missing the memory barrier that the sync() function
includes. You're doing this:
__asm__ __volatile__("sync");
But the sync() macros does this:
static inline void sync(void)
{
__asm__ __volatile__ ("sync" : : : "memory");
}
The "memory" tells the compiler that this function is a memory
barrier, which means it won't try to reorder any reads/writes *after*
the "sync".
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply [flat|nested] 23+ messages in thread* [U-Boot] [PATCH] POST: Added ECC memory test for mpc83xx.
2010-04-06 15:29 ` Michael Zaidman
2010-04-06 15:45 ` Timur Tabi
@ 2010-04-07 0:40 ` Kim Phillips
2010-04-07 14:30 ` Timur Tabi
2010-04-07 14:47 ` Michael Zaidman
1 sibling, 2 replies; 23+ messages in thread
From: Kim Phillips @ 2010-04-07 0:40 UTC (permalink / raw)
To: u-boot
On Tue, 6 Apr 2010 18:29:08 +0300
Michael Zaidman <michael.zaidman@gmail.com> wrote:
> >> Rewriting code to use accessors API added 56 bytes or 14 opcodes. It
> >> doubled the routine's execution time. The routine is called in the
> >> loop per each ecc word, that significantly increased execution time of
> >> the ECC POST test and consequently board startup time.
> >
> > If this is really a problem, you can modify the code to perform the
> > writes without the I/O accessors, and then terminate the block with a
> > sync.
>
> I thought that is what I actually do in this patch...
>
> > You should add a comment explaining why you're not using I/O
> > accessors.
>
> Ok, I will add the explanation.
use raw i/o accessors please.
oh, and don't forget to sign off your work
Thanks,
Kim
^ permalink raw reply [flat|nested] 23+ messages in thread
* [U-Boot] [PATCH] POST: Added ECC memory test for mpc83xx.
2010-04-07 0:40 ` Kim Phillips
@ 2010-04-07 14:30 ` Timur Tabi
2010-04-07 16:25 ` Scott Wood
2010-04-07 14:47 ` Michael Zaidman
1 sibling, 1 reply; 23+ messages in thread
From: Timur Tabi @ 2010-04-07 14:30 UTC (permalink / raw)
To: u-boot
On Tue, Apr 6, 2010 at 7:40 PM, Kim Phillips <kim.phillips@freescale.com> wrote:
>> > You should add a comment explaining why you're not using I/O
>> > accessors.
>>
>> Ok, I will add the explanation.
>
> use raw i/o accessors please.
But what about his performance concern? Shouldn't it be okay for him
to do direct writes and then follow-up with a sync(), as long as he
comments it?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply [flat|nested] 23+ messages in thread
* [U-Boot] [PATCH] POST: Added ECC memory test for mpc83xx.
2010-04-07 14:30 ` Timur Tabi
@ 2010-04-07 16:25 ` Scott Wood
0 siblings, 0 replies; 23+ messages in thread
From: Scott Wood @ 2010-04-07 16:25 UTC (permalink / raw)
To: u-boot
On Wed, Apr 07, 2010 at 09:30:55AM -0500, Timur Tabi wrote:
> On Tue, Apr 6, 2010 at 7:40 PM, Kim Phillips <kim.phillips@freescale.com> wrote:
>
> >> > You should add a comment explaining why you're not using I/O
> >> > accessors.
> >>
> >> Ok, I will add the explanation.
> >
> > use raw i/o accessors please.
>
> But what about his performance concern? Shouldn't it be okay for him
> to do direct writes and then follow-up with a sync(), as long as he
> comments it?
That's exactly what raw accessors are for. They don't include
synchronization (and unfortunately this somehow gets tied up in whether
endian conversions are done).
-Scott
^ permalink raw reply [flat|nested] 23+ messages in thread
* [U-Boot] [PATCH] POST: Added ECC memory test for mpc83xx.
2010-04-07 0:40 ` Kim Phillips
2010-04-07 14:30 ` Timur Tabi
@ 2010-04-07 14:47 ` Michael Zaidman
2010-04-07 15:10 ` Timur Tabi
1 sibling, 1 reply; 23+ messages in thread
From: Michael Zaidman @ 2010-04-07 14:47 UTC (permalink / raw)
To: u-boot
On Wed, Apr 7, 2010 at 3:40 AM, Kim Phillips <kim.phillips@freescale.com> wrote:
> On Tue, 6 Apr 2010 18:29:08 +0300
> Michael Zaidman <michael.zaidman@gmail.com> wrote:
>
>> >> Rewriting code to use accessors API added 56 bytes or 14 opcodes. It
>> >> doubled the routine's execution time. The routine is called in the
>> >> loop per each ecc word, that significantly increased execution time of
>> >> the ECC POST test and consequently board startup time.
>> >
>> > If this is really a problem, you can modify the code to perform the
>> > writes without the I/O accessors, and then terminate the block with a
>> > sync.
>>
>> I thought that is what I actually do in this patch...
>>
>> > You should add a comment explaining why you're not using I/O
>> > accessors.
>>
>> Ok, I will add the explanation.
>
> use raw i/o accessors please.
>
> oh, and don't forget to sign off your work
>
> Thanks,
>
> Kim
>
Thanks for your feedback.
The version #2 of the patch is located here
http://lists.denx.de/pipermail/u-boot/2010-April/069579.html
-michael
^ permalink raw reply [flat|nested] 23+ messages in thread
* [U-Boot] [PATCH] POST: Added ECC memory test for mpc83xx.
2010-04-07 14:47 ` Michael Zaidman
@ 2010-04-07 15:10 ` Timur Tabi
2010-04-07 15:17 ` Michael Zaidman
0 siblings, 1 reply; 23+ messages in thread
From: Timur Tabi @ 2010-04-07 15:10 UTC (permalink / raw)
To: u-boot
On Wed, Apr 7, 2010 at 9:47 AM, Michael Zaidman
<michael.zaidman@gmail.com> wrote:
> The version #2 of the patch is located here
> http://lists.denx.de/pipermail/u-boot/2010-April/069579.html
What is ppcDWstore(), and why do you use it sometimes instead of
__raw_writel()? I see the code for ppcDWstore:
.globl ppcDWstore
ppcDWstore:
lfd 1, 0(r4)
stfd 1, 0(r3)
blr
I just don't understand why it exists.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply [flat|nested] 23+ messages in thread
* [U-Boot] [PATCH] POST: Added ECC memory test for mpc83xx.
2010-04-07 15:10 ` Timur Tabi
@ 2010-04-07 15:17 ` Michael Zaidman
2010-04-07 15:19 ` Timur Tabi
2010-04-07 16:01 ` Joakim Tjernlund
0 siblings, 2 replies; 23+ messages in thread
From: Michael Zaidman @ 2010-04-07 15:17 UTC (permalink / raw)
To: u-boot
On Wed, Apr 7, 2010 at 6:10 PM, Timur Tabi <timur.tabi@gmail.com> wrote:
> On Wed, Apr 7, 2010 at 9:47 AM, Michael Zaidman
> <michael.zaidman@gmail.com> wrote:
>
>> The version #2 of the patch is located here
>> http://lists.denx.de/pipermail/u-boot/2010-April/069579.html
>
> What is ppcDWstore(), and why do you use it sometimes instead of
> __raw_writel()? ?I see the code for ppcDWstore:
>
> ? ? ? ?.globl ?ppcDWstore
> ppcDWstore:
> ? ? ? ?lfd ? ? 1, 0(r4)
> ? ? ? ?stfd ? ?1, 0(r3)
> ? ? ? ?blr
>
> I just don't understand why it exists.
>
This is the fastest way to copy 64 bit words.
-michael
^ permalink raw reply [flat|nested] 23+ messages in thread
* [U-Boot] [PATCH] POST: Added ECC memory test for mpc83xx.
2010-04-07 15:17 ` Michael Zaidman
@ 2010-04-07 15:19 ` Timur Tabi
2010-04-07 16:01 ` Joakim Tjernlund
1 sibling, 0 replies; 23+ messages in thread
From: Timur Tabi @ 2010-04-07 15:19 UTC (permalink / raw)
To: u-boot
On Wed, Apr 7, 2010 at 10:17 AM, Michael Zaidman
<michael.zaidman@gmail.com> wrote:
> This is the fastest way to copy 64 bit words.
Of course, DW==double word. I should drink more coffee.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply [flat|nested] 23+ messages in thread
* [U-Boot] [PATCH] POST: Added ECC memory test for mpc83xx.
2010-04-07 15:17 ` Michael Zaidman
2010-04-07 15:19 ` Timur Tabi
@ 2010-04-07 16:01 ` Joakim Tjernlund
2010-04-08 6:49 ` Michael Zaidman
1 sibling, 1 reply; 23+ messages in thread
From: Joakim Tjernlund @ 2010-04-07 16:01 UTC (permalink / raw)
To: u-boot
>
> On Wed, Apr 7, 2010 at 6:10 PM, Timur Tabi <timur.tabi@gmail.com> wrote:
> > On Wed, Apr 7, 2010 at 9:47 AM, Michael Zaidman
> > <michael.zaidman@gmail.com> wrote:
> >
> >> The version #2 of the patch is located here
> >> http://lists.denx.de/pipermail/u-boot/2010-April/069579.html
> >
> > What is ppcDWstore(), and why do you use it sometimes instead of
> > __raw_writel()? ?I see the code for ppcDWstore:
> >
> > ? ? ? ?.globl ?ppcDWstore
> > ppcDWstore:
> > ? ? ? ?lfd ? ? 1, 0(r4)
> > ? ? ? ?stfd ? ?1, 0(r3)
> > ? ? ? ?blr
> >
> > I just don't understand why it exists.
> >
>
> This is the fastest way to copy 64 bit words.
hmm, not all boards have a FPU(8xx and 832x). How are lfd and stfd handled
there?
Jocke
^ permalink raw reply [flat|nested] 23+ messages in thread
* [U-Boot] [PATCH] POST: Added ECC memory test for mpc83xx.
2010-04-07 16:01 ` Joakim Tjernlund
@ 2010-04-08 6:49 ` Michael Zaidman
2010-04-08 8:27 ` Kim Phillips
0 siblings, 1 reply; 23+ messages in thread
From: Michael Zaidman @ 2010-04-08 6:49 UTC (permalink / raw)
To: u-boot
On Wed, Apr 7, 2010 at 7:01 PM, Joakim Tjernlund
<joakim.tjernlund@transmode.se> wrote:
>>
>> On Wed, Apr 7, 2010 at 6:10 PM, Timur Tabi <timur.tabi@gmail.com> wrote:
>> > On Wed, Apr 7, 2010 at 9:47 AM, Michael Zaidman
>> > <michael.zaidman@gmail.com> wrote:
>> >
>> >> The version #2 of the patch is located here
>> >> http://lists.denx.de/pipermail/u-boot/2010-April/069579.html
>> >
>> > What is ppcDWstore(), and why do you use it sometimes instead of
>> > __raw_writel()? ?I see the code for ppcDWstore:
>> >
>> > ? ? ? ?.globl ?ppcDWstore
>> > ppcDWstore:
>> > ? ? ? ?lfd ? ? 1, 0(r4)
>> > ? ? ? ?stfd ? ?1, 0(r3)
>> > ? ? ? ?blr
>> >
>> > I just don't understand why it exists.
>> >
>>
>> This is the fastest way to copy 64 bit words.
>
> hmm, not all boards have a FPU(8xx and 832x). How are lfd and stfd handled
> there?
>
> ?Jocke
>
The ppcDWstore/ ppcDWload code is mpc83xx specific, so the mpc8xx is
not relevant here. The e300c1 and e300c3 have FPU while e300c2 has
not. The lfd/stfd instructions load/store data from/to memory to/from
FPRs. It looks like these instructions are performed by Load/Store
Unit and rather require FPRs presence than FPU. The block diagram of
the e300c2 core in the e300coreRM (Rev3, 12/2006) specifies FPR File
and its connection to the Load/Store Unit. On other hand the
"1.3.1.1.2 Floating-Point Registers (FPRs)" chapter says that FPRs are
not included in the e300c2 core. Can someone clarify this?
Thanks,
Michael
^ permalink raw reply [flat|nested] 23+ messages in thread
* [U-Boot] [PATCH] POST: Added ECC memory test for mpc83xx.
2010-04-08 6:49 ` Michael Zaidman
@ 2010-04-08 8:27 ` Kim Phillips
2010-04-08 8:37 ` Joakim Tjernlund
0 siblings, 1 reply; 23+ messages in thread
From: Kim Phillips @ 2010-04-08 8:27 UTC (permalink / raw)
To: u-boot
On Thu, 8 Apr 2010 09:49:08 +0300
Michael Zaidman <michael.zaidman@gmail.com> wrote:
> On Wed, Apr 7, 2010 at 7:01 PM, Joakim Tjernlund
> <joakim.tjernlund@transmode.se> wrote:
> >>
> >> On Wed, Apr 7, 2010 at 6:10 PM, Timur Tabi <timur.tabi@gmail.com> wrote:
> >> > On Wed, Apr 7, 2010 at 9:47 AM, Michael Zaidman
> >> > <michael.zaidman@gmail.com> wrote:
> >> >
> >> >> The version #2 of the patch is located here
> >> >> http://lists.denx.de/pipermail/u-boot/2010-April/069579.html
> >> >
> >> > What is ppcDWstore(), and why do you use it sometimes instead of
> >> > __raw_writel()? ?I see the code for ppcDWstore:
> >> >
> >> > ? ? ? ?.globl ?ppcDWstore
> >> > ppcDWstore:
> >> > ? ? ? ?lfd ? ? 1, 0(r4)
> >> > ? ? ? ?stfd ? ?1, 0(r3)
> >> > ? ? ? ?blr
> >> >
> >> > I just don't understand why it exists.
> >> >
> >>
> >> This is the fastest way to copy 64 bit words.
> >
> > hmm, not all boards have a FPU(8xx and 832x). How are lfd and stfd handled
> > there?
> >
> > ?Jocke
> >
> The ppcDWstore/ ppcDWload code is mpc83xx specific, so the mpc8xx is
> not relevant here. The e300c1 and e300c3 have FPU while e300c2 has
right (which also suggests it's badly named (at least since the advent
of the e300c2)).
> not. The lfd/stfd instructions load/store data from/to memory to/from
> FPRs. It looks like these instructions are performed by Load/Store
> Unit and rather require FPRs presence than FPU. The block diagram of
> the e300c2 core in the e300coreRM (Rev3, 12/2006) specifies FPR File
> and its connection to the Load/Store Unit. On other hand the
> "1.3.1.1.2 Floating-Point Registers (FPRs)" chapter says that FPRs are
> not included in the e300c2 core. Can someone clarify this?
The documentation is confusing: the e300c2 has its FPU chopped off -
the FP registers are simply not there.
this is a good catch by Jocke - it would be best if generic 83xx code
didn't depend on the ppcDW* accessors.
Kim
^ permalink raw reply [flat|nested] 23+ messages in thread
* [U-Boot] [PATCH] POST: Added ECC memory test for mpc83xx.
2010-04-08 8:27 ` Kim Phillips
@ 2010-04-08 8:37 ` Joakim Tjernlund
2010-04-15 22:25 ` Kim Phillips
0 siblings, 1 reply; 23+ messages in thread
From: Joakim Tjernlund @ 2010-04-08 8:37 UTC (permalink / raw)
To: u-boot
Kim Phillips <kim.phillips@freescale.com> wrote on 2010-04-08 10:27:03:
>
> On Thu, 8 Apr 2010 09:49:08 +0300
> Michael Zaidman <michael.zaidman@gmail.com> wrote:
>
> > On Wed, Apr 7, 2010 at 7:01 PM, Joakim Tjernlund
> > <joakim.tjernlund@transmode.se> wrote:
> > >>
> > >> On Wed, Apr 7, 2010 at 6:10 PM, Timur Tabi <timur.tabi@gmail.com> wrote:
> > >> > On Wed, Apr 7, 2010 at 9:47 AM, Michael Zaidman
> > >> > <michael.zaidman@gmail.com> wrote:
> > >> >
> > >> >> The version #2 of the patch is located here
> > >> >> http://lists.denx.de/pipermail/u-boot/2010-April/069579.html
> > >> >
> > >> > What is ppcDWstore(), and why do you use it sometimes instead of
> > >> > __raw_writel()? ?I see the code for ppcDWstore:
> > >> >
> > >> > ? ? ? ?.globl ?ppcDWstore
> > >> > ppcDWstore:
> > >> > ? ? ? ?lfd ? ? 1, 0(r4)
> > >> > ? ? ? ?stfd ? ?1, 0(r3)
> > >> > ? ? ? ?blr
> > >> >
> > >> > I just don't understand why it exists.
> > >> >
> > >>
> > >> This is the fastest way to copy 64 bit words.
> > >
> > > hmm, not all boards have a FPU(8xx and 832x). How are lfd and stfd handled
> > > there?
> > >
> > > ?Jocke
> > >
> > The ppcDWstore/ ppcDWload code is mpc83xx specific, so the mpc8xx is
> > not relevant here. The e300c1 and e300c3 have FPU while e300c2 has
>
> right (which also suggests it's badly named (at least since the advent
> of the e300c2)).
>
> > not. The lfd/stfd instructions load/store data from/to memory to/from
> > FPRs. It looks like these instructions are performed by Load/Store
> > Unit and rather require FPRs presence than FPU. The block diagram of
> > the e300c2 core in the e300coreRM (Rev3, 12/2006) specifies FPR File
> > and its connection to the Load/Store Unit. On other hand the
> > "1.3.1.1.2 Floating-Point Registers (FPRs)" chapter says that FPRs are
> > not included in the e300c2 core. Can someone clarify this?
>
> The documentation is confusing: the e300c2 has its FPU chopped off -
> the FP registers are simply not there.
>
> this is a good catch by Jocke - it would be best if generic 83xx code
> didn't depend on the ppcDW* accessors.
That or one could impl. ppcDW* using normal load/store insns for 832x.
Either way the ppcDW* should be inlined as the overhead for doing
function calls isn't something you want when looking for speed.
Jocke
^ permalink raw reply [flat|nested] 23+ messages in thread* [U-Boot] [PATCH] POST: Added ECC memory test for mpc83xx.
2010-04-08 8:37 ` Joakim Tjernlund
@ 2010-04-15 22:25 ` Kim Phillips
2010-04-16 16:44 ` Michael Zaidman
0 siblings, 1 reply; 23+ messages in thread
From: Kim Phillips @ 2010-04-15 22:25 UTC (permalink / raw)
To: u-boot
On Thu, 8 Apr 2010 10:37:08 +0200
Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> Kim Phillips <kim.phillips@freescale.com> wrote on 2010-04-08 10:27:03:
> >
> > The documentation is confusing: the e300c2 has its FPU chopped off -
> > the FP registers are simply not there.
> >
> > this is a good catch by Jocke - it would be best if generic 83xx code
> > didn't depend on the ppcDW* accessors.
>
> That or one could impl. ppcDW* using normal load/store insns for 832x.
> Either way the ppcDW* should be inlined as the overhead for doing
> function calls isn't something you want when looking for speed.
another good point, but it seems they were added primarily for code
density benefits. I think we can do something like this in the
meantime:
^ permalink raw reply [flat|nested] 23+ messages in thread
* [U-Boot] [PATCH] POST: Added ECC memory test for mpc83xx.
2010-04-15 22:25 ` Kim Phillips
@ 2010-04-16 16:44 ` Michael Zaidman
2010-04-17 9:07 ` Joakim Tjernlund
2010-04-20 19:52 ` Michael Zaidman
0 siblings, 2 replies; 23+ messages in thread
From: Michael Zaidman @ 2010-04-16 16:44 UTC (permalink / raw)
To: u-boot
On Fri, Apr 16, 2010 at 1:25 AM, Kim Phillips
<kim.phillips@freescale.com> wrote:
> On Thu, 8 Apr 2010 10:37:08 +0200
> Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
>
>> Kim Phillips <kim.phillips@freescale.com> wrote on 2010-04-08 10:27:03:
>> >
>> > The documentation is confusing: the e300c2 has its FPU chopped off -
>> > the FP registers are simply not there.
>> >
>> > this is a good catch by Jocke - it would be best if generic 83xx code
>> > didn't depend on the ppcDW* accessors.
>>
>> That or one could impl. ppcDW* using normal load/store insns for 832x.
>> Either way the ppcDW* should be inlined as the overhead for doing
>> function calls isn't something you want when looking for speed.
>
> another good point, but it seems they were added primarily for code
> density benefits. I think we can do something like this in the
> meantime:
>
> From 686d3bb7a732ec36beec169c4eaf4882382d3aa2 Mon Sep 17 00:00:00 2001
> From: Kim Phillips <kim.phillips@freescale.com>
> Date: Thu, 8 Apr 2010 18:22:13 -0500
> Subject: [PATCH] mpc83xx: implement ppcDW{load,store} accessors for e300c2
>
> e300c2 core based processors (MPC832x) don't have an FPU: provide
> alternative, gpr based accessor functions for code compatibility.
>
> Suggested-by: Joakim Tjernlund <joakim.tjernlund@transmode.se>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> ---
> arch/ppc/cpu/mpc83xx/start.S | 14 ++++++++++++++
> 1 files changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/arch/ppc/cpu/mpc83xx/start.S b/arch/ppc/cpu/mpc83xx/start.S
> index 68bb620..6bfce57 100644
> --- a/arch/ppc/cpu/mpc83xx/start.S
> +++ b/arch/ppc/cpu/mpc83xx/start.S
> @@ -139,14 +139,28 @@ get_pvr:
>
> .globl ppcDWstore
> ppcDWstore:
> +#if !defined(CONFIG_MPC832x)
> lfd 1, 0(r4)
> stfd 1, 0(r3)
> +#else
> + lwz r5, 0(r4)
> + stw r5, 0(r3)
> + lwz r5, 4(r4)
> + stw r5, 4(r3)
> +#endif
> blr
>
> .globl ppcDWload
> ppcDWload:
> +#if !defined(CONFIG_MPC832x)
> lfd 1, 0(r3)
> stfd 1, 0(r4)
> +#else
> + lwz r5, 0(r3)
> + stw r5, 0(r4)
> + lwz r5, 4(r3)
> + stw r5, 4(r4)
> +#endif
> blr
>
> #ifndef CONFIG_DEFAULT_IMMR
> --
> 1.7.0.5
>
Although this is good for most of the cases it does not fit in the
algorithm implemented in the post_ecc_test. The first stw in
ppcDWstore will generate ecc error (due to read-modify-write) so ecc
capture data registers will capture only first word as it was written
with flipped injected error bit or without depending on its position
in the data_error_inject_hi or data_error_inject_lo injection mask
registers. The second ecc capture data word will hold the data that
was in the memory right before the ppcDWstore call. Thus, the test
validation while working for stfd will fail for stw x 2. So, the
algorithm need to be reworked...
I also agree with Joakim regarding the routine call overhead and
replacing it by inline macro. Please review this code.
^ permalink raw reply [flat|nested] 23+ messages in thread* [U-Boot] [PATCH] POST: Added ECC memory test for mpc83xx.
2010-04-16 16:44 ` Michael Zaidman
@ 2010-04-17 9:07 ` Joakim Tjernlund
2010-04-17 9:20 ` Joakim Tjernlund
2010-04-20 19:52 ` Michael Zaidman
1 sibling, 1 reply; 23+ messages in thread
From: Joakim Tjernlund @ 2010-04-17 9:07 UTC (permalink / raw)
To: u-boot
Michael Zaidman <michael.zaidman@gmail.com> wrote on 2010/04/16 18:44:12:
>
> On Fri, Apr 16, 2010 at 1:25 AM, Kim Phillips
> <kim.phillips@freescale.com> wrote:
> > On Thu, 8 Apr 2010 10:37:08 +0200
> > Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> >
> >> Kim Phillips <kim.phillips@freescale.com> wrote on 2010-04-08 10:27:03:
> Although this is good for most of the cases it does not fit in the
> algorithm implemented in the post_ecc_test. The first stw in
> ppcDWstore will generate ecc error (due to read-modify-write) so ecc
> capture data registers will capture only first word as it was written
> with flipped injected error bit or without depending on its position
> in the data_error_inject_hi or data_error_inject_lo injection mask
> registers. The second ecc capture data word will hold the data that
> was in the memory right before the ppcDWstore call. Thus, the test
> validation while working for stfd will fail for stw x 2. So, the
> algorithm need to be reworked...
>
> I also agree with Joakim regarding the routine call overhead and
> replacing it by inline macro. Please review this code.
>
> From 5a64a5c4f480dcea89bc8f13f8464b96b888b73c Mon Sep 17 00:00:00 2001
> From: Michael Zaidman <michael.zaidman@gmail.com>
> Date: Fri, 16 Apr 2010 18:50:43 +0300
> Subject: [U-Boot][PATCH] asm-ppc/io.h - added 64bits I/O accessors for ppc32.
>
> Suggested-by: Joakim Tjernlund <joakim.tjernlund@transmode.se>
> Signed-off-by: Michael Zaidman <michael.zaidman@gmail.com>
> ---
> include/asm-ppc/io.h | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 49 insertions(+), 0 deletions(-)
>
> diff --git a/include/asm-ppc/io.h b/include/asm-ppc/io.h
> index 4ddad26..0d5e125 100644
> --- a/include/asm-ppc/io.h
> +++ b/include/asm-ppc/io.h
> @@ -231,6 +231,31 @@ extern inline unsigned in_be32(const volatile
> unsigned __iomem *addr)
> return ret;
> }
>
> +/* 64 bits I/O read accessor for ppc32 */
> +extern inline void in_be64(volatile unsigned __iomem *addr, volatile
> unsigned __iomem *ret)
> +{
> +/* FIXME: Add other CPUs without FPU here... */
> +#if defined(CONFIG_MPC832x)
> + __asm__ __volatile__(
> + "sync\n"
> + "lwz%U0%X0 0,%0\n"
> + "stw%U1%X1 0,%1\n"
> + "lwz%U0%X0 0,4+%0\n"
> + "stw%U1%X1 0,4+%1\n"
> + "isync"
> + :"=m" (*ret)
> + :"m" (*addr), "r" (addr), "r" (ret));
To emulate FP better you should do 2 loads first and then 2 stores.
It is also faster.
^ permalink raw reply [flat|nested] 23+ messages in thread* [U-Boot] [PATCH] POST: Added ECC memory test for mpc83xx.
2010-04-17 9:07 ` Joakim Tjernlund
@ 2010-04-17 9:20 ` Joakim Tjernlund
2010-04-20 20:22 ` Michael Zaidman
0 siblings, 1 reply; 23+ messages in thread
From: Joakim Tjernlund @ 2010-04-17 9:20 UTC (permalink / raw)
To: u-boot
>
> Michael Zaidman <michael.zaidman@gmail.com> wrote on 2010/04/16 18:44:12:
> >
> > On Fri, Apr 16, 2010 at 1:25 AM, Kim Phillips
> > <kim.phillips@freescale.com> wrote:
> > > On Thu, 8 Apr 2010 10:37:08 +0200
> > > Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> > >
> > >> Kim Phillips <kim.phillips@freescale.com> wrote on 2010-04-08 10:27:03:
>
> > Although this is good for most of the cases it does not fit in the
> > algorithm implemented in the post_ecc_test. The first stw in
> > ppcDWstore will generate ecc error (due to read-modify-write) so ecc
> > capture data registers will capture only first word as it was written
> > with flipped injected error bit or without depending on its position
> > in the data_error_inject_hi or data_error_inject_lo injection mask
> > registers. The second ecc capture data word will hold the data that
> > was in the memory right before the ppcDWstore call. Thus, the test
> > validation while working for stfd will fail for stw x 2. So, the
> > algorithm need to be reworked...
> >
> > I also agree with Joakim regarding the routine call overhead and
> > replacing it by inline macro. Please review this code.
> >
> > From 5a64a5c4f480dcea89bc8f13f8464b96b888b73c Mon Sep 17 00:00:00 2001
> > From: Michael Zaidman <michael.zaidman@gmail.com>
> > Date: Fri, 16 Apr 2010 18:50:43 +0300
> > Subject: [U-Boot][PATCH] asm-ppc/io.h - added 64bits I/O accessors for ppc32.
> >
> > Suggested-by: Joakim Tjernlund <joakim.tjernlund@transmode.se>
> > Signed-off-by: Michael Zaidman <michael.zaidman@gmail.com>
> > ---
> > include/asm-ppc/io.h | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 files changed, 49 insertions(+), 0 deletions(-)
> >
> > diff --git a/include/asm-ppc/io.h b/include/asm-ppc/io.h
> > index 4ddad26..0d5e125 100644
> > --- a/include/asm-ppc/io.h
> > +++ b/include/asm-ppc/io.h
> > @@ -231,6 +231,31 @@ extern inline unsigned in_be32(const volatile
> > unsigned __iomem *addr)
> > return ret;
> > }
> >
> > +/* 64 bits I/O read accessor for ppc32 */
> > +extern inline void in_be64(volatile unsigned __iomem *addr, volatile
> > unsigned __iomem *ret)
> > +{
> > +/* FIXME: Add other CPUs without FPU here... */
> > +#if defined(CONFIG_MPC832x)
> > + __asm__ __volatile__(
> > + "sync\n"
> > + "lwz%U0%X0 0,%0\n"
> > + "stw%U1%X1 0,%1\n"
> > + "lwz%U0%X0 0,4+%0\n"
> > + "stw%U1%X1 0,4+%1\n"
> > + "isync"
> > + :"=m" (*ret)
> > + :"m" (*addr), "r" (addr), "r" (ret));
>
> To emulate FP better you should do 2 loads first and then 2 stores.
> It is also faster.
Forgot, you can add the MPC8xx CPU's too. These are also without FPU.
^ permalink raw reply [flat|nested] 23+ messages in thread* [U-Boot] [PATCH] POST: Added ECC memory test for mpc83xx.
2010-04-17 9:20 ` Joakim Tjernlund
@ 2010-04-20 20:22 ` Michael Zaidman
0 siblings, 0 replies; 23+ messages in thread
From: Michael Zaidman @ 2010-04-20 20:22 UTC (permalink / raw)
To: u-boot
On Sat, Apr 17, 2010 at 12:20 PM, Joakim Tjernlund
<joakim.tjernlund@transmode.se> wrote:
>>
>> Michael Zaidman <michael.zaidman@gmail.com> wrote on 2010/04/16 18:44:12:
>> >
>> > On Fri, Apr 16, 2010 at 1:25 AM, Kim Phillips
>> > <kim.phillips@freescale.com> wrote:
>> > > On Thu, 8 Apr 2010 10:37:08 +0200
>> > > Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
>> > >
>> > >> Kim Phillips <kim.phillips@freescale.com> wrote on 2010-04-08 10:27:03:
>> >
>> > I also agree with Joakim regarding the routine call overhead and
>> > replacing it by inline macro. Please review this code.
>> >
>> > From 5a64a5c4f480dcea89bc8f13f8464b96b888b73c Mon Sep 17 00:00:00 2001
>> > From: Michael Zaidman <michael.zaidman@gmail.com>
>> > Date: Fri, 16 Apr 2010 18:50:43 +0300
>> > Subject: [U-Boot][PATCH] asm-ppc/io.h - added 64bits I/O accessors for ppc32.
>> >
>> > Suggested-by: Joakim Tjernlund <joakim.tjernlund@transmode.se>
>> > Signed-off-by: Michael Zaidman <michael.zaidman@gmail.com>
>> > ---
>> > ?include/asm-ppc/io.h | ? 49 +++++++++++++++++++++++++++++++++++++++++++++++++
>> > ?1 files changed, 49 insertions(+), 0 deletions(-)
>> >
>> > diff --git a/include/asm-ppc/io.h b/include/asm-ppc/io.h
>> > index 4ddad26..0d5e125 100644
>> > --- a/include/asm-ppc/io.h
>> > +++ b/include/asm-ppc/io.h
>> > @@ -231,6 +231,31 @@ extern inline unsigned in_be32(const volatile
>> > unsigned __iomem *addr)
>> > ? ? return ret;
>> > ?}
>> >
>> > +/* 64 bits I/O read accessor for ppc32 */
>> > +extern inline void in_be64(volatile unsigned __iomem *addr, volatile
>> > unsigned __iomem *ret)
>> > +{
>> > +/* FIXME: Add other CPUs without FPU here... */
>> > +#if defined(CONFIG_MPC832x)
>> > + ? __asm__ __volatile__(
>> > + ? ? ? ? "sync\n"
>> > + ? ? ? ? "lwz%U0%X0 0,%0\n"
>> > + ? ? ? ? "stw%U1%X1 0,%1\n"
>> > + ? ? ? ? "lwz%U0%X0 0,4+%0\n"
>> > + ? ? ? ? "stw%U1%X1 0,4+%1\n"
>> > + ? ? ? ? "isync"
>> > + ? ? ? ? :"=m" (*ret)
>> > + ? ? ? ? :"m" ?(*addr), "r" (addr), "r" (ret));
>>
>> To emulate FP better you should do 2 loads first and then 2 stores.
>> It is also faster.
>
> Forgot, you can add the MPC8xx CPU's too. These are also without FPU.
>
>
Ok, thanks, the code below does this. I did not succeed however to
force the compiler to assign register for temporary storage and used
r5 explicitly.
/* 64 bits I/O read accessor for ppc32 */
extern inline void in_be64(volatile unsigned __iomem *addr, volatile
unsigned __iomem *ret)
{
/* FIXME: Add other CPUs without FPU here... */
#if defined(CONFIG_MPC832x) || defined(CONFIG_MPC8xx)
__asm__ __volatile__(
"sync\n"
"lwz%U0%X0 0,%0\n"
"lwz%U0%X0 5,4+%0\n"
"sync\n"
"stw%U1%X1 0,%1\n"
"stw%U1%X1 5,4+%1\n"
"isync"
:"=m" (*ret)
:"m" (*addr), "r" (addr), "r" (ret)
:"r0", "r5"
);
#else
__asm__ __volatile__(
"sync\n"
"lfd%U0%X0 1,%0\n"
"stfd%U1%X1 1,%1\n"
"isync"
:"=m" (*ret)
:"m" (*addr), "r" (addr), "r" (ret));
#endif
}
/* 64 bits I/O write accessor for ppc32 */
extern inline void out_be64(volatile unsigned __iomem *addr, volatile
unsigned __iomem *val)
{
/* FIXME: Add other CPUs without FPU here... */
#if defined(CONFIG_MPC832x) || defined(CONFIG_MPC8xx)
__asm__ __volatile__(
"sync\n"
"lwz%U0%X0 0,%0\n"
"lwz%U0%X0 5,4+%0\n"
"sync\n"
"stw%U1%X1 0,%1\n"
"stw%U1%X1 5,4+%1\n"
:"=m" (*addr)
:"m" (*val), "r" (addr), "r" (val)
:"r0", "r5"
);
#else
__asm__ __volatile__(
"sync\n"
"lfd%U1%X1 1,%1\n"
"stfd%U0%X0 1,%0"
:"=m" (*addr)
:"m" (*val), "r" (addr), "r" (val));
#endif
}
-michael
^ permalink raw reply [flat|nested] 23+ messages in thread
* [U-Boot] [PATCH] POST: Added ECC memory test for mpc83xx.
2010-04-16 16:44 ` Michael Zaidman
2010-04-17 9:07 ` Joakim Tjernlund
@ 2010-04-20 19:52 ` Michael Zaidman
1 sibling, 0 replies; 23+ messages in thread
From: Michael Zaidman @ 2010-04-20 19:52 UTC (permalink / raw)
To: u-boot
>> Michael, can you resubmit something more comprehensive, something that
>> builds for 83xx with CONFIG_POST turned on?
>>
> Sure.
>
Please see this patch:
http://lists.denx.de/pipermail/u-boot/2010-April/070319.html
-michael
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2010-04-20 20:22 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-04-02 14:49 [U-Boot] [PATCH] POST: Added ECC memory test for mpc83xx Michael Zaidman
2010-04-03 0:22 ` Timur Tabi
2010-04-06 9:28 ` Michael Zaidman
2010-04-06 14:40 ` Timur Tabi
2010-04-06 15:29 ` Michael Zaidman
2010-04-06 15:45 ` Timur Tabi
2010-04-07 0:40 ` Kim Phillips
2010-04-07 14:30 ` Timur Tabi
2010-04-07 16:25 ` Scott Wood
2010-04-07 14:47 ` Michael Zaidman
2010-04-07 15:10 ` Timur Tabi
2010-04-07 15:17 ` Michael Zaidman
2010-04-07 15:19 ` Timur Tabi
2010-04-07 16:01 ` Joakim Tjernlund
2010-04-08 6:49 ` Michael Zaidman
2010-04-08 8:27 ` Kim Phillips
2010-04-08 8:37 ` Joakim Tjernlund
2010-04-15 22:25 ` Kim Phillips
2010-04-16 16:44 ` Michael Zaidman
2010-04-17 9:07 ` Joakim Tjernlund
2010-04-17 9:20 ` Joakim Tjernlund
2010-04-20 20:22 ` Michael Zaidman
2010-04-20 19:52 ` Michael Zaidman
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.