[U-Boot] mx28 spl power cpu clock configuration

[Marek Vasut]

> 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.

Stepping through the code is not recommended, that's why I couldn't debug 
certain parts of the power init code either. But I don't think it's a bug, I 
suspect it's an expected behaviour during this transition.
> 
> 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?

This seems reasonable. Fabio, can you comment?

M

> 
> Cheers,
> 
>         Robert.