From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Mon, 16 May 2011 13:25:08 -0500 Subject: [U-Boot] [PATCH 0/4] Accurate boot time measurement In-Reply-To: <20110516114020.B7D3B1491B07@gemini.denx.de> References: <1305319923-9477-1-git-send-email-sjg@chromium.org> <20110515115317.56695DB7945@gemini.denx.de> <20110516054810.AE67F1491B07@gemini.denx.de> <20110516114020.B7D3B1491B07@gemini.denx.de> Message-ID: <20110516132508.2d44b047@schlenkerla.am.freescale.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Mon, 16 May 2011 13:40:20 +0200 Wolfgang Denk wrote: > Dear Graeme Russ, > > In message you wrote: > > > > > As we can trivially use regular expressions, the effort to implement a > > > "timing parser" can be ignored. And it is independet of what sort of > > > boot device we are using. > > > > Fine if your running Linux - What if the only tool tyou have is > > Hyperterminal? > > AFAICT tcl is also available under Windoze... What about a board farm with a networked serial port server, adding unpredictable latency? Even if you have direct access to the host serial port, there's not just the host FIFO distorting things, but the scheduling latency of the application. I suspect the useful precision of this approach is significantly higher than 100 us. > What makes you think a call to printf()/puts()/putc() would increase > the code size worse than a call to the trace function? If I don't > care about pretty messages (and use silent console otherwise) my > serial console based messages consist of a plain "putc('a')" or > similar - certainly not more overhead than the call to the trace > function. The size impact minor in either case, but in terms of time overhead (i.e. the thing being measured), waiting for previous output to go over the wire and the THR to empty is less overhead than putting a timestamp in a log? Even if THR is already empty, those I/O accesses tend to be much more expensive than reading from an CPU-internal time source and writing to a cached data structure. > It's not about willing or not. If willing or wanting would help, we > had an ideal world. But in reality, we have a world full of > restrictions. And requiring that debugging infrastructure for such a low-level piece of software be universally applicable is a pretty big self-imposed restriction... How many targets are so short on pre-relocation memory that they can't spare a couple hundred bytes for debugging, lacking a suitable time source, etc.? It seems like the concept would be usable on more than just a handful of boards, even if not necessarily all of them. > GD is definitely not buffer space for arbitrary amounts of log data. When did "limited" become "arbitrary"? -Scott