> 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. _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
