On Wed, Jan 29, 2014 at 01:03:52PM -0600, Nishanth Menon wrote: > To help us debug similar problems, I wrote a tool today: > https://github.com/nmenon/ctt-dump - it is a simple memory read utility, > Input file is CTT dump-out > For example: 3630 CTT is here: > http://www.ti.com/pdfs/wtbu/CTT-OMAP3630ES1.x-v1.6.0.4.zip > > to give an idea - i posted a screen shot here: > https://plus.google.com/112464029509057661457/posts/hNdee4gNfob > > After generating the the rd1 file from CTT, > we pick up the registers using ctt-dump -> any tool which can do > register reads could do, but it might be handy having this. > Example output on beagle-xm: http://slexy.org/view/s2YWmM1ium > importing it back into CTT and after setting up the correct sysclk, we > can compare clock frequencies Vs debugfs output - example: > http://slexy.org/view/s21iQyDTct > > > I mean, it is awesome having to debugfs data, but with nascent > systems, it is always good to compare to what the hardware is really > configured to - and CTT is the easy way to deal with it. Oscilloscope on pin sysclkout2 measures 24 Mhz with next_20140115 on this hardware here (omap3-lil-a83x). Its corresponding rd1 file, generated by ctt-dump, shows in CTT incorrectly 100 Mhz. The hardware has a 26 Mhz crystal. The error in CTT is that MUX_sys_clkout2 doesn't configure CLKOUT2SOURCE right. 0x2 is CM_96M_FCLK not CORE_CLK for example. This is the diff of clk registers before and after DT clock conversion patches: --- ctt_dump_lil_a83x_next_20140115__works_as_expected.rd1 +++ ctt_dump_lil_a83x_next_20140124__breaks.rd1 2014-02-01 @@ -22,23 +22,23 @@ 0x48004c10 0x0000002f 0x48004c30 0x0000023f 0x48004c40 0x00000014 -0x48004d00 0x10370037 +0x48004d00 0xf0371037 0x48004d04 0x00000017 0x48004d40 0x09900c00 0x48004d44 0x0483600c 0x48004d48 0x00000009 0x48004d4c 0x0000780c 0x48004d50 0x00000001 -0x48004d70 0x00000092 -0x48004e00 0x00000001 +0x48004d70 0x0000009a +0x48004e00 0x00000000 0x48004e10 0x00000001 0x48004e30 0x00000001 -0x48004e40 0x0000100f +0x48004e40 0x00001009 0x48004f00 0x00000000 0x48004f10 0x00000000 0x48004f30 0x00000001 0x48004f40 0x00000004 -0x48005000 0x00040800 +0x48005000 0x00000800 0x48005010 0x00078fff 0x48005030 0x0007ffff 0x48005040 0x000000ff Thanks -- Christoph -- 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
