Re: [U-Boot] [PATCH 2/2] i.MX28: Fix ref_cpu clock setup
Hi,
In addition to my first patch, please consider accepting this patch too. It prevents needless switching on and off PLL bypass mode and it allow single stepping through the SPL.
Hi,
this is how the imx-bootlets does it though. It's likely that FSL wants the PLL0 to run from XTAL when doing power configuration?
M
This patch removes mx28_power_clock2xtal, because all this function does is switching to reset-defaults, at a moment only reset defaults are already active.
It removes mx28_power_clock2pll becasue it is incomplete and because mx28_mem_init_clock does the same thing a little later on and does it corectly.
Maybe clock2pll should be fixed then ?
M
Signed-off-by: Robert Delien (robert@delien.nl)
From: Marek Vasut [marek.vasut@gmail.com] Sent: 26 January 2012 19:32 To: Fabio Estevam Cc: Robert Deliën; u-boot@lists.denx.de Subject: Re: mx28 spl power cpu clock configuration
Hi Robert,
On 1/25/12, Marek Vasut marek.vasut@gmail.com wrote:
Shouldn't we configure clkctrl_frac0 - or at least disable CPU clock gating - before disabling PLL bypass?
This seems reasonable. Fabio, can you comment?
Could you please post a patch with your proposed change so that we can test it?
Hi Fabio,
I bought a really crappy custom board a few days ago (some china-made crap) sporting mx287, but apparently I'm hitting similar issue you do here.
When I swap power_init and mem_init though, the board boots fine, othervise it hangs.
M
Hi,
this is how the imx-bootlets does it though. It's likely that FSL wants the PLL0 to run from XTAL when doing power configuration?
I was using the FLS bootlets as a reference too, but I have noticed a number of 'mistakes' in that code. For example: - Busy-indicators aren't considered when reconfiguring PLLs - They are linked right on top of the expection vectors - Sloppy printf macros left out <CR>s So for me it's more of a best effort example than a Reference. And personally, I'd rather have the CPU running from a rock-solid - yet slower - xtal, than a sensitive PLL0 when I start tickering with power supplies.
Maybe clock2pll should be fixed then ?
That's how I started. But properly configuring PLL0 also requires to properly configure EMI, or the board will hand. And this is exactly what is done in mx28_mem_init_clock.
clock2pll is broken: It disables PLL bypass without configuring PLL0 first, or even ungating it. I don't fully understand why it works in normal operation. Perhaps due to some bus-lag.
I think it is justified to remove it, because what it intends to do, is done slightly later by mx28_mem_init_clock. I think FSL reused/shares this code with other platforms, where no mx28_mem_init_clock is present, but in that case they do have a bug to fix.
Cheers,
Robert.
Hi,
this is how the imx-bootlets does it though. It's likely that FSL wants the PLL0 to run from XTAL when doing power configuration?
I was using the FLS bootlets as a reference too, but I have noticed a number of 'mistakes' in that code. For example:
- Busy-indicators aren't considered when reconfiguring PLLs
- They are linked right on top of the expection vectors
- Sloppy printf macros left out <CR>s
Do you know why we use our own implementation of the boot code instead of imx bootlets? ;-)
So for me it's more of a best effort example than a Reference. And personally, I'd rather have the CPU running from a rock-solid - yet slower - xtal, than a sensitive PLL0 when I start tickering with power supplies.
If you can guarantee the CPU won't go insane during some power transition when running from xtal, then it's fine by me. Then it makes me wonder though, why FSL switched to PLL.
Maybe clock2pll should be fixed then ?
That's how I started. But properly configuring PLL0 also requires to properly configure EMI, or the board will hand. And this is exactly what is done in mx28_mem_init_clock.
clock2pll is broken: It disables PLL bypass without configuring PLL0 first, or even ungating it. I don't fully understand why it works in normal operation. Perhaps due to some bus-lag.
Fabio?
I think it is justified to remove it, because what it intends to do, is done slightly later by mx28_mem_init_clock. I think FSL reused/shares this code with other platforms, where no mx28_mem_init_clock is present, but in that case they do have a bug to fix.
Cheers,
Robert.
Thanks
M
participants (2)
-
Marek Vasut -
Robert Deliën