[U-Boot] Cache alignment warnings on Tegra (ARM)

[Thierry Reding <thierry.reding@avionic-design.de>]

On Fri, Sep 14, 2012 at 08:53:32AM -0700, Simon Glass wrote:
> Hi,
> 
> On Wed, Sep 12, 2012 at 4:42 PM, Marek Vasut <marex@denx.de> wrote:
> > Dear Stephen Warren,
> >
> >> On 09/12/2012 04:38 PM, Marek Vasut wrote:
> >> > Dear Stephen Warren,
> >> >
> >> >> On 09/12/2012 10:19 AM, Tom Warren wrote:
> >> >>> Folks,
> >> >>>
> >> >>> Stephen Warren has posted an internal bug regarding the cache
> >> >>> alignment 'warnings' seen on Tegra20 boards when accessing MMC. Here's
> >> >>> the gist:
> >> >>>
> >> >>> Executing "mmc dev 0" still yields cache warnings:
> >> >>>
> >> >>> Tegra20 (Harmony) # mmc dev 0
> >> >>> ERROR: v7_dcache_inval_range- stop address is not aligned- 0x3fb69908
> >> >>> mmc0 is current device
> >> >>
> >> >> ...
> >> >>
> >> >>> There have been patches in the past (IIRC) that have tried to ensure
> >> >>> all callers (FS, MMC driver, USB driver, etc.) force their buffers to
> >> >>> the appropriate alignment, but I don't know that we can ever correct
> >> >>> every instance, now or in the future.
> >> >>>
> >> >>> Can we start a discussion about what we can do about this warning?
> >> >>> Adding an appropriate #ifdef (CONFIG_SYS_NO_CACHE_ALIGNMENT_WARNINGS,
> >> >>> etc.) where Stephen put his #if 0's would be one approach, or changing
> >> >>> the printf() to a debug(), perhaps. As far as I can tell, these
> >> >>> alignment 'errors' don't seem to produce bad data in the transfer.
> >> >>
> >> >> I don't think simply turning off the warning is the correct approach; I
> >> >> believe they represent real problems that can in fact cause data
> >> >> corruption. I don't believe we have any choice other than to fully solve
> >> >> the root-cause.
> 
> Yes I agree, and I think it is pretty close - certainly much better
> than it used to be. The good thing about them being annoying is that
> they will likely get fixed :-)

I think I traced this to the copying of CSD a while back. The problem is
that the transferred buffer is 8 bytes, so there's no way to make it
aligned properly. Unfortunately the entailing discussion did not yield a
solution at the time.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120915/f04d0695/attachment.pgp>