From: Detlev Zundel <dzu@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v3] MPC5200: workaround data corruption for unaligned local bus accesses
Date: Fri, 25 Jun 2010 10:35:28 +0200 [thread overview]
Message-ID: <m2sk4bcxwv.fsf@ohwell.denx.de> (raw)
In-Reply-To: <1277251931-12994-1-git-send-email-wd@denx.de> (Wolfgang Denk's message of "Wed, 23 Jun 2010 02:12:11 +0200")
Hi Wolfgang,
Now that we keep the old speed on aligned access, I'm ok with the change
and only see one typo in the comment.
> The MPC5200 has a nasty problem that will cause silent data corruption
> when performing unaligned 16 or 32 byte accesses when reading from the
> local bus - typically this affects reading from flash. The problem can
> be easily shown:
>
> => md fc0c0000 10
> fc0c0000: 323e4337 01626f6f 74636d64 3d72756e 2>C7.bootcmd=run
> fc0c0010: 206e6574 5f6e6673 00626f6f 7464656c net_nfs.bootdel
> fc0c0020: 61793d35 00626175 64726174 653d3131 ay=5.baudrate=11
> fc0c0030: 35323030 00707265 626f6f74 3d656368 5200.preboot=ech
> => md fc0c0001 10
> fc0c0001: 65636801 00000074 0000003d 00000020 ech....t...=...
> fc0c0011: 0000005f 00000000 00000074 00000061 ..._.......t...a
> fc0c0021: 00000000 00000064 00000065 00000035 .......d...e...5
> fc0c0031: 00000000 00000062 0000003d 0000006f .......b...=...o
> => md.w fc0c0001 10
> fc0c0001: 0000 3701 0000 6f74 0000 643d 0000 6e20 ..7...ot..d=..n
> fc0c0011: 0000 745f 0000 7300 0000 6f74 0000 6c61 ..t_..s...ot..la
>
> This commit implements a workaround at least for the most blatant
> problem: using memcpy() from NOR flash. We rename the assembler
> routine into __memcpy() and provide a wrapper, which will use a
> byte-wise copy loop for unaligned source or target addresses when
> reading from NOR flash, and branch to the optimized __memcpy()
> in all other cases, thus minimizing the performance impact.
>
> Tested on lite5200b and TQM5200S.
>
> Signed-off-by: Wolfgang Denk <wd@denx.de>
> Cc: Detlev Zundel <dzu@denx.de>
Acked-by: Detlev Zundel <dzu@denx.de>
[...]
> diff --git a/arch/powerpc/cpu/mpc5xxx/memcpy_mpc5200.c b/arch/powerpc/cpu/mpc5xxx/memcpy_mpc5200.c
> new file mode 100644
> index 0000000..0950354
> --- /dev/null
> +++ b/arch/powerpc/cpu/mpc5xxx/memcpy_mpc5200.c
> @@ -0,0 +1,71 @@
> +/*
> + * (C) Copyright 2010
> + * 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
> + */
> +
> +/*
> + * This is a workaround for issues on the MPC5200, where unaligned
> + * 32-bit-accesses to the local bus will deliver corrupted data. This
> + * happens for example when trying to use memcpy() from an odd NOR
> + * flash address; the behaviour can be also seen when using "md" on an
> + * odd NOR flash address (but there it is not a bug in U-Boot, which
> + * only shows the behaviour of this processor).
> + *
> + * For memcpy(), we test if either the source or the target address
> + * are not 32 bit aligned, and - if so - if the source address is in
> + * NOR flash: in this case we perform a byte-wise (slow) then; for
^
+- copy
> + * aligned operations of non-flash areas we use the optimized (fast)
> + * real __memcpy(). This way we minimize the performance impact of
> + * this workaround.
> + *
> + */
[...]
Cheers
Detlev
--
WARNING: The external boundaries of India as depicted in map(s) are neither
correct nor authentic. Other external boundaries as depicted in the map(s)
may neither be correct nor authentic.
-- Garmin MapSource manual
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
next prev parent reply other threads:[~2010-06-25 8:35 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-21 20:29 [U-Boot] [PATCH] MPC5200: workaround data corruption for unaligned local bus accesses Wolfgang Denk
2010-06-22 23:10 ` [U-Boot] [PATCH v2] " Wolfgang Denk
2010-06-23 0:12 ` [U-Boot] [PATCH v3] " Wolfgang Denk
2010-06-25 8:35 ` Detlev Zundel [this message]
2010-06-29 9:48 ` [U-Boot] [PATCH] MPC512x: " Wolfgang Denk
2010-06-29 11:49 ` Detlev Zundel
2010-06-29 12:09 ` Wolfgang Denk
2010-06-29 12:41 ` Detlev Zundel
2010-06-29 12:42 ` Joakim Tjernlund
2010-06-29 12:55 ` Wolfgang Denk
2010-06-29 13:06 ` Joakim Tjernlund
2010-06-29 14:21 ` Joakim Tjernlund
2010-06-29 16:19 ` [U-Boot] [PATCH] MPC512x: workaround data corruption forunaligned " Steve Deiters
2010-06-29 19:24 ` Wolfgang Denk
2010-06-29 21:47 ` Joakim Tjernlund
2010-06-29 12:23 ` [U-Boot] [PATCH] MPC512x: workaround data corruption for unaligned " Anatolij Gustschin
2010-06-29 12:47 ` Wolfgang Denk
2010-06-29 13:34 ` Anatolij Gustschin
2010-06-29 12:45 ` [U-Boot] [PATCH] Use memcpy in print_buffer to fix unaligned dumps Anatolij Gustschin
2010-06-29 12:53 ` Wolfgang Denk
2010-06-29 12:57 ` Wolfgang Denk
2010-06-29 19:42 ` Mike Frysinger
2010-06-29 19:29 ` [U-Boot] [PATCH] MPC512x: workaround data corruption for unaligned local bus accesses Wolfgang Denk
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=m2sk4bcxwv.fsf@ohwell.denx.de \
--to=dzu@denx.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox