Hi there,
tl;dr: We are considering adding early parallel code execution in coreboot. We need to discuss how this can be done.
Nowadays we see firmware getting more complicated. At the same time CPUs do not necessarily catch up. Furthermore, recent increases in performance can be largely attributed to parallelism and stuffing more cores on die rather than sheer core computing power. However, firmware typically runs on just one CPU and is effectively barred from all the parallelism goodies available to OS software.
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. Interestingly, great deal of tasks that needs to be done are not even computation-bound. They are IO bound. In case of SDHCI below it is possible to train eMMC link to switch from default low-freq single data rate (sdr50) mode to high frequency dual data rate mode (hs400). This link training increases eMMC throughput by factor by 15-20. As result time it takes to load kernel in depthcharge goes down from 130ms to 10ms. However, the training sequence requires constant by frequent CPU attention. As result, it doesn't make any sense to try to turn on higher-frequency modes because you don't get any net win. We also experimented by starting work in current MPinit code. Unfortunately it starts pretty late in the game and we do not have enough parallel time to reap meaningful benefit.
In order to address this problem we can do following things: 1. Add scheduler, early or not 2. Add early MPinit code
For [1] I am aware of one scheduler discussion in 2013, but that was long time ago and things may have moved a bit. I do not want to be a necromancer and reanimate old discussion, but does anybody see it as a useful/viable thing to do?
For [2] we have been working on prototype for Apollolake that does pre-memory MPinit. We've got to a stage where we can run C code on another core before DRAM is up (please do not try that at home, because you'd need custom experimental ucode). However, there are many questions what model to use and how to create infrastructure to run code in parallel in such early stage. Shall we just add "run this (mini) stage on this core" concept? Or shall we add tasklet/worklet structures that would allow code to live in run and when migration to DRAM happens have infrastructure take care of managing context and potentially resume it? One problem is that code running with CAR needs to stop by the time system is ready to tear down CAR and migrate to DRAM. We don't want to delay that by waiting on such task to complete. At the same time, certain task may have largely fluctuating run times so you would want to continue them. It is actually may be possible just to do that, if we use same address space for CAR and DRAM. But come to think of it, this is just a tip of iceberg and there are packs of other issues we would need to deal with.
Does any of that make sense? Perhaps somebody thought of this before? Let's see what may be other ways to deal with this challenge.
thanks Andrey
On 01/25/2017 03:16 PM, Guvendik, Bora wrote:
Port sdhci and mmc driver from depthcharge to coreboot. The purpose is to speed up boot time by starting
storage initialization on another CPU in parallel. On the Apollolake systems we checked, we found that cpu can take
up to 300ms sending CMD1s to HW, so we can avoid this delay by parallelizing.
Why not add this parallelization in the payload instead?
There is potentially more time to parallelize things incoreboot. Payload execution is much faster,
so we don't get much parallel execution time.
- Why not send CMD1 once in coreboot to trigger power-up and let HW
initialize using only 1 cpu?
Jedec spec requires the CPU to keep sending CMD1s whenthe hardware is busy (section 6.4.3). We tested
with real-world hardware and it indeed didn't work witha single CMD1.
Why did you port the driver from depthcharge?
I wanted to use a driver that is proven to avoid bugs.It is also easier to apply patches back and forth.
https://review.coreboot.org/#/c/18105
Thanks
Bora