On Sat, 5 Dec 2009 21:27:30 +0100 Peter Korsgaard <jac...@sunsite.dk> wrote:
> >>>>> "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. none, really. Just safety from any potential unknown behaviour: http://lists.denx.de/pipermail/u-boot/2009-September/061580.html > >> 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. ok let's leave it as _EARLY then. wrt boards in current u-boot, can you add the _EARLY define in their default config files? I'm trying to extend the benefit of the patch to existing boards, not only out-of-tree boards. Speaking of which, new board patches are welcome. Kim _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot