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

Marek Vasut
2012-06-15T14:33:41Z

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@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