[coreboot] Add coreboot storage driver

Aaron Durbin adurbin at google.com
Tue Feb 14 17:25:37 CET 2017


On Mon, Feb 13, 2017 at 1:16 PM, Nico Huber <nico.h at gmx.de> 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.
>
>> In order to address this problem we can do following things:
>> 1. Add scheduler, early or not
>
> Yes, but really doesn't fit into the coreboot idea, IMHO.
>
>> 2. Add early MPinit code
>
> No? um, at best very limited (by the number of threads the hardware sup-
> ports).
>
>> 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.
>
> Sounds very scary, as if it would never fit, not matter how strong you
> push. If you really think, we should do something in parallel across
> coreboot stages, it might be time to redesign the whole thing across
> stages.
>
> As long as there is a concept involving romstage/ramstage, we should
> keep it to one thing in romstage: getting DRAM up. If this needs a
> clumsy blob, then accept its time penalty.
>
>>
>> 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.
>
> 3. Design a driver architecture that doesn't suffer from io-waiting
>
> This is something I kept in mind for payloads for some time now, but it
> could also apply to later coreboot stages: Instead of busy waiting for
> i/o, a driver could yield execution until it's called again. Obviously,
> this only helps if there is more than one driver running in "parallel".
> But it scales much better than one virtual core per driver...
>
> Another idea just popped up: Performing "background" tasks in udelay()
> / mdelay() implementations ;)
>
> I guess there are many more, maybe some viable, approaches to solve it
> with only one thread of execution.
>
> Anyway, I rather see this parallelism in payloads. Another thought: If
> there is something in coreboot that really slows booting down, maybe
> that could be moved into the payload?

I don't think things are as simple as that with the current solution
for these platforms. FSP very much complicates things because the
execution context is lost on the transfer. But it's actually worse
than that because resource allocation is dependent on the presence of
PCI devices. If those disappear or appear after resource allocation
then the IO map is not so hot. Things are definitely tightly coupled
so it's not clear to me the answer is to punt everything to a payload
making everything better.

FWIW, I've provided the feedback on FSP and its current deficiencies.
However, FSP does allow one to ship products without having to deal
with UEFI as a solution to the firmware and ensure all the correct
hardware tuning is done since that's the only place Intel supports
documenting/maintaining correct initialization sequences. It's
definitely a predicament if one wants to continue shipping products on
new hardware.

>
> Nico
>
> --
> coreboot mailing list: coreboot at coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot



More information about the coreboot mailing list