[coreboot] Google Panther: coreboot has to wait for Intel’s ME (Management Engine)

[Berth-Olof Bergman]

Anyway, this is very good!! Good work!!

> 28 apr 2015 kl. 09:16 skrev Matt DeVillier <matt.devillier at gmail.com>:
> 
> On 4/28/2015 1:22 AM, Berth-Olof Bergman wrote:
>> That’s truly amazing! So the FSP + coreboot part only takes a quarter of a second? Intel FSP must be on steroids!!
>> 
>> The total boot time is the sum of components time, so if you fix that problem you will have close to a quarter of second boot time!! Can we see a video clip of that boot?
> 
> well, that doesn't count the execution of the payload, which in this case also includes the execution of the VGA option rom, so it's still close to 2.5s from the time the power button is pressed until the system actually boots.  Also, Panther doesn't use FSP.
> 
>> 
>>> 27 apr 2015 kl. 22:42 skrev Duncan Laurie < <mailto:dlaurie at chromium.org>dlaurie at chromium.org <mailto:dlaurie at chromium.org>>:
>>> 
>>> On Mon, Apr 27, 2015 at 12:29 PM, Matt DeVillier < <mailto:matt.devillier at gmail.com>matt.devillier at gmail.com <mailto:matt.devillier at gmail.com>> wrote:
>>> On 4/26/2015 3:03 AM, Paul Menzel wrote:
>>>> Dear coreboot folks,
>>>> 
>>>> 
>>>> looking at the time stamps of the Intel Haswell device Google Panther,
>>>> which Matt DeVillier thankfully uploaded to the board status repository
>>>> [1], it looks odd that it took around a quarter of a second, from after
>>>> the SeaBIOS payload was decompressed to starting the payload. This is
>>>> almost half of the whole boot time.
>>>> 
>>>>         […]
>>>>           90:load payload                                      233,302 (216)
>>>>           15:starting LZMA decompress (ignore for x86)         233,415 (113)
>>>>           16:finished LZMA decompress (ignore for x86)         250,327 (16,912)
>>>>           99:selfboot jump                                     493,712 (243,384)
>>>> 
>>>> Thanks to Aaron Durbin’s analysis of the code path, the finalize in line
>>>> 138 of `src/southbridge/intel/lynxpoint/smi.c` calls
>>>> `intel_me_mbp_clear()` in line 589 of
>>>> `src/southbridge/intel/lynxpoint/me_9.x.c`.
>>>> 
>>>>         $ more src/southbridge/intel/lynxpoint/me_9.x.c # line 589
>>>>         […]
>>>>         #if CONFIG_ME_MBP_CLEAR_LATE
>>>>         	/* Wait for ME MBP Cleared indicator */
>>>>         	intel_me_mbp_clear(PCH_ME_DEV);
>>>>         #endif
>>>>         […]
>>>> 
>>>> The issue is even described in the Kconfig option description of
>>>> `ME_MBP_CLEAR_LATE` and the commit message of commit 3d299c4b (lynxpoint
>>>> me: add support for mbp clear wait in finalize step) [2] adding this
>>>> option.
>>>> 
>>>>         $ more src/southbridge/intel/lynxpoint/Kconfig
>>>>         […]
>>>>         config ME_MBP_CLEAR_LATE
>>>>         	bool "Defer wait for ME MBP Cleared"
>>>>         	default y
>>>>         	help
>>>>         	  If you set this option to y, the Management Engine driver
>>>>         	  will defer waiting for the MBP Cleared indicator until the
>>>>         	  finalize step.  This can speed up boot time if the ME takes
>>>>         	  a long time to indicate this status.
>>>>         […]
>>>> 
>>>> I guess there is no way to get fixed ME BLOBs from Intel. I heard the ME
>>>> BLOB has been fixed for newer Intel devices.
>>> 
>>> The ME firmware that ships with Panther is 9.5.13.1706.  I've also tested 9.5.41.1904 (what I'm using in the firmware referenced above) and 9.5.45.1922 (which I just came across today) - all display the same behavior in terms of time needed to report MBP cleared.  The 9.6 series ME firmware is also for Haswell/Lynxpoint, but I'm unsure if it's compatible with systems shipped with ME 9.5.  Since I have an external programmer, I suppose I could always give it a try :)  The 10.0 series ME firmware is for Broadwell and is more likely to contain the fix, but less likely to be compatible with Haswell/LP.
>>> 
>>> -Matt
>>> 
>>> 
>>> 
>>> 
>>> Unfortunately the wait for ME MBP to clear is even worse on Broadwell, but with ME10 there is a (gross) boot flow to avoid it thanks to some new commands that do not need acknowledgement:
>>> 
>>> http://review.coreboot.org/gitweb?p=coreboot.git;a=commit;h=c99681f4f23ddacd64fddbedf060f6443d008090 <http://review.coreboot.org/gitweb?p=coreboot.git;a=commit;h=c99681f4f23ddacd64fddbedf060f6443d008090>
>>> 
>>> -duncan
>>>  
>>>> Thanks,
>>>> 
>>>> Paul
>>>> 
>>>> 
>>>> [1] http://review.coreboot.org/gitweb?p=board-status.git;a=commitdiff;h=3926f95b143b74c0762516df0bdf250c1dd8ba32#patch4 <http://review.coreboot.org/gitweb?p=board-status.git;a=commitdiff;h=3926f95b143b74c0762516df0bdf250c1dd8ba32#patch4>
>>>> [2] http://review.coreboot.org/4375 <http://review.coreboot.org/4375>
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> coreboot mailing list: coreboot at coreboot.org <mailto:coreboot at coreboot.org>
>>> http://www.coreboot.org/mailman/listinfo/coreboot <http://www.coreboot.org/mailman/listinfo/coreboot>
>>> 
>>> -- 
>>> coreboot mailing list: coreboot at coreboot.org <mailto:coreboot at coreboot.org>
>>> http://www.coreboot.org/mailman/listinfo/coreboot <http://www.coreboot.org/mailman/listinfo/coreboot>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150428/81862be2/attachment.html>