[U-Boot] mx28 spl power cpu clock configuration

[Robert Deliën]

Hi Marek/Fabio,

I think there's an error in code setting up the CPU clock in the
SPL for the i.MX28. When instruction stepping through
mx28_power_clock2pll in spl_power_init.c, the processor drops dead
right after PLL bypass has been disabled.

The i.MX28 reference manual (pag 116) states that the JTAG clock is
derived from the CPU clock and that the JTAG tap will stop working
if CPU clock is stalled, too low or disabled. I figured that
disabling PLL bypass would temporarilly cause an irregular clock,
throwing off the probe, even in adaptive clocking mode. Three
different probes later, I know it is not.

Freescal tech support said it may be related to a non ARM specification
shortcut in the clock tree, but that's not causing the problem either.

I succeeded in reproducing the problem using only my JTAG probe
(Abatron BDI300) on adaptive clocking. Below the transcript of
the probe's command line interface:
926E>reset
...
926E>md 0x80040000 1
80040000 : 0x00000000            0  ....
926E>mm 0x80040000 0x00020000
926E>md 0x80040000 1
80040000 : 0x00020000       131072  ....
926E>
926E>md 0x800401d0 1
800401d0 : 0x000441ff       279039  .A..
926E>mm 0x800401d0 0x000041ff
926E>md 0x800401d0 1         
After the last command, both mx28evk board and JTAG probe hang. The
last JTAG transaction, caused by the last 'mm'-command, is shown on
attachement 'TCK-RTCK, Adaptive, No Frac0.png'. This picture shows that
the transaction the probe is raising TCK, but the target is no longer
following it, as it's supposed to do.

When configuring the probe at a fixed clock of 1MHz, the same sequence
no longer hangs up the probe, but just hangs up the target:
926E>reset
...
926E>md 0x80040000 1
80040000 : 0x00000000            0  ....
926E>mm 0x80040000 0x00020000
926E>md 0x80040000 1         
80040000 : 0x00020000       131072  ....
926E>
926E>md 0x800401d0 1         
800401d0 : 0x000441ff       279039  .A..
926E>mm 0x800401d0 0x000041ff
926E>md 0x80040000 1         
80040000 : 0xffffffff           -1  ....
The last read-back is obviously a bogus value. The last JTAG
transaction, caused by the last 'mm'-command, is shown on
attachement 'TCK-RTCK, 1MHz, No Frac0.png'. This picture shows that
half-way the transaction the stops outputting RTCK, while the probe
continues on it's fixed clock.

I think the cause of this problem is that PLL bypass is disabled - using
PLL0 as CPU clock source instead of it's reference xtal - while CPU
clock gating on PLL0 is still enabled. Now I don't fully understand why
this problem only occurs when instruction-stepping the code, and not
under normal operating conditions. It may be related to delay, because
some time later mx28_mem_init in spl_mem_init.c does disable CPU clock
gating on PLL0.

I have tested this by modifying the sequence above by inserting commands
to disable CPU clock gating:
926E>reset
...
926E>md 0x80040000 1
80040000 : 0x00000000            0  ....
926E>mm 0x80040000 0x00020000
926E>md 0x80040000 1
80040000 : 0x00020000       131072  ....
926E>
926E>md 0x800401b0 1
800401b0 : 0x92929292  -1835887982  ....
926E>mm 0x800401b0 0x12525513
926E>md 0x800401b0 1
800401b0 : 0x52521513   1381111059  ..RR
926E>
926E>md 0x800401d0 1
800401d0 : 0x000441ff       279039  .A..
926E>mm 0x800401d0 0x000041ff
926E>md 0x800401d0 1
800401d0 : 0x000041ff        16895  .A..
After this sequence, both probe and board are still fully responsive.
Even the written value can be read back successfully. Attachement
'TCK-RTCK, Adaptive, Frac0.png' shows the JTAG transaction, caused by
the last 'mm'-command. The zoomed section at the bottom shows how the
clock frequency increases half-way the command.

The sequence above changes more to the clkctrl_frac0 register than just
disabling CPU clock gating, but I have repeated this sequence writing
a value of 0x92929212 (over a power-up default of 0x92929292) and that
works just the same.

Shouldn't we configure clkctrl_frac0 - or at least disable CPU clock
gating - before disabling PLL bypass?

Cheers,

        Robert.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TCK-RTCK, Adaptive, No Frac0.png
Type: image/x-png
Size: 43567 bytes
Desc: TCK-RTCK, Adaptive, No Frac0.png
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120125/d72d1181/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TCK-RTCK, 1MHz, No Frac0.png
Type: image/x-png
Size: 47532 bytes
Desc: TCK-RTCK, 1MHz, No Frac0.png
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120125/d72d1181/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TCK-RTCK, Adaptive, Frac0.png
Type: image/x-png
Size: 60682 bytes
Desc: TCK-RTCK, Adaptive, Frac0.png
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120125/d72d1181/attachment-0002.bin>