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

Stephen Warren
2012-09-12T23:10:44Z

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.
>
> Try CONFIG_MMC_BOUNCE_BUFFER or what it was called ... see
> inclued/configs/m28evk.h , I use it there.

That didn't seem to change anything.

I just re-tested and it looks like there's one single instance of this
cache warning now when running "mmc dev 0"; there used to be hundreds of
them when loading files from eMMC. Perhaps it depends on some runtime
allocation or something though, and I'm just getting lucky and seeing
fewer of them.