[U-Boot] [PATCH 6/9] CACHE: nand read/write: Test if start address is aligned

[Marek Vasut <marex@denx.de>]

Dear Tom Rini,

> On Mon, Jun 25, 2012 at 11:58:10AM -0500, Scott Wood wrote:
> > On 06/24/2012 07:17 PM, Marek Vasut wrote:
> > > This prevents the scenario where data cache is on and the
> > > device uses DMA to deploy data. In that case, it might not
> > > be possible to flush/invalidate data to RAM properly. The
> > > other option is to use bounce buffer,
> > 
> > Or get cache coherent hardware. :-)
> > 
> > > but that involves a lot of copying and therefore degrades performance
> > > rapidly. Therefore disallow this possibility of unaligned load
> > > address altogether if data cache is on.
> > 
> > How about use the bounce buffer only if the address is misaligned?  The
> > corrective action a user has to take is the same as with this patch,
> > except for an additional option of living with the slight performance
> > penalty.  How often does this actually happen?  How much does it
> > actually slow things down compared to the speed of the NAND chip?
> 
> We would need to architect things such that any 'load' command would be
> routed through this logic.  A solvable problem for sure, but a little
> bit larger than just for NAND :)

It's not only NAND, it's the whole user interface that's broken right now.

> > I'm hesitant to break something -- even if it's odd (literally in this
> > case) -- that currently works on most hardware, just because one or two
> > drivers can't handle it.  It feels kind of like changing the read() and
> > write() system calls to require cacheline alignment. :-P
> 
> I don't want to get into an ARM vs PowerPC argument.

ARM is better anyway :-D

> I think the best
> answer is that I'm not sure having things unaligned works totally right
> today as I did a silly test of loading a uImage to 0x82000001 and bootm
> hung inside of U-Boot not long ago.  Can you try that on some cache
> coherent hardware and see if that works?

+1

[...]

Best regards,
Marek Vasut