Hi Andrew. Thanks for the clarification!
Rafael Em qua, 8 de ago de 2018 às 16:14, Andrew Fish <[email protected]> escreveu: > > On Aug 8, 2018, at 10:31 AM, Rafael Machado < > [email protected]> wrote: > > Hi everyone > > One question that was not answered and that could help us, is about > skipping the MemoryTypeInfo variable usage. > Is there any way to do this skip at a UEFI App ? > Simple erasing the MemoryTypeInfo var seems a little to violent from our > perspective. What do you think? > > Seems the system we're having this problem has some inconsistency when > filling the MemoryTypeInfo var before exiting the previous boot, and > seems to consider the BootServices memory type also to be stored at the > var. Does anyone remember of this kind of issue on some system in the past? > > > No we do that all the time to remove fragmentation from the memory map and > it does not > > Thanks, > > Andrew Fish > > Thanks and Regards > Rafael > > Em qua, 8 de ago de 2018 às 08:55, Rafael Machado < > [email protected]> escreveu: > >> Hi Jiewen >> >> Thanks for highlighting this. >> Just checked and we just add the Reserved/Acpi/Runtime types. >> >> Seems the guess that this would be related to the MemoryTypeInfo var is >> not the correct way to follow. >> >> We'll keep working on it, maybe asking more questions to the community in >> future. >> Thank you all for the help and guidance! >> In case someone has any comment or idea, please feel free to share. >> >> Rafael >> >> >> >> Em ter, 7 de ago de 2018 às 19:42, Yao, Jiewen <[email protected]> >> escreveu: >> >>> Hi >>> >>> It is unclear to me that which type you have put to MemoryTypeInfo table. >>> >>> >>> >>> By design, we only need put Reserved/Acpi/Runtime, which should be quite >>> small. >>> >>> >>> >>> Do you put any other type into MemoryTypeInfo table? >>> >>> >>> >>> Thank you >>> >>> Yao Jiewen >>> >>> >>> >>> *From:* Rafael Machado [mailto:[email protected]] >>> *Sent:* Wednesday, August 8, 2018 3:12 AM >>> *To:* Laszlo Ersek <[email protected]> >>> *Cc:* Andrew Fish <[email protected]>; Ni, Ruiyu <[email protected]>; >>> [email protected]; Yao, Jiewen <[email protected]> >>> >>> >>> *Subject:* Re: [edk2] Question about memory map entries >>> >>> >>> >>> Hi everyone >>> >>> >>> >>> Based on the information shared by the members, the understanding is >>> that the current state of the system may impact fuutre boots. >>> >>> The problem is that in my case, due to specific requirements, before >>> booting we need to stress the system's memory, allocating a big amount of >>> memory and doing some memory validation algorithms. >>> >>> So the high number of allocations and frees is by choice and not by >>> mistakes. >>> >>> >>> >>> Considering this. Is there any way to bypass the MemoryTypeInformation >>> var store actions? >>> >>> >>> >>> Thanks and Regards >>> >>> Rafael >>> >>> >>> >>> Em qui, 2 de ago de 2018 às 17:39, Laszlo Ersek <[email protected]> >>> escreveu: >>> >>> On 08/02/18 21:18, Rafael Machado wrote: >>> > Just found something interesting. >>> > Based on the logs from the serial port. >>> > >>> > This system works fine: >>> > >>> > "PeiInstallPeiMemory MemoryBegin 0x93D50000, MemoryLength 0xA2B0000 >>> > Temp Stack : BaseAddress=0x400000 Length=0x80000 >>> > Temp Heap : BaseAddress=0x480000 Length=0x80000 >>> > Total temporary memory: 1048576 bytes. >>> > temporary memory stack ever used: 524288 bytes. >>> > temporary memory heap used: 63304 bytes. >>> > Old Stack size 524288, New stack size 524288 >>> > Stack Hob: BaseAddress=0x93D50000 Length=0x80000 >>> > Heap Offset = 0x93950000 Stack Offset = 0x93950000 >>> > Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi" >>> > ... >>> > "CoreInitializeMemoryServices: >>> > BaseAddress - 0x93DE1000 Length - 0x8135000 MinimalMemorySizeNeeded - >>> > 0x5AC0000" >>> > >>> > This one is bricked: >>> > >>> > "PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9D637000 >>> > Temp Stack : BaseAddress=0x400000 Length=0x80000 >>> > Temp Heap : BaseAddress=0x480000 Length=0x80000 >>> > Total temporary memory: 1048576 bytes. >>> > temporary memory stack ever used: 524288 bytes. >>> > temporary memory heap used: 63304 bytes. >>> > Old Stack size 524288, New stack size 524288 >>> > Stack Hob: BaseAddress=0x9C9000 Length=0x80000 >>> > Heap Offset = 0x5C9000 Stack Offset = 0x5C9000 >>> > Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi" >>> > ... >>> > "CoreInitializeMemoryServices: >>> > BaseAddress - 0x0 Length - 0x0 MinimalMemorySizeNeeded - 0x98E47000 >>> > " >>> > ... >>> > "ASSERT_EFI_ERROR (Status = Out of Resources) >>> > ASSERT [DxeCore] ...\MdeModulePkg\Core\Dxe\DxeMain\DxeMain.c(299): >>> > !EFI_ERROR (Status) >>> > AllocatePoolPages: failed to allocate 1 pages >>> > AllocatePool: failed to allocate 120 bytes" >>> >>> The location and the size of the permanent PEI RAM are extremely >>> different between the two cases. >>> >>> - Functional system: >>> >>> PeiInstallPeiMemory MemoryBegin 0x93D50000, MemoryLength 0xA2B0000 >>> >>> Base address is ~2365 MB, size is ~162 MB >>> >>> - Unbootable system: >>> >>> PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9D637000 >>> >>> Base address is ~9 MB, size is ~2518 MB >>> >>> The numbers in the second (unbootable) case look very unusual to me. The >>> permanent PEI RAM is usually tens or (maybe) hundreds of megabytes in >>> size, and tends to start much higher (usually as high as possible under >>> 4GB, on x86 anyway). >>> >>> >>> Consult the following sections in the PI spec (v1.6), volume 3: >>> >>> - 4.3 Example HOB Producer Phase Memory Map and Usage >>> - 5.3 PHIT HOB >>> >>> The CoreInitializeMemoryServices() function searches the HOB list for a >>> tested system memory "Resource Descriptor HOB that contains PHIT range >>> EfiFreeMemoryBottom..EfiFreeMemoryTop". (Quoted a comment from the code.) >>> >>> Basically, the function locates the system RAM HOB that contains the >>> free permanent PEI RAM. >>> >>> If the search fails, then we trip an ASSERT(). This does not happen in >>> your case, the search succeeds. >>> >>> If the search succeeds, then the DXE core will try to initialize itself >>> in one of three locations in the RAM area defined by that HOB. In >>> descending preference order: above the permanent PEI RAM, within the >>> free permanent PEI RAM, and below the permanent PEI RAM. >>> >>> There is also a fallback (a fourth option) when even the third one from >>> before proves too small -- the function will then search again for a >>> memory descriptor HOB, top-down, avoiding the one HOB that it found >>> earlier to contain the permanent PEI RAM (because, all three options for >>> that have already failed, see above). >>> >>> As the result of this search, your broken system finishes with: >>> >>> BaseAddress - 0x0 Length - 0x0 MinimalMemorySizeNeeded - 0x98E47000 >>> >>> "MinimalMemorySizeNeeded" includes the previous measurements from >>> MemoryTypeInformation, and the concrete value is very strange -- it >>> seems to imply that you need ~2446 MB for initializing the DXE core. >>> It's not surprising that the function cannot fit that anywhere, in >>> either of the four options described above. >>> >>> If your system has more (high) RAM to spare, try to install a resource >>> descriptor HOB for it. Then the fourth option might succeed. >>> >>> Honestly though, those permanent PEI RAM values (base address at ~9 MB, >>> size ~2518 MB) look super fishy to me in the first place. Something must >>> be wrong in the PEI phase with the calculation of those parameters. >>> Possibly, the memory resource descriptor HOBs could be wrong too. >>> >>> >>> ... Considering commit 3a05b13106d1 ("MdeModulePkg DxeCore: Take the >>> range in resource HOB for PHIT as higher priority", 2015-09-18), it >>> writes, >>> >>> "Also let the minimal memory size needed include the total memory bin >>> size needed to make sure memory bin could be allocated successfully." >>> >>> This is the reason "MinimalMemorySizeNeeded" includes >>> MemoryTypeInformation. Normally, MemoryTypeInformation tracks long-term >>> maximums that are necessary for booting an OS without memory map >>> fragmentation (including S4 resume). However, if you have a UEFI >>> application that allocates huge amounts of memory, and then *doesn't* >>> boot an OS, then it could invalidate MemoryTypeInformation. Because, the >>> maximums that MemoryTypeInformation represents, no longer reflect >>> requirements for booting an OS. In that case, the >>> "MinimalMemorySizeNeeded" assumption (from commit 3a05b13106d1), for >>> initializing the DXE core, could be invalid too. >>> >>> Thanks >>> Laszlo >>> >>> _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
