All, Thanks for all your input and time. We'll try rolling our sleeves up and looking at these GPMC timings again. Looking through those links I shared previously, it looks like the AM35xx GPMC may be setup a bit differently than the OMAP or DM. What items should I be taking into account as we try to draft this up ourselves? For instance, from (http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/416/t/49394.aspx), it appears that my L3 clock should be set to 166MHz and GPMC_FCLK should be 83MHz. My source is new enough that it now includes the various patches to enable the MPU to run at 600MHz instead of 500MHz. (This patch is part of that: http://lists.denx.de/pipermail/u-boot/2012-February/117018.html. ; There were more, but I couldn't find them quickly when pulling this email together.) Does that adjust anything here with respect to these GPMC calculations, or is the L3 held steady so it does not matter? After all that crashing yesterday and the day before, we setup some additional tests, and now it seems we can't break it... This is precisely why we've had to keep hunting for this thing for so long. It rears its ugly head and crashes us a ton, only to disappear back into the vapor. Thanks again for all your help and time. If we get any more points of interest I'll certainly share. ----- Original Message ----- From: Jarkko Nikula <jarkko.nikula@xxxxxxxxxx> To: Tony Lindgren <tony@xxxxxxxxxxx> Cc: CF Adad <cfadad@xxxxxxxxxxxxxx>; "Shilimkar, Santosh" <santosh.shilimkar@xxxxxx>; "linux-omap@xxxxxxxxxxxxxxx" <linux-omap@xxxxxxxxxxxxxxx> Sent: Wednesday, June 6, 2012 6:37 AM Subject: Re: Please help! AM35xx mm/slab.c BUG my 2 cents. On 06/06/2012 11:41 AM, Tony Lindgren wrote: > * CF Adad <cfadad@xxxxxxxxxxxxxx> [120606 00:55]: >> >> Do you folks know of a good reference for properly calculating these GPMC settings? > > In theory you just need to know the timings of connected components, > then check which ones depend on cycles and which ones depend on time. > I afraid paper-and-pencil gpmc exercise is often required but after that it is more easy to see from charts if e.g. original settings were not optimal or too near to edge. Helps to understand and point possible problems on oscilloscope measurements too. > Also take into account latencies added by level shifters if you have those. > Paul Walmsley noticed a few years ago that those affected the smsc911x > timings if not accounted for. > I've noticed the same. Even one-directional level shifters easily add a few ns and double amount in read operation since then there are two level shifters in a path: one in clk/cs/oe/etc cpu-to-chip signal and one on chip-to-cpu side. Pay also attention if there are extra latencies in chip. Chip memory reads/writes may be slower than chip register access (probably similar than smsc fifo issue what Tony mentioned earlier in this thread). -- Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
