I have just been debugging a couple of i.MX28 boards out of a small prototype run that would not boot. It turns out they were stuck during the early power initialisation that first sets the linear regulators to the target voltages, before later switching over to the DC-DC.
The supplied xldr.c in the Freescale BSP does the following for each rail:
// Restore VDDA 1.800 volt
HW_POWER_VDDACTRL_WR(HW_POWER_VDDACTRL_RD() | BM_POWER_VDDACTRL_BO_OFFSET);
HW_POWER_VDDACTRL_WR((HW_POWER_VDDACTRL_RD() & ~BM_POWER_VDDACTRL_TRG) | VDDAVolt2Reg(1800));
// need to wait more than 10 microsecond before the DC_OK is valid
// wait for DC_OK
while (!(HW_POWER_STS_RD() & BM_POWER_STS_DC_OK));
It turns out that the two problem boards got stuck on the while statement at the end waiting for DC_OK to clear. When running from linear regs the DC_OK flag is set if the output voltage is > target. If I comment out the while statement it moves onto the next rail (VDDIO) and hangs there at the same point, then if I comment it out it gets to VDDA and hangs again.
I am not sure the code should be checking DC_OK when running from linear regs. Looking at the Windows CE PMU driver code the implementation is different in that after changing the target voltage the code only checks DC_OK if running from a DC-DC converter, otherwise it just adds in a 100us delay and continues.
I am guessing that tolerances between the processors determine if this flag is clear at this point (2 boards out of 9 had the issue). Either way if I comment out the 'while' and let it continue the board boots up fine. I all rails are at the correct programmed voltages and the rail power-up waveform looks great on a scope.
My question is: Is this OK to do? It seems only xldr.c checks the DC_OK flag after changing the linear regulator target. The CE PMU driver and Linux code do not seem to bother waiting for DC_OK as this really only applies to the DC_DC converter.