From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id B79861A1E18 for ; Mon, 8 Aug 2016 02:18:41 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id i5so125140336wmg.0 for ; Mon, 08 Aug 2016 02:18:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Jr5VwupqCME7ygtwO3hUW+aB5k+SLZRLOScPUDSJhng=; b=Y4lQRenC89owEJjcYynUutmQOEIKjcDVPGcjNAGA6LqdojSpQa+fSIVrii6drHwFsj DCsng/KDTjtltWZtMJeOr8D3p/GG0KVv36m/835FfeGzpW/+hjGLzaOOj6B80JB3zZqO SS9AWP50lA4xfZ/U0xvyjqk4u8sKvhkBvsqfJUIvvkj4kUKdt+MroZ0tJ/awn5rcJVvi AQiaZ7SJ04CnF5TGNVO4/iQSvSR0KHoAFciumENTzJJU1Bz7qqzywFB3AIUL9qm27AWx UbfB5KuIeNvnd8ovMJCHTwaXqS517jB+KDiIHuojnoiY1GNiV949WhPz/Vtkw4sCyYLl 420A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Jr5VwupqCME7ygtwO3hUW+aB5k+SLZRLOScPUDSJhng=; b=KuR/8TeRgTLxA0IZ6yysUSKpz3Y35kGRTTEEUelmqUjJRBfyN11bKgl2eQrrQGNBmK wfZZjsWpxt3heMVhzQU+woZ+XoCB6boMVa3oHJoxTdscbSuWuveCIxVhFbh+2tVxxEs8 Wt1qlIKTnBpFkj94LZvkZjxNEqvQF9V7Jnqu0pvqJlNnYuqK3kLZfxrgylHE4XtlGLru txbh3d5xi34d+9Qeegqv9n1owDSVWmmcbsn5YpD7TbPLvotUb99fe77/r2WSZ5qKej0n DM49JgKfbFuKGE55nwpk5gh9bmF/Q2NeE/QlY9dgzmtz1EURqdQ/MUZ+J6hrmS+k/TnL YwCw== X-Gm-Message-State: AEkooutqRUNiIDIA4DiKFD+jt6f3vnnrbG9nubegCiSTOJ4XusRS3bI6J7J6oXQ6/F8P4YKOKvrrcu0ZN5TQzQ== X-Received: by 10.28.30.1 with SMTP id e1mr15710711wme.77.1470647920307; Mon, 08 Aug 2016 02:18:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.238.198 with HTTP; Mon, 8 Aug 2016 02:18:39 -0700 (PDT) In-Reply-To: References: From: Michael Zimmermann Date: Mon, 8 Aug 2016 11:18:39 +0200 Message-ID: To: Ard Biesheuvel Cc: edk2-devel-01 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 Subject: Re: ARM PrePI Memory setup recommendations X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 09:18:42 -0000 Content-Type: text/plain; charset=UTF-8 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 wrote: > On 6 August 2016 at 13:05, Michael Zimmermann > 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) >