From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Mon, 25 Jun 2012 13:48:01 -0700 Subject: [U-Boot] [PATCH 6/9] CACHE: nand read/write: Test if start address is aligned In-Reply-To: <4FE8C529.30509@freescale.com> References: <1340583477-14018-1-git-send-email-marex@denx.de> <1340583477-14018-7-git-send-email-marex@denx.de> <4FE898A2.9060801@freescale.com> <20120625184354.GA6377@bill-the-cat> <4FE8C529.30509@freescale.com> Message-ID: <4FE8CE81.4060408@ti.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de -----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-----