Open Source BIOS for UP Xtreme (WhiskeyLake, with Intel Core i3-8xxx)

koluchy
koluchy New Member Posts: 3 ✭
edited October 9 in UP Xtreme BIOS

Hello everyone!
Will the firmware built on WhiskeylakeOpenBoardPkg (instructions here: https://github.com/tianocore/edk2-platforms/blob/master/Platform/Intel/Readme.md) work on this platform?
I built a debug version of the image for the UP Xtreme platform (WhiskeylakeOpenBoardPkg) according to this instruction, replaced the BIOS region with a new one (in the full firmware), changed the offsets and sizes of the regions in the descriptor. As a result, in the console I see that the platform boots normally with the "Stage 1" (Minimal Debug) and "Stage 2" (Memory Functional) build options, but when choosing the "Stage 4" (Boot to OS) build option, an ASSERT related to SMM occurs during boot. Previously, before this ASSERT, the console output displayed the message "SMRAM Map Buffer too small" several times, as well as other messages similar to this: "ConvertPages: failed to find range 8C000000 - 8CFFFFFF". But I can't figure out if this is the reason and what to do with these errors. In addition, when selecting the "Stage 3" build option (Boot to UI - Simple console input and output to a UI, UEFI shell), the platform boots further, up to the display of the Tianocore logo and the prompt to press keys to enter the BIOS settings menu or the boot menu. The console shows that we have reached the stage "======== TestPointReadyToBootUefiConsoleVariableFunctional - Exit", but then Warm Reset occurs and then, almost immediately, the system reboots completely, there is no reaction to pressing keys (on the keyboard connected to the USB port). The platform sees the eMMC memory, but somehow strangely - there are errors when working with it. I used Flash with EFI Shell as a boot device.
Sorry for such a long description of the problem).

P.s.: I excluded the following modules from OpenBoardPkg.dsc and OpenBoardPkg.fdf:
"SiliconPolicyInitLib|$(PLATFORM_BOARD_PACKAGE)/FspWrapper/Library/PeiFspPolicyInitLib/PeiFspPolicyInitLib.inf" and
"SiliconPolicyUpdateLib|$(PROJECT)/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiSiliconPolicyUpdateLibFsp.inf,"

because they were even worse. This, as it seemed to me, was due to the fact that they (as I understood) performed a repeated initialization, which had already been performed by FSP. Perhaps this is a mistake, but without these modules, subjectively, it became better)

· Share on FacebookShare on Twitter

Best Answer

Answers

Categories

Privacy Policy