Missing MrcCommonConfig.dsc file in EagleStream

[memristor2]

Hello. I was looking into building EagleStream Platfrom after the release of its fsp and druing the build processes I found that inside FSP/EagleStreamFspBinPkg/FspPkgPcdShare.dsc there is this at line 14: !include EaglestreamSiliconPkg/MrcCommonConfig.dsc So where is this package? I think you forgot to add it. It seems that the EaglestreamSiliconPkg directory should be resided inside edk2-platforms/Silicon/Intel (My assumption is simply based upon comparing other platforms) but I guess edk2-platforms hasn't been updated yet

---

Edit: Also there is a typo in the same file line 16: EaglestreamFspBinPkg/DynamicExPcd.dsc "S" in Stream should be capital

[nate-desimone]

@abanejad - Thanks for the catch on the typo! We are working on getting the patch series for edk2-platforms out. It should be available shortly.

[memristor2]

@nate-desimone Thanks for your response. I am also trying to build the IFWI. until now I managed to get the sec phase working until locating the DxeIpl peim. I don't know why am i having this issue. it seems it doesn't return EFI_SUCCESS while locating the peim Status = PeiServicesLocatePpi ( &gEfiDxeIplPpiGuid, 0, NULL, (VOID **)&TempPtr.DxeIpl ); Any thoughts on this? Also would you please make sure the debug macro would work on this platform? I built the IceLake-Sp platform (WhitleyopenboardPkg) and the JunctionCity board even though I had a hard-time getting it running on my platform I eventually did it but no matter what I tried I was't able to get the debug macros working. I suspected that the platform hooking to ast2500 for serial debugging might be the issue. But since I got the IceLake-Sp platform working I didn't bother myself anymore with the debug print macros yet I wish it would work for Sapphire-rapids at the moment. I guess both the IceLake-sp and Sapphire-rapdis would use the same serial library. Anyways either I'd get it working before you release it or I'll just look into the patch in edk2-platforms and seem what changes would it need.

[nate-desimone]

@abanejad - Are you trying to run WhitleyOpenBoardPkg on a Sapphire Rapids system? I would not recommend that if that is what you are doing.

If the EFI_DXE_IPL_PPI isn't found then I would look for 2 things:

1. MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf is included in FvPreMemory.
2. DxeIpl is being loaded by PEI core. This can be an issue if DxeIpl has a dependency that isn't being met.

You are indeed correct that the ast2500 requires a special serial port driver. We have that driver available here: WhitleyOpenBoardPkg/Library/SerialPortLib

If you are trying to run ICX code on a SPR system... then you are missing the new PCH cycle decoding initialization required for the Emitsburg PCH. Which would fully explain why you don't see debug logs.

If you are running on a ICX system... my best guess is for why you don't see debug log output is because of one of two possibilities:

1. ExStatusCodeHandlerPei/PeiCore/DxeMain is not being linked with that instance of SerialPortLib.
2. PeiCore/DxeMain is not using the BaseDebugLibSerialPort.inf instance of DebugLib
3. PcdDebugPropertyMask/PcdFixedDebugPrintErrorLevel are not right. A good example there is WhitleyOpenBoardPkg\Include\Dsc\EnableRichDebugMessages.dsc but note that the !include for that file in PlatformPkg.dsc is commented out by default.

[memristor2]

@nate-desimone Yes I am trying to use WhitleyOpenBoardPkg as a baseline since I don't have much resources to build it from scratch. I think I was misunderstood. The problem isn't locating the DxeIpl and calling it, its finding the ppi's guid inside the Peciore (gEfiDxeIplPpiGuid). I am sure about the fact that it returns EFI_NOT_FOUND after calling PeiServicesLocatePpi. I don't know why this happens I can see the guid both in the build process and when I use UEFITools inside the Ifwi. About your further comments on debug log, I check them out and see what happens. Thank you your help is much appreciated

---

Update: I checked everything needed for the enabling the debug logs. every thing to be at their right place but I still didn't get any output.I checked every pcd, every libraryclass instance. but it didn't work i Still have no idea on this

[memristor2]

I guess this is related to the FSP-M binary. Beacuse I triple checked everything especially the fdf file. I put in the proper base addresses and sizes but i don't know why it couldn't find the gEfiDxeIplPpiGuid. I also checked the PeiCore image inside FSP-M using UEFITools-NE and searched for the guid of gEfiDxeIplPpiGuid I can see it there but I don't know why PeiServicesLocatePpi (which points to the address of PeiLocatePpi) returns EFI_NOT_FOUND. I used the post codes as some sort of debugging method to display on the Dr. Debug 7 segments since I wasn't able to get serial logging enabled inside the PeiLocatePpi and it confirmed my thought that it doesn't find the GUID of gEfiDxeIplPpiGuid I still don't have any idea why this is happening and my best shot is that maybe it's something I don't have any code access to it, (the FSP-M binary).

[nate-desimone]

@abanejad - The issue with the serial port/debug logs is that WhitleyOpenBoardPkg has drivers for the older Lewisburg PCH, whereas Sapphire Rapids uses the new Emitsburg PCH. You need the new Emitsburg PCH drivers. This is necessary since Emitsburg requires different PCH cycle decoding initialization than Lewisburg.

We are working on getting EaglestreamOpenBoardPkg posted on edk2-platforms. This new package will come with said PCH drivers.

With regard to DxeIpl, I suspect DxeIpl is not being executed from some reason. It is likely that it has a dependency that is not being met.

[memristor2]

@nate-desimone Hi Nate, Thanks for the response. I checked everything and also added the pcds from the EagleStream folder to my PlatformPkg.dec adf checked every dependency. I guess everything was alright but yet couldn't solve my problem. I guess I am going to give up on this... since I don't know what else could be done until the patch would be released. I'll keep this issue open though so if I manage to get it working I'll update this thread. Thank you for your time.

[memristor2]

@nate-desimone Hello again, so after some time and checking back and forth I found out I had the assert debug macro off I set it and realized that inside the PeiMain.c the system gets stuck at this point

 if (PrivateData.HobList.HandoffInformationTable->BootMode != BOOT_ON_S3_RESUME) {
    //
    // Check if InstallPeiMemory service was called on non-S3 resume boot path.
    //
    ASSERT (PrivateData.PeiMemoryInstalled == TRUE);
  } 

it seems that the memory doesn't get installed and the PeiMemoryInstalled flag doesn't set to true. Could you help me and point me to the right direction to see what makes this to happen?

[memristor2]

So the reason causing the issue was that I was trying to use FSP dispatch mode for booting I switched to API mode and the FspmWrapperPeim successfully installed the memory and I managed to get the platform load the DXE phase.