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

[Zoran Stojsavljevic]

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 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]
1. 0000000000001000 - 000000000009FFFF [01]
2. 0000000000100000 - 000000007F791FFF [01]
3. 000000007F792000 - 000000007FBFFFFF [10]
4. 000000007FC00000 - 000000007FFFFFFF [02]
5. 00000000E0000000 - 00000000EFFFFFFF [02]
6. 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