Sorry for the late response to this thread... PEI has grown greatly in complexity, as Andrew pointed out. Do we (TianoCore community) think it's time to add a real pool manager to PEI?  There's getting to be quite a bit of post-DRAM-initialization PEI code on some platforms.  And really, having a limited amount of pre-DRAM memory available is an even better reason for having an effective pool allocator, so the memory can be freed and reused. FWIW we (HPE) needed to add a private pool allocator to manage memory for a proprietary h/w initialization module which needs to run in post-DRAM PEI, and depends on allocating and freeing memory in different phases of its operation. Brian J. Johnson ------------------------------------------------------------------------ *From:* Ayush Singh [mailto:ayushdevel1325@gmail.com] *Sent:* Friday, June 10, 2022, 12:22 AM *To:* Andrew Fish *Cc:* devel@edk2.groups.io *Subject:* [edk2-devel] Clarification of Memory management in PEI phase > Thanks for the wonderful answer. > > Ayush Singh > > On Thu, Jun 9 2022 at 01:26:58 PM -0700, Andrew Fish > wrote: >> >> On Jun 9, 2022, at 10:28 AM, Ayush Singh >> > me with understanding dynamic memory management in PEI phase? In >> the UEFI Platform Integration Specification, version 1.7 Errata >> A, Section 4.6, PEI Memory services are given which include: 1. >> InstallPeiMemory() >> >> This is basically: (*PeiServices)->InstallPeiMemory (PeiServices, >> MemoryBegin, MemoryLength); This is how you tell the PEI Core the >> location of the memory that will can be used in PEI. >> >> 2. AllocatePages() 3. AllocatePool() 4. CopyMem() 5. SetMem() 6. >> FreePages() However, no `FreePool()` service seems to be present. >> So how is the memory allocated using `AllocatePool()` freed? >> >> It basically gets Freed when you transition to the DXE phase. To step >> back for a minute I think it is important to remember that the main >> job of PEI is to initialize DRAM, and deal with S3 (resuming from >> suspend to RAM). So as soon as you have DRAM you are kind done and >> ready for the DXE IPL so you can load the DXE Phase and start up EFI. >> Remember PEI is Pre EFI. The reality is programming DRAM is complex >> and lots of code got written, then lots more code got written and PEI >> has become large for some ports. That was never the intent. PEI is >> designed as a way to run C code when you code is running from ROM and >> you donā��t have any DRAM. For x86 not having DRAM means you are >> using the cache as RAM. For some SoCs there is actually an SRAM you >> can use. Thus the PEI memory allocation scheme is designed to deal >> with this very constrained environment. You start PEI with a heap and >> stack. You can also allocate HOBs (Hand Off Blocks). A pool >> allocation in PEI is just a HOB. See [1]. There is no way to free a >> HOB. So the AllocatePool() kind of leaks into DXE too as an entry in >> the HOB list. But when the OS called gBS->ExitBootServices() that >> frees all non runtime memory back to the OS. If you look a >> AllocatePages/FreePages you will see AllocatePages creates a HOB that >> points to the memory region, and FreePages just marks that HOB as not >> used. That code is also in this file [1]. TL;DR there is no pool >> manager in PEI. [1] >> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pei/Memory/MemoryServices.c#L878 >> Thanks, Andrew Fish >> >> Ayush Singh >> > Brian ------------------------------------------------------------------------------------------------------------------------------ "It's OK to be stuck. 99% of the time in your own [research] work, you're stuck." -- Mark Lawrence