I'm using the defaults from the (now deleted) 2ndstage sample dsc: gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIMemoryNVS|0 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiReservedMemoryType|0 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData|50 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode|20 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiBootServicesCode|400 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiBootServicesData|20000 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiLoaderCode|20 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiLoaderData|0
I figured that the PrePi's stack setup may cause this, especially since I'm using all the memory up to 0xFFFFFFFF+1 which causes the logic to ignore the last page(I think). I'm now using PcdSystemMemorySize - PcdFdSize - EFI_PAGE_SIZE which seems to work pretty good even though the "missing" memory was just like 900bytes and not 4096. Thanks Michael On Mon, Aug 8, 2016 at 10:50 AM, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > On 6 August 2016 at 13:05, Michael Zimmermann <sigmaepsilo...@gmail.com> > wrote: > > Hi, > > > > I have some problems with my current setup and would like to ask you for > the > > best way to configure the following setup: > > - I'm using PrePi, I don't need relocations because the loading address > is > > fixed(0xfe000000) > > - The SystemMemory address range is unknown at compile time > > - the system-memory consists of multiple ranges with holes so providing > just > > a base and a size is not enough > > - There's no NOR, edk2 gets loaded into dram > > > > my current setup: > > PcdSystemMemoryBase = loading addr(0xfe000000) > > PcdSystemMemorySize = 32MB > > FD_BASE = PcdSystemMemoryBase > > FD_SIZE = 4MB > > in ArmPlatformGetVirtualMemoryMap I call BuildResourceDescriptorHob for > all > > DRAM memory ranges. > > In PrePiMain after MemoryPeim I call BuildMemoryAllocationHob for some > > reserved memory ranges > > > > After running into out-of-memory errors during PrePi when using bigger > FV's > > I revisited everything and came across a PCD I somehow never looked at > when > > setting up my platform a year ago: PcdSystemMemoryUefiRegionSize. > > this was hardcoded to 0x00e00000 which obviously caused allocation errors > > while extracting big FV's even though PcdSystemMemorySize was big enough. > > > > Since there already was this nice comment 'PcdSystemMemorySize - > PcdFdSize' > > I did exactly that: 32MB-4MB = 28MB. > > Unfortunately after doing that MdeModulePkg/Core/Dxe/Gcd/Gcd.c starts > > bugging that he can't find a resource hob that contains the PHIT Hob. > > > > Could you check the > > gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiXXX|nnnn > > definitions in your .DSC? Fairly recently, the core code was modified > to use the sum of these definitions as an estimate of the minimally > required allocation size, and it broke some other platforms in a > similar way. > > > So now that my setup and problems are clear, the questions: > > - Is it ok to define ResourceHob's that cover the PcdSystemMemory range? > > - what can I do to fix the PHIT Hob problem? should PcdFdSize + > > PcdSystemMemoryUefiRegionSize be smaller than PcdSystemMemorySize ? > > - I took a quick look at ArmVirt where they change the PcdSystemMemory > range > > at runtime, but they use lots of custom code like their own MemoryPeiLib, > > and I think everything but Xen uses PEIM instead of PrePi. Also as I > said I > > have more than one range so this would work anyway. > > > > ArmVirtQemu uses PEIM, since it runs from [emulated] NOR flash. > ArmVirtQemuKernel and ArmVirtXen use PrePi (the former is simply > ArmVirtQemu with the FD executing from DRAM, using the QEMU '-kernel' > option) > _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
