Re: [coreboot] 64 UEFI payload boot fail on Denverton platform but 32 UEFI payload works

[Melissa Yi]

Hi
  The 32bit build log is attached, the log is too big so I compressed it. I
didn't find out some important information between them.
  I will contact Intel team directly, thanks for your help.

Thanks.

Regards,
Melissa Yi

2017-09-22 15:25 GMT+08:00 Zoran Stojsavljevic <
[e-mail]>:
> 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.
>
> I also see that MRC passed (there is in total 6 GB of DDR3 memory there),
> I see that dynamic PCIe discovery worked correctly.
>
> At the end of Coreboot booting, we see the following boot sequence:
>
> [SPS] SpsFspReadyToBootEvent Start
> [SPS] Looking for SPS HOB info ..
> [SPS] HOB: flow 1, feature set 0x9B8106, pwr opt boot 0, cores2disable 0
> [SPS] SpsFspSendEndOfPost Start
> [SPS] Sending END_OF_POST to ME
> [HECI] Send msg: 80040007 00000CFF
> [HECI]  Got msg: 80080007 00008CFF ...
> [SPS] SpsFspSendEndOfPost End
> [SPS] Disabling Global Reset capability
> [SPS] SpsFspReadyToBootEvent End Success
>
> 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:
> *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!?*
>
> And, at the very end, EDKII taking over Coreboot (my best guess from the
> end of the log):
>
> NotifyPhaseApi() - End  [Status: 0x00000000]
> BS: BS_PAYLOAD_LOAD times (us): entry 0 run 1091381 exit 707003
> COLLECT_TIMESTAMPS: Coreboot took 59501373064 <0595%200137%203064> TSC
> ticks
> Total booting time : 28.333987 seconds
> *Jumping to boot code at 00800340(7f7c8000) <<== EDKII takes over*
> *CPU0: stack: 0012c000 - 0012d000, lowest used address 0012cabc, stack
> used: 1348 bytes <<== Too low stack value of 4KB (maybe, only one page),
> seems...*
> entry    = 0x00800340
> lb_start = 0x00100000
> lb_size  = 0x000358b0
> buffer   = 0x7f726000
> PROGRESS CODE: V03020003 I0
> Loading PEIM at 0x00000813BA0 EntryPoint=0x00000813EDF CbSupportPeim.efi
> PROGRESS CODE: V03020002 I0
> 0. 0000000000000000 - 0000000000000FFF [10]
> 0000000000001000 - 000000000009FFFF [01]
> 0000000000100000 - 000000007F791FFF [01]
> 000000007F792000 - 000000007FBFFFFF [10]
> 000000007FC00000 - 000000007FFFFFFF [02]
> 00000000E0000000 - 00000000EFFFFFFF [02]
> 0000000100000000 - 000000017FFFFFFF [01]
>
> Low memory 0x7F792000
> SystemLowMemTop 0x80000000
> PeiMemBase: 0x7B790000.
> PeiMemSize: 0x4000000.
> PeiInstallPeiMemory MemoryBegin 0x7B790000, MemoryLength 0x4000000
> Found one valid fv : 0x4C000000830000.
> Install PPI: 49EDB1C1-BF21-4761-BB12-EB0031AABB39
> Notify: PPI Guid: 49EDB1C1-BF21-4761-BB12-EB0031AABB39, Peim notify entry
> point: 802069
> The 1th FV start address is 0x00000830000, size is 0x004C0000, handle is
> 0x830000
>
> Melissa,
>
> If bunch of @intel.com 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).
>
> Hope this helps...?!
>
> Good luck! :-)
> Zoran Stojsavljevic
> _______
>
> On Fri, Sep 22, 2017 at 8:46 AM, Patrick Georgi via coreboot <
> [e-mail]> wrote:
> > 2017-09-22 3:33 GMT+02:00 Melissa Yi :
> > > Anyone can give some information?
> >
> > Probably not.
> >
> > 64bit tianocore as payload should work in general (since it still
> > comes with a 32bit entry point, just switches to long mode really
> > early).
> > It's hard to tell what's going on if the entire report is "doesn't work".
> >
> > Regards,
> > Patrick Georgi