[coreboot] Add coreboot storage driver

Zoran Stojsavljevic zoran.stojsavljevic at gmail.com
Tue Feb 14 09:10:28 CET 2017


Hello Andrey,

I found that Coreboot really implements atomic and semaphores operations?!
What for? Did not expect to find these... At all???

The ONLY reason why, is that in some SoCs are going some independent
(invisible) HW threads using the same resources as BSP core (all other
cores should be waiting on some SIPI event). I do NOT see any other
reason(s) for them to be used. No multi-threading in Coreboot, just single
thread continuously/sequentially executing correct?

Why not BIOS? There are 100s of millions of PCs, notebooks etc. out there,
and these are slow with BIOS. You can argue and tell: IOTG will soon have
billions of smart devices using SoCs. Valid point.

In the sense, I have another idea for INTEL SoCs/CPUs, as HW architecture
improvement. Why your top-notch HW guys do NOT implement MRC as part of
MCU. Some HW thread inside CPU/SoC should execute MCU, shouldn't it? MRCs
should be few K in size, and they can perfectly fit in there, thus MRC
should be (my take on this) part of internal CPU architecture.

Today's INTEL COREs and ATOMs have at least/minimum 100M gates, why not to
add couple of dozen K more? Lot of problems solved, don't they? ;-)
[1] BOOT stage to be much shorter (no anything such as CAR phase);
[2] ROM stage does not exist;
[3] IP preserved in HW, so the whole INTEL FSP is actually (imagine the
Beauty) Open Source...

Just $.02 in addition to original $.02 (makes it nickel - $.01). :-)

Zoran

On Mon, Feb 13, 2017 at 7:08 PM, Andrey Petrov <andrey.petrov at intel.com>
wrote:

> Hi,
>
> On 02/13/2017 12:21 AM, Zoran Stojsavljevic wrote:
>
> IBVs can work on this proposal, and see how BIOS boot-up time will improve
>> (by this parallelism)
>>
>
> There is no need to wait for anybody to see real-world benefits.
>
> The original patch where you train eMMC link already saves some 50ms.
> However MP init kicks in very late. That is a limitation of current
> approach where MPinit depends on DRAM to be available. If you move mpinit
> earlier, you can already get approx 200ms saving. On Apollolake we have a
> prototype where MPinit happens in bootblock. That already reduces boot time
> by some 200ms.
>
> Since, very soon, you'll run to shared HW resource, and then you'll need
>> to implement semaphores, atomic operations and God knows what!?
>>
>
> Fortunately, divine powers have nothing to do with it. Atomic operations
> are already implemented and spinlocks are in as well.
>
> What other major issues you see, Zoran?
>
> thanks
> Andrey
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20170214/070732af/attachment.html>


More information about the coreboot mailing list