From: "Gao, Liming" <liming.gao@intel.com>
To: Michael Zimmermann <sigmaepsilon92@gmail.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "edk2-devel@lists.01.org" <edk2-devel@ml01.01.org>,
"Gao, Liming" <liming.gao@intel.com>
Subject: Re: correct way to reserve memory from PrePi?
Date: Thu, 15 Dec 2016 04:55:40 +0000 [thread overview]
Message-ID: <4A89E2EF3DFEDB4C8BFDE51014F606A14D6A55EE@SHSMSX104.ccr.corp.intel.com> (raw)
In-Reply-To: <CAN9vWD+-QeV7Z0NwDQMphEtDvcrPw7gtgzxcSwpkfO6ONakZ0g@mail.gmail.com>
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 <ard.biesheuvel@linaro.org>
> Cc: edk2-devel@lists.01.org <edk2-devel@ml01.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
> <sigmaepsilon92@gmail.com> 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
> > <ard.biesheuvel@linaro.org> wrote:
> >> On 14 December 2016 at 10:02, Michael Zimmermann
> >> <sigmaepsilon92@gmail.com> 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
next prev parent reply other threads:[~2016-12-15 4:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-14 10:02 correct way to reserve memory from PrePi? Michael Zimmermann
2016-12-14 10:21 ` Ard Biesheuvel
2016-12-14 15:13 ` Michael Zimmermann
2016-12-14 17:57 ` Michael Zimmermann
2016-12-15 4:55 ` Gao, Liming [this message]
2016-12-15 5:02 ` Michael Zimmermann
2016-12-15 5:12 ` Gao, Liming
2016-12-15 5:27 ` Michael Zimmermann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A89E2EF3DFEDB4C8BFDE51014F606A14D6A55EE@SHSMSX104.ccr.corp.intel.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox