[U-Boot] [PATCH v3] MPC5200: workaround data corruption for unaligned local bus accesses

[Detlev Zundel]

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 at denx.de>
> Cc: Detlev Zundel <dzu at denx.de>

Acked-by: Detlev Zundel <dzu at 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