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

[Tom Rini <trini@ti.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/25/2012 01:08 PM, Scott Wood wrote:
> On 06/25/2012 01:43 PM, Tom Rini wrote:
>> 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.
> 
> It's something the driver backend should handle (possibly via a
> common helper library).  The fact that you can't do a DMA transfer
> to an unaligned buffer is a hardware-specific detail, just as is
> the fact that you're setting up a DMA buffer in the first place.

Right.  What I'm trying to say is it's not a NAND problem it's an
unaligned addresses problem so the solution needs to be easily used
everywhere.

>>> 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.  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?
> 
> I'm not sure what bootm has to do with nand (and the fact that some
> ppc is cache coherent actually doesn't matter, since we don't do
> DMA for NAND), but I was able to bootm from an odd RAM address, and
> "nand read" to an odd RAM address, on p5020ds.

On ARM-land we have a lot of problems with unaligned addresses, even
with cache off.  I went to reproduce the original bootm problem and
ran into fatload hanging.  tftp didn't fail but bootm hangs.

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJP6M6BAAoJENk4IS6UOR1WQXkP/1L0lbnKcpJ5jY9oCyIA29zE
r2eNVmsetudSTVC1rbQsmr5qd15xmzdqIi4yGVxOQIj6rj5eAhwRt8W6vRplNlSy
zRSFcZTh8YGdmNyLeiSiXFj/sxppIeSwPJqm1b17U7O43W8G4OVh73Ox1s7/YVB+
ag49VFokK0RBjgY8vux3YeJtpbDVTS0ZAmOXkoxLpvQgctttpnyDjoz9nbhfLA9d
BjmpVHKKkwKChhIuNyexMXregkZzfVAw9hJ9N3SCv0/x4VylRQBq3QNroHQJdGGq
0H0FRjAz9iLFu/EsHjmvzPgpCWeWgFLeGh1YLWORSZD3M8YlQvj5j6mSUsZjr8Ab
DJOyvZRsYgOK+h/+CIPdbGufY0yQfBPJPvzYkhxPAvs8zKkSwVYRm7xqPbSQNxYt
uBJh7Xw3M+rGVmqGmd6bERgeFOiL7BV3Jtfd3YaDQmJqiPS4r2nqwAjiDNaVUYlu
9TaxkbyTQl5PyCA+hkiwO4ebnSRgaGLrgnNZfkIuZD0qcpJ3A/Zldos2YXherwPc
/azJiitQvRrxxRU8RHEg1vkTOnX4urQi2cfPap+QiTb5KT+Gxrg6UPwBWvsOmDmY
MqIsHwgdpZflOOOX9Vco8ViSE44ePYaQDRLNhHbrdCAYEIEOxRIReAHs9YVVO2my
6OzYbd4sBdJDe/wl8s8X
=7znQ
-----END PGP SIGNATURE-----