[U-Boot] [PATCH 4/4] armv7: cache: remove flush on un-aligned invalidate

[Albert ARIBAUD]

Hi Anton,

Le 09/08/2011 18:39, Anton Staaf a écrit :
> I'm not sure what the larger context of this change is, but it seems
> like a bad idea to me.  There are a lot of locations in U-Boot that
> will end up causing an unaligned invalidate (ext2 and dos file system
> code in particular).  And this change will cause those unaligned
> invalidates to possibly throw away stores to adjacent variables.  If
> you are going to make this change you should at least assert instead
> of just printing a warning.  And there should be a concerted effort to
> clean up the buffer management in U-Boot so that invalidates will
> never be unaligned.  This is also a departure from the cache
> management implementations in the Linux kernel, not that U-Boot has to
> do exactly what they do, but I feel they have the correct
> implementation, from the perspective of ensuring that all stores
> actually make it to main memory.

There's been a lot of discussion, both in July and August, about this 
and the the conclusion is that unaligned invalidates (and flushes) 
cannot reliably be done within the size and speed constraints of an 
embedded bootloader, and there are no 100% clean solutions without 
alignment, because with unaligned buffers, one might invalidate a cache 
line containing also deferred writes, or flush a line onto a buffer 
currently undergoing DMA. Linux can afford to spend more space and time 
than U-Boot to solving those issues. OTOH, aligning buffers is a 
relatively trivial change in the calling code that allows for much 
simpler and more efficient cache management.

The current cache patches on ARM are precisely the start of the effort 
to align buffers that you suggest, by warning the developer about 
unaligned invalidates/flushes through the console, and turning any side 
effect to an "inside-effect", so to speak: for instance the recent cache 
invalidate patch on arm926ejs prevents unaligned invalidates from 
affecting any other data than the (badly) invalidated buffer itself.

You have a point though that maybe a warning is not enough and that 
unalignments warrant an assert instead. OTOH, that might mean *a lot* of 
boards will completely cease working in this case, even for live 
debugging the issue with basic U-Boot commands (which many developers do 
I am sure).

Comments on this warning/assert point?

Amicalement,
-- 
Albert.