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: <20140201185216.GA7125@mars>
Date:	Sat, 1 Feb 2014 19:52:16 +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 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/