On Sat, 5 Dec 2009 21:27:30 +0100 Peter Korsgaard jacmet@sunsite.dk wrote:
"Kim" == Kim Phillips kim.phillips@freescale.com writes:
Kim> On Fri, 20 Nov 2009 12:42:43 +0100 Kim> Peter Korsgaard jacmet@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