Hi,
On 02/13/2017 11:16 AM, Nico Huber wrote:
On 13.02.2017 08:19, Andrey Petrov wrote:
For example Apollolake is struggling to finish firmware boot with all the whistles and bells (vboot, tpm and our friendly, ever-vigilant TXE) under one second.
Can you provide exhaustive figures, which part of this system's boot process takes how long? That would make it easier to reason about where "parallelism" would provide a benefit.
Such data is available. Here is a boot chart I drew few months back: http://imgur.com/a/huyPQ
I color-coded different work types. Some blocks are coded incorrectly please bear with me).
So what we can see is that everything is serial and there is great deal of waiting. For that specific SDHCI case you can see "Storage device initialization" that is happening in depthcharge. That is CMD1 that you need keep on sending to the controller. As you can see, it completes in 130ms. Unfortunately you really can't just send CMD1 and go about your business. You need to poll readiness status and keep on sending CMD1 again and again. Also, it is not always 130ms. It tends to vary and worst case we seen was over 300ms. Another one is "kernel read", which is pure IO and takes 132ms. If you invest some 300ms in training the link (has to happen on every boot on every board) to HS400 you can read it in just 10ms. Naturally you can't see HS400 in the picture because enabling it late in the boot flow would be counter productive.
That's essentially the motivation to why we are looking into starting this CMD1 and HS400 link training as early as possible. However fixing this particular issue is just a "per-platform" fix. I was hoping we could come up with a model that adds parallelism as a generic reusable feature not just a quick hack.
Andrey