From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-x241.google.com (mail-vk0-x241.google.com [IPv6:2607:f8b0:400c:c05::241]) (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 85C8081C8D for ; Wed, 14 Dec 2016 21:02:04 -0800 (PST) Received: by mail-vk0-x241.google.com with SMTP id w194so6648880vkw.3 for ; Wed, 14 Dec 2016 21:02:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ojv5O5qTjAcyQrOvFWJxQInfzfMCsUx8R/XNWsXR96Y=; b=NsnDSmPGDMF/ColLC6nWSmlVjQPRQl4WaUCWXKorCEyiJpvslkrRwRmMDXuJdrX0N2 Y2yuqaAcLcrjvnEa4osm+VeqsecoywH5r1Zdr1XTfBhku5nyMvvN3XDO774esV8pKVEV NKNPWtXYw0TrVeuMcIhgSyFJguMzUeE9e3u/PI03ZO2bssJ0gNT560xxfFxjZYnwXsr/ sH7b5jSQCmOgMMXESQSWX1QrNVx0I8KU1ihVmZRWLHiBy7iGd+wG8BBo/LRCxEjMADAU 6BkAEFffDLNUVEjMpwDPPh+4QeU9zgcvqwZMuTBujKr4uZbn50b0m2j30bv8eGjhSCIK bYnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ojv5O5qTjAcyQrOvFWJxQInfzfMCsUx8R/XNWsXR96Y=; b=W9oRRsE/8iV7qNP7HJChdNIJqtwdSvYj+IRm6FtEK11atQ12WNNwxKXzaoJyvjwYNw ZFKI7CMkqEzIV5sGjsR4xtIyxZuanAumYMsGu5g9OPYrhZy6VaqKgdA0tkZURckL9sys vN+d7IRxV77EsrkKS6YuwgM2HLyJSnROC1Pp1bWgaoflyCEygdy5606kSvVbaXDdo/l+ 4jKB3PB6jw9j9IFmt3jvpIt6fYBCRPwav9acxYVUwmMDwczh8unSEQ7wiYssagEbim45 Uj4HqfxtfB6RvbUKOwwdjaxaDATvltuVWmiNzTtGdJa2aPgnQIddCMa3EjUJxeeqih9A dFQg== X-Gm-Message-State: AKaTC01/O+BAiA4R2ux878Elrpx1BIqF9ncdRC2maj2U++gBBAAUTkXYCnsBQ15bwFSOgwBCqhcgsTNLmekoKQ== X-Received: by 10.176.67.132 with SMTP id l4mr314616ual.164.1481778123070; Wed, 14 Dec 2016 21:02:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.34.2 with HTTP; Wed, 14 Dec 2016 21:02:02 -0800 (PST) In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14D6A55EE@SHSMSX104.ccr.corp.intel.com> References: <4A89E2EF3DFEDB4C8BFDE51014F606A14D6A55EE@SHSMSX104.ccr.corp.intel.com> From: Michael Zimmermann Date: Thu, 15 Dec 2016 06:02:02 +0100 Message-ID: To: "Gao, Liming" Cc: Ard Biesheuvel , "edk2-devel@lists.01.org" , Star Zeng , Feng Tian Subject: Re: correct way to reserve memory from PrePi? 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: Thu, 15 Dec 2016 05:02:04 -0000 Content-Type: text/plain; charset=UTF-8 I do not want to allocate the full memory range, just small parts of it. I have one or two ranges(depending on how the system config reports it) for all ram. e.g a 2gb device usually uses either 0x0000000-0x80000000 or 0x00000000-0x40000000 and 0x40000000-0x40000000. So I digged even further and it looks like upon boot, the highest available memory resource descriptor is selected and allocated for the DxeCore. So if I have one memory resource only, the whole DRAM will be allocated by/for DxeCore. Is that really the intended behavior? Because this way I'm unable to reserve any RAM from the highest resource descriptor. The reason why it works when I have split the DRAM in two descriptors is that DxeCore will only allocate the upper half and I'm usually trying to reserve a few low memory ranges - which isn't always the case. Thanks Michael On Thu, Dec 15, 2016 at 5:55 AM, Gao, Liming wrote: > Michael: > I understand your usage that BuildResourceDescriptorHob adds system memory range, BuildMemoryAllocationHob allocate the full memory range as reserved memory. Then, you expect they can be shown in EFI memory map. Right? > > BuildResourceDescriptorHob() with (start,size) 0x80000000,0x80000000, then BuildMemoryAllocationHob() with (start,size) 0x80000000,0x80000000. It doesn't work. > Two BuildResourceDescriptorHob() with (start,size) 0x80000000,0x40000000 and 0xc0000000,0x40000000, then two BuildMemoryAllocationHob(). It does work. Right? > > Thanks > Liming >> -----Original Message----- >> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of >> Michael Zimmermann >> Sent: Thursday, December 15, 2016 1:57 AM >> To: Ard Biesheuvel >> Cc: edk2-devel@lists.01.org >> Subject: Re: [edk2] correct way to reserve memory from PrePi? >> >> I've enabled GCD debugging and apparently it doesn't accept the allocation: >> GCD:AllocateMemorySpace(Base=0000000090000000,Length=0000000010000 >> 000) >> GcdAllocateType = AtAddress >> GcdMemoryType = SystemMem >> Alignment = 0000000000000001 >> ImageHandle = FDE28F90 >> DeviceHandle = 0 >> CoreAllocateSpaceCheckEntry:982 handle=FDE28F90 >> CoreAllocateSpace:1130 >> Status = Not Found >> GCDMemType Range Capabilities >> Attributes >> ========== ================================= >> ================ >> ================ >> NonExist 0000000000000000-000000007FFFFFFF 0000000000000000 >> 0000000000000000 >> SystemMem 0000000080000000-00000000FDFFFFFF 800000000000000E >> 0000000000000000* >> NonExist 00000000FE000000-00000000FE3FFFFF 0000000000000000 >> 0000000000000000 >> SystemMem 00000000FE400000-00000000FFFE5FFF 800000000000000E >> 0000000000000000 >> SystemMem 00000000FFFE6000-00000000FFFEEFFF 800000000000000E >> 0000000000000000* >> SystemMem 00000000FFFEF000-00000000FFFFFFFF 800000000000000E >> 0000000000000000 >> >> >> It fails in this line: >> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe >> /Gcd/Gcd.c#L982 >> In this example I've used(start,size) 0x80000000,0x80000000 for the >> resource descriptors. >> If I use 0x80000000,0x40000000 and 0xc0000000,0x40000000 everything >> works just fine. >> >> Thanks >> Michael >> >> On Wed, Dec 14, 2016 at 4:13 PM, Michael Zimmermann >> wrote: >> > As far as I know the proper way is to create resource descriptors >> > using BuildResourceDescriptorHob and then allocate reserved areas >> > using BuildMemoryAllocationHob. This way I don't have any overlapping >> > descriptors - I just allocated some memory very early. >> > >> > I ran many tests and it looks like all calls to >> > BuildMemoryAllocationHob get ignored if my dram hobs look like this: >> > 0x00000000 - 0x40000000 >> > >> > If I split this range into two Hob's like this everything seems to >> > work just fine: >> > 0x00000000 - 0x20000000 >> > 0x20000000 - 0x20000000 >> > >> > I took a look at other platforms like Juno and they add big dram Hob's >> > (2GB and 6GB) too so why is this a problem? >> > >> > Thanks >> > Michael >> > >> > On Wed, Dec 14, 2016 at 11:21 AM, Ard Biesheuvel >> > wrote: >> >> On 14 December 2016 at 10:02, Michael Zimmermann >> >> wrote: >> >>> I tried both BuildResourceDescriptorHob and BuildMemoryAllocationHob >> >>> but apparently they don't have any effect. >> >>> When I look at the output of the shell's memmap command there aren't >> >>> any reserved/unavailable pages. >> >>> >> >>> Furthermore, when using AllocatePages with one of the physical >> >>> addresses which I've reserved it succeeds which means that it's not >> >>> just a problem of how the memmap command works. >> >>> >> >>> Am I doing something wrong or is this a bug? >> >>> >> >> >> >> I think you need to ensure that they don't overlap existing resource >> >> descriptors: if you declare a region as reserved, you should not >> >> declare it as memory first >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel