Anyway, this is very good!! Good work!! > 28 apr 2015 kl. 09:16 skrev Matt DeVillier <matt.devill...@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:dlau...@chromium.org>dlau...@chromium.org >>> <mailto:dlau...@chromium.org>>: >>> >>> On Mon, Apr 27, 2015 at 12:29 PM, Matt DeVillier < >>> <mailto:matt.devill...@gmail.com>matt.devill...@gmail.com >>> <mailto:matt.devill...@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@coreboot.org <mailto:coreboot@coreboot.org> >>> http://www.coreboot.org/mailman/listinfo/coreboot >>> <http://www.coreboot.org/mailman/listinfo/coreboot> >>> >>> -- >>> coreboot mailing list: coreboot@coreboot.org <mailto:coreboot@coreboot.org> >>> http://www.coreboot.org/mailman/listinfo/coreboot >>> <http://www.coreboot.org/mailman/listinfo/coreboot> >
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
