linux-kernel - Re: OMAP: clock DT conversion issues with omap36xx

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1391371777.5453.6.camel@mars>
Date:	Sun, 02 Feb 2014 21:09:37 +0100
From:	Christoph Fritz <chf.fritz@...glemail.com>
To:	Nishanth Menon <nm@...com>
Cc:	Tero Kristo <t-kristo@...com>,
	Tomi Valkeinen <tomi.valkeinen@...com>,
	Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	linux-kernel@...r.kernel.org, pali.rohar@...il.com, pavel@....cz
Subject: Re: OMAP: clock DT conversion issues with omap36xx

On Sat, 2014-02-01 at 19:52 +0100, Christoph Fritz wrote:
> 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

Origin files of this diff added as attachment to this mail.


View attachment "ctt_dump_lil_a83x_next_20140124__breaks.rd1" of type "text/plain" (1148 bytes)

View attachment "ctt_dump_lil_a83x_next_20140115__works_as_expected.rd1" of type "text/plain" (1149 bytes)