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

Albert ARIBAUD
2011-08-10T06:29:41Z

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.