From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Denk Date: Mon, 16 May 2011 20:32:23 +0200 Subject: [U-Boot] [PATCH 0/4] Accurate boot time measurement In-Reply-To: References: <1305319923-9477-1-git-send-email-sjg@chromium.org> <20110515115317.56695DB7945@gemini.denx.de> <20110516054810.AE67F1491B07@gemini.denx.de> Message-ID: <20110516183223.BBBAA1491B09@gemini.denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Simon Glass, In message you wrote: > > Such a lot of text about such a small patch. It is clear to me that you are > used to doing things one way, and this is a different approach. As I said You can tell many things about me, but this one certainly is not the case. > > I don't see that we use any FIFOs in the output direction. > > Yes we do, and in fact they do improve boot performance slightly when the > console is muted. Do you have an explanation how that works? When there is no output on the console, the use of a FIFO in tx direction should not matter at all? > I agree it is unfortunate to have features which require platform-specific > features. Perhaps we should define a microsecond timer as a requirement of a > U-Boot port? Or perhaps an option which opens up new features? We already have that, or better. The problem is that it depends on the architecture. On PPC systems for example you always have the time base, a 64 bit counter which is clocked with something like 1/4 or 1/16 of the CPU clock. And whe have the timer that gettime() is based on - which is in milliseocnd resolution (hence the demand that CONFIG_SYS_HZ must always be defined as 1000). The problem comes with the multitude of different architectures and SoCs we support - there is no concept of timebase registers on ARM, on some systems we need interrupts to implement timer services so these are available only after relocation, etc. > > But you need storage for the timing events, and you don't have this > > before relocation. So you miss some really interesting parts of the > > boot procedure. > > It is easy enough to get storage if we want it - you can maintain a > pre-reloc table which is copied over afterwards. I notice that some Where will you store this "pre-reloc" table? Yes, there are some systems with plenty of on-chip-memory or huge caches that can beused for this. But there are also systems where we barely can find the room for the most vital global data before relocation. Even worse - if you take this seriously, you will probably also get timing information from early boot stages, like how long it's taking to load the U-Boot image from NAND - but on some systems this loader code has to fit in as little as 2 KiB. > I believe it compares favourably. It has a more friendly display, doesn't > require a serial port, is more accurate, can run self-hosted, etc. With the > TCL script you need to add a new line before you will get a new time. Well, the display format is trivial to adapt, as well as the trigger criteria. Keep in mind that this is just an example script that covers the most common use case we've seen so far. > > But to do so, you need to insert trace points. With the same effort > > we can insert a printf(). > > Fair enough. If you have your heart set on the TCL script I'm really not > going to get very far! I haven't my heart set on it. It is just one example of solutions which cover a large percentage of the potential use cases. I am trying to understand the ration of advanatges versus effort, that's all. > In terms of all this discussion I can see your point :-) I did have > expressions of interest from two people including one I thought was at your > company, which I why I went to the effort to clean up and submit this. At > that time I didn't realise it would be such a touchy subject. Where is the problem? If you are convinced of you idea you should be ready to defend it. If you are not, it's not wort it at all. And if you see a voting result of 2:1 pro this is pretty good, isn't it? > But if you really don't want this in U-Boot then please accept my apologies > for wasting so much time on the list. I don't consider this discussion a waste of time. I hope you don't do, either. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Life would be so much easier if we could just look at the source code. -- Dave Olson