<div dir="ltr"><div><div><div><div><div><div><div><div><div>I have looked into the log. I see that INTEL FSP (for what I know) works correctly. It entered bunch of phases (now there are many, NOT only three). Anyway, scary stuff, directly taken from INTEL BIOS development, and tailored as "FSP" per say.<br><br></div>I also see that MRC passed (there is in total 6 GB of DDR3 memory there), I see that dynamic PCIe discovery worked correctly.<br><br></div>At the end of Coreboot booting, we see the following boot sequence:<br><br>[SPS] SpsFspReadyToBootEvent Start<br>[SPS] Looking for SPS HOB info ..<br>[SPS] HOB: flow 1, feature set 0x9B8106, pwr opt boot 0, cores2disable 0<br>[SPS] SpsFspSendEndOfPost Start<br>[SPS] Sending END_OF_POST to ME<br>[HECI] Send msg: 80040007 00000CFF<br>[HECI]  Got msg: 80080007 00008CFF ...<br>[SPS] SpsFspSendEndOfPost End<br>[SPS] Disabling Global Reset capability<br>[SPS] SpsFspReadyToBootEvent End Success<br><br></div>From my modest knowledge, I see that HECI I/F between ME and Coreboot still works as expected (actually between HECI and FSP embedded in Coreboot, at the end of Coreboot, hidden from Coreboot designers). Also what I see as a non-standard set of features added is SPS addendum, which should be the following:<br></div><span style="color:rgb(255,0,0)"><b><i>SPS -> INTEL Server Platform Services (since Denverton belongs to class of micro servers, as I correctly remember)?! <<== This makes (maybe) some difference from the normal booting!?</i></b></span><br><br></div>And, at the very end, EDKII taking over Coreboot (my best guess from the end of the log):<br><br>NotifyPhaseApi() - End  [Status: 0x00000000]<br>BS: BS_PAYLOAD_LOAD times (us): entry 0 run 1091381 exit 707003<br>COLLECT_TIMESTAMPS: Coreboot took 59501373064 TSC ticks<br>Total booting time : 28.333987 seconds<br><span style="color:rgb(255,0,0)"><i><b>Jumping to boot code at 00800340(7f7c8000) <<== EDKII takes over</b></i></span><br><span style="color:rgb(255,0,0)"><i><b>CPU0: stack: 0012c000 - 0012d000, lowest used address 0012cabc, stack used: 1348 bytes <<== Too low stack value of 4KB (maybe, only one page), seems...</b></i></span><br>entry    = 0x00800340<br>lb_start = 0x00100000<br>lb_size  = 0x000358b0<br>buffer   = 0x7f726000<br>PROGRESS CODE: V03020003 I0<br>Loading PEIM at 0x00000813BA0 EntryPoint=0x00000813EDF CbSupportPeim.efi<br>PROGRESS CODE: V03020002 I0<br>0. 0000000000000000 - 0000000000000FFF [10]<br>1. 0000000000001000 - 000000000009FFFF [01]<br>2. 0000000000100000 - 000000007F791FFF [01]<br>3. 000000007F792000 - 000000007FBFFFFF [10]<br>4. 000000007FC00000 - 000000007FFFFFFF [02]<br>5. 00000000E0000000 - 00000000EFFFFFFF [02]<br>6. 0000000100000000 - 000000017FFFFFFF [01]<br>Low memory 0x7F792000<br>SystemLowMemTop 0x80000000<br>PeiMemBase: 0x7B790000.<br>PeiMemSize: 0x4000000.<br>PeiInstallPeiMemory MemoryBegin 0x7B790000, MemoryLength 0x4000000<br>Found one valid fv : 0x4C000000830000.<br>Install PPI: 49EDB1C1-BF21-4761-BB12-<wbr>EB0031AABB39<br>Notify: PPI Guid: 49EDB1C1-BF21-4761-BB12-<wbr>EB0031AABB39, Peim notify entry point: 802069<br>The 1th FV start address is 0x00000830000, size is 0x004C0000, handle is 0x830000<br><br></div>Melissa,<br><br></div>If bunch of @<a href="http://intel.com" target="_blank">intel.com</a> folks will not help you (they should), you should do the same exercise with 32bit EDKII as payload, and compare tail -100 (last 100 lines of log, where 64bit EDKII fails).<br><br></div>Hope this helps...?!</div><div><br></div><div>Good luck! :-)<br></div>Zoran Stojsavljevic  <br>_______<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 22, 2017 at 8:46 AM, Patrick Georgi via coreboot <span dir="ltr"><<a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">2017-09-22 3:33 GMT+02:00 Melissa Yi <<a href="mailto:huayi@celestica.com">huayi@celestica.com</a>>:<br>
>    Anyone can give some information?<br>
</span>Probably not.<br>
<br>
64bit tianocore as payload should work in general (since it still<br>
comes with a 32bit entry point, just switches to long mode really<br>
early).<br>
It's hard to tell what's going on if the entire report is "doesn't work".<br>
<br>
<br>
Regards,<br>
Patrick Georgi<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org">coreboot@coreboot.org</a><br>
<a href="https://mail.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://mail.coreboot.org/<wbr>mailman/listinfo/coreboot</a><br>
</font></span></blockquote></div><br></div>