On Wed, Jun 27, 2018 at 04:07:11PM +0200, Mogens Lauridsen wrote: > PLL3 was first set to 400MHz and then some peripheral was switched > to PLL3. Finally PLL3 was set to 216MHz. This could make some > i.MX538 hang in a dead loop in the boot process. Let's see what the code currently does: By reset default the clock path to the DDR is: PLL2 (192MHz) -> periph_clk -> main_bus_clk -> axi_a_podf -> axi_a (/1 = 192MHz) -> ddr_clk_root PLL2 is running at 192MHz. The code now tries to switch PLL2 from 192MHz to 400MHz. This requires that the RAM is driven by some other clock during the PLL reconfiguration. The code switches the clock path to: PLL3 (400MHz) -> periph_clk -> main_bus_clk -> axi_a_podf -> axi_a (/2 = 200MHz) -> ddr_clk_root Then PLL2 is reconfigured to 400MHz and the DDR clock path is switched back to the original path, this time with the PLL runnning at 400MHz, so RAM is then running at the desired speed. The code configures PLL3 to 400MHz probably to keep the DDR frequency nearly constant during the transition. I have no idea why your change helps you. When I understand correctly then you are running nearly at half the frequency during the transition (400/216). I'm afraid to merge such change as long as we do not fully understand what we are doing and why it helps. BTW the current code is the same as on U-Boot which is derived from the original Freescale code, so this is not exactly new or barebox specific. Do you have anything special in your dcd table that influences the clocks in an unexpected way? Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
