> On Aug 8, 2018, at 10:31 AM, Rafael Machado > <rafaelrodrigues.mach...@gmail.com> 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 > <rafaelrodrigues.mach...@gmail.com > <mailto:rafaelrodrigues.mach...@gmail.com>> 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 <jiewen....@intel.com > <mailto:jiewen....@intel.com>> 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:rafaelrodrigues.mach...@gmail.com > <mailto:rafaelrodrigues.mach...@gmail.com>] > Sent: Wednesday, August 8, 2018 3:12 AM > To: Laszlo Ersek <ler...@redhat.com <mailto:ler...@redhat.com>> > Cc: Andrew Fish <af...@apple.com <mailto:af...@apple.com>>; Ni, Ruiyu > <ruiyu...@intel.com <mailto:ruiyu...@intel.com>>; edk2-devel@lists.01.org > <mailto:edk2-devel@lists.01.org>; Yao, Jiewen <jiewen....@intel.com > <mailto:jiewen....@intel.com>> > > > 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 <ler...@redhat.com > <mailto:ler...@redhat.com>> 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 edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
