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@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