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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
