[U-Boot] [PATCH 2/4] cache_v7: Check for dcache enablement in dcache flush functions

[Marek Vasut]

Dear Tom Rini,

> On 06/15/2012 07:25 AM, Marek Vasut wrote:
> > Dear Tom Rini,
> > 
> >> On 06/14/2012 10:48 PM, R, Sricharan wrote:
> >>> Hi Tom,
> >>> 
> >>> On Fri, Jun 15, 2012 at 12:31 AM, Tom Rini <trini at ti.com> wrote:
> >>>> If we are built with D-CACHE enabled but have run 'dcache off' and
> >>>> then attempt to flush unaligned regions we spam the console with
> >>>> problems that aren't true (as the cache was off).
> >>>> 
> >>>   Today we do cache maintenance operations after the dcache is turned
> >>>   off. One example is before jumping to kernel, we try to invalidate
> >>>   the caches, in cache turned off state. So with this patch those
> >>>   maintenance calls will do nothing, which is not correct.
> >> 
> >> Ah yes,  But, shouldn't we be doing these same operations as part of
> >> turning the cache off?
> >> 
> >>>    If it is a problem with unaligned regions, then that is the only
> >>> 
> >>> thing to be fixed
> >>> 
> >>>   right ?. Just trying to understand why this change is required ?
> >> 
> >> The problem is that within the USB/network/filesystem stacks we have a
> >> lot of not cache safe alignments apparently.  Without this every '#' of
> >> a tftp gives a screen full of error printfs.  So tftp'ing a kernel takes
> >> minutes, not seconds, to complete.
> > 
> > I think we should augment uboot to disallow tftp, fatload etc. to cache-
> > unaligned address when caches are on ... this'd squash away the need for
> > any shitty bounce buffers right away. Tom, will you be able to implement
> > it, pretty please?
> 
> But that's not the problem.  The problem is all of the stuff going on
> within the USB/networking stack.

Correct. This will shield you from the users, I think it's worth to implement 
like that asap anyway. Or do we want a bounce buffer? I doubt that.

The other part is to fix the internals of u-boot. This will be the harder part.

Best regards,
Marek Vasut