>>>>> "Kim" == Kim Phillips <kim.phill...@freescale.com> writes:
Kim> On Fri, 20 Nov 2009 12:42:43 +0100 Kim> Peter Korsgaard <jac...@sunsite.dk> wrote: >> E.G. on a 8347 board a bootup time increase of ~600ms has been observed: Kim> heh, even more on an 8313! Thanks for this - I hadn't realized the Kim> difference was so large (or neglected it since the move to init_r was Kim> done at the last moment). OK, why exactly was it moved? What do you want to protect against? I don't remember seing anyone complaining about the old location. >> Fix it by introducing CONFIG_SYS_LCRR_EARLY, and set LCRR in cpu_init_f >> instead of in cpu_init_r if set. Kim> instead of introducing the new CONFIG_SYS_LCRR_EARLY, shouldn't we Kim> check for something like: Kim> !defined(CONFIG_NAND_SPL) && !defined(CONFIG_SYS_RAMBOOT) As in do the reconfig early if we're running from RAM right away? It's not that simple - I have a board which boots from NOR flash. As that is an async device there isn't any problem in changing the LBC settings while you're running from flash (as long as you respect the min access time). I have another design where the flash sits behind a FPGA (for signal integrity reasons), and there I have to wait until we're running in RAM before changing the LBC clock. On the 2nd design I even have to tell the FPGA to resync (through a GPIO pin) and wait a bit before I can continue, so I'm doing the LCRR config in board code (in board_early_init_r). The move to cpu_init_r broke that as well as the LCRR value is overwritten there. Kim> btw, this generates: Kim> cpu_init.c: In function 'cpu_init_r': Kim> cpu_init.c:367: warning: unused variable 'im' Ups, I'll fix that and send a new patch once we agree on the form. -- Bye, Peter Korsgaard _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
