On Thu, 26 Mar 2015 18:57:02 -0500 Rivera Jose-B46482 German.Rivera@freescale.com wrote:
From: Kim Phillips [mailto:kim.phillips@freescale.com] Sent: Wednesday, March 25, 2015 4:13 PM
On Tue, 24 Mar 2015 21:32:56 -0500 Stuart Yoder b08248@gmail.com wrote:
On a system with the MC running with caches on, u-boot took 20 seconds to boot. The MC took about 5 seconds of that, most of that in DPL processing.
We would welcome help analyzing u-boot boot time and where the time is going. But, seriously, saving 1 ms is not going to help at all.
I did a quick experiment and saved ~50ms when setting both udelays down to 50, which, sure, isn't a big deal given it's out of the order of 10sec, but it's something, and, like I said, development time for our users can be seriously helped if MC initialization were omitted from the main u-boot boot sequence, and occurred only when necessary, i.e., when users want to use one of the DP net interfaces. Most of the time when we boot today, we don't use DP net interfaces, so MC init - with or without DPL processing - is just a waste of our time!
The 50ms improvement you claim will not make any difference to save time For development users, since 50ms is not something humans can perceive. As Stuart said, we (the MC team) should first analyze where is the bulk of The DPL processing by the MC fw is being spent, to see how much we can reduce the 5 seconds spent there. That is, we should be concerned first about where we can save big bucks, before being concerned about where we can save one penny or two.
my point is that all 10 seconds of MC processing should be removed from u-boot startup time, and moved to only when u-boot needs to use MC-based ethernet, e.g., when a tftp command is invoked.
and, fwiw, the 50ms figure will improve as MC firmware performance improves.
Kim