Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table type issue

2016-04-01 Thread Ard Biesheuvel 
On 1 April 2016 at 16:07, Yao, Jiewen  wrote:
> That is enough. Thanks!
>
> I suggest you use this way as temp work-around.
>
> As final solution, I think we can construct table after all ReadyToBoot 
> events are processed, which need more update in DxeCore.
>

For now, the work around is fine.

Thanks,
Ard.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table type issue

2016-04-01 Thread Yao, Jiewen 
That is enough. Thanks!

I suggest you use this way as temp work-around.

As final solution, I think we can construct table after all ReadyToBoot events 
are processed, which need more update in DxeCore.

Thank you
Yao Jiewen


> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Friday, April 1, 2016 10:02 PM
> To: Yao, Jiewen <jiewen@intel.com>
> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Gao, Liming
> <liming....@intel.com>
> Subject: Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table
> type issue
> 
> On 1 April 2016 at 15:57, Yao, Jiewen <jiewen@intel.com> wrote:
> > Yes, that is weird.
> > Do you see the same issue in February 24 image? Or is this a new issue?
> >
> 
> This is a different platform than I was using at the time to validate
> this code, so I cannot really compare them directly.
> 
> >
> > It seems some other module allocates RuntimeServicesData region in
> ReadyToBootEvent handler.
> > I am not sure if it is introduced by recent HiiDatabaseDxe change. Would
> you please try to set *PcdHiiOsRuntimeSupport|FALSE*?
> >
> 
> Yes, that fixes my problem.
> 
> Thanks,
> Ard.
> 
> 
> >
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> >> Ard Biesheuvel
> >> Sent: Friday, April 1, 2016 8:19 PM
> >> To: Yao, Jiewen <jiewen@intel.com>
> >> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Gao, Liming
> >> <liming@intel.com>
> >> Subject: Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes
> table
> >> type issue
> >>
> >> On 1 April 2016 at 14:16, Ard Biesheuvel <ard.biesheu...@linaro.org>
> wrote:
> >> > On 1 April 2016 at 09:25, Ard Biesheuvel <ard.biesheu...@linaro.org>
> >> wrote:
> >> >> On 1 April 2016 at 09:24, Ard Biesheuvel <ard.biesheu...@linaro.org>
> >> wrote:
> >> >>> On 31 March 2016 at 15:33, Ard Biesheuvel
> <ard.biesheu...@linaro.org>
> >> wrote:
> >> >>>> On 31 March 2016 at 15:20, Yao, Jiewen <jiewen@intel.com>
> >> wrote:
> >> >>>>> Hi Ard
> >> >>>>> Thanks for your log. Yes, it seems new issue, I have never
> >> encountered before.
> >> >>>>>
> >> >>>>> Here is what I found:
> >> >>>>>
> >> >>>>> 1) MemoryAttributeTable is always installed in ReadyToBoot event.
> >> (Sorry, I gave wrong info on EndOfDxe, that is for old properties table)
> >> >>>>>
> >> >>>>
> >> >>>> OK
> >> >>>>
> >> >>>>> 2) In this log, I have seen MemoryAttributeTable is installed 6 
> >> >>>>> times.
> It
> >> means this system boot 6 boot options. First 5 fail, and last one success. 
> >> I
> am
> >> not clear what device you want to boot, but it seems "Booting EFI Misc
> >> Device" category. It is also weird that RT_Data entry is changed every
> time.
> >> Does this boot device allocate/free RT_Data?
> >> >>>>>
> >> >>>>
> >> >>>> Good question, I can investigate
> >> >>>>
> >> >>>>> 3) In this log, it shows MemoryAttributeTable is always correct. See
> >> line 1427. I do not know why it is corrupt in efimemmap.log.
> >> >>>>> This memory attribute table is allocated in "BootServicesData"
> type
> >> memory. Are you sure that system does not corrupt BootServicesData
> when
> >> efimemmap.log is created?
> >> >>>>>
> >> >>>>> 4) So I suggest we check *when* this table is corrupted. I have
> >> MemoryAttributesDump UEFI APPLICATION (See attachment, password:
> >> 12345678). Maybe can you help run it in UEFI shell to see if
> >> MemoryAttributes table is correct or not?
> >> >>>>> We can use this way to narrow down the corruption - *when* it is
> >> created, or *after* it is created.
> >> >>>>>
> >> >>>>
> >> >>>> Shell> MemoryAttributesDump.efi
> >> >>>> MemoryAttributesTable:
> >> >>>>   Version - 0x0001
> >> >>>>   NumberOfEntries - 0x0019
> >> >>>&g

Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table type issue

2016-04-01 Thread Ard Biesheuvel 
On 1 April 2016 at 15:57, Yao, Jiewen <jiewen@intel.com> wrote:
> Yes, that is weird.
> Do you see the same issue in February 24 image? Or is this a new issue?
>

This is a different platform than I was using at the time to validate
this code, so I cannot really compare them directly.

>
> It seems some other module allocates RuntimeServicesData region in 
> ReadyToBootEvent handler.
> I am not sure if it is introduced by recent HiiDatabaseDxe change. Would you 
> please try to set *PcdHiiOsRuntimeSupport|FALSE*?
>

Yes, that fixes my problem.

Thanks,
Ard.


>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Ard Biesheuvel
>> Sent: Friday, April 1, 2016 8:19 PM
>> To: Yao, Jiewen <jiewen@intel.com>
>> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Gao, Liming
>> <liming....@intel.com>
>> Subject: Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table
>> type issue
>>
>> On 1 April 2016 at 14:16, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
>> > On 1 April 2016 at 09:25, Ard Biesheuvel <ard.biesheu...@linaro.org>
>> wrote:
>> >> On 1 April 2016 at 09:24, Ard Biesheuvel <ard.biesheu...@linaro.org>
>> wrote:
>> >>> On 31 March 2016 at 15:33, Ard Biesheuvel <ard.biesheu...@linaro.org>
>> wrote:
>> >>>> On 31 March 2016 at 15:20, Yao, Jiewen <jiewen@intel.com>
>> wrote:
>> >>>>> Hi Ard
>> >>>>> Thanks for your log. Yes, it seems new issue, I have never
>> encountered before.
>> >>>>>
>> >>>>> Here is what I found:
>> >>>>>
>> >>>>> 1) MemoryAttributeTable is always installed in ReadyToBoot event.
>> (Sorry, I gave wrong info on EndOfDxe, that is for old properties table)
>> >>>>>
>> >>>>
>> >>>> OK
>> >>>>
>> >>>>> 2) In this log, I have seen MemoryAttributeTable is installed 6 times. 
>> >>>>> It
>> means this system boot 6 boot options. First 5 fail, and last one success. I 
>> am
>> not clear what device you want to boot, but it seems "Booting EFI Misc
>> Device" category. It is also weird that RT_Data entry is changed every time.
>> Does this boot device allocate/free RT_Data?
>> >>>>>
>> >>>>
>> >>>> Good question, I can investigate
>> >>>>
>> >>>>> 3) In this log, it shows MemoryAttributeTable is always correct. See
>> line 1427. I do not know why it is corrupt in efimemmap.log.
>> >>>>> This memory attribute table is allocated in "BootServicesData" type
>> memory. Are you sure that system does not corrupt BootServicesData when
>> efimemmap.log is created?
>> >>>>>
>> >>>>> 4) So I suggest we check *when* this table is corrupted. I have
>> MemoryAttributesDump UEFI APPLICATION (See attachment, password:
>> 12345678). Maybe can you help run it in UEFI shell to see if
>> MemoryAttributes table is correct or not?
>> >>>>> We can use this way to narrow down the corruption - *when* it is
>> created, or *after* it is created.
>> >>>>>
>> >>>>
>> >>>> Shell> MemoryAttributesDump.efi
>> >>>> MemoryAttributesTable:
>> >>>>   Version - 0x0001
>> >>>>   NumberOfEntries - 0x0019
>> >>>>   DescriptorSize  - 0x0030
>> >>>>
>> >>>> Type   StartEnd  # Pages
>> Attributes
>> >>>> RT_DataF5B5-
>> 0030 80004000
>> >>>> RT_CodeF5B8-
>> 0010 80004000
>> >>>
>> >>> Actually, I did find something strange here: these first two regions
>> >>> are both set to EFI_MEMORY_XP, but the second one is
>> >>> EfiRuntimeServicesCode
>> >>>
>> >>> I am not sure if this is related, but it does look wrong to me.
>> >>>
>> >>
>> >> Never mind, this is mandated by the spec for PE/COFF images.
>> >
>> > OK, looking at the debug output again, there is in fact a problem on
>> > the BIOS side.
>> > Please refer to the attached debug log.
>> >
>> > It shows this region in the memory map
>>
>> Available  F5B5-F5B6 0020
>> 000F
>>
>> and this region in the memory attributes table
>>
>> RT_DataF5B5- 0030
>> 80004000
>>
>> This confuses the OS code, since it does not expect the available
>> region in the memory map, but there is clearly something wrong on the
>> firmware side.
> ___
> 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

Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table type issue

2016-04-01 Thread Yao, Jiewen 
Yes, that is weird.
Do you see the same issue in February 24 image? Or is this a new issue?


It seems some other module allocates RuntimeServicesData region in 
ReadyToBootEvent handler.
I am not sure if it is introduced by recent HiiDatabaseDxe change. Would you 
please try to set *PcdHiiOsRuntimeSupport|FALSE*?

I want to narrow down the issue.

If that is problem, we need consider a better place to construct the table.

Thank you
Yao Jiewen


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ard Biesheuvel
> Sent: Friday, April 1, 2016 8:19 PM
> To: Yao, Jiewen <jiewen@intel.com>
> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Gao, Liming
> <liming....@intel.com>
> Subject: Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table
> type issue
> 
> On 1 April 2016 at 14:16, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
> > On 1 April 2016 at 09:25, Ard Biesheuvel <ard.biesheu...@linaro.org>
> wrote:
> >> On 1 April 2016 at 09:24, Ard Biesheuvel <ard.biesheu...@linaro.org>
> wrote:
> >>> On 31 March 2016 at 15:33, Ard Biesheuvel <ard.biesheu...@linaro.org>
> wrote:
> >>>> On 31 March 2016 at 15:20, Yao, Jiewen <jiewen@intel.com>
> wrote:
> >>>>> Hi Ard
> >>>>> Thanks for your log. Yes, it seems new issue, I have never
> encountered before.
> >>>>>
> >>>>> Here is what I found:
> >>>>>
> >>>>> 1) MemoryAttributeTable is always installed in ReadyToBoot event.
> (Sorry, I gave wrong info on EndOfDxe, that is for old properties table)
> >>>>>
> >>>>
> >>>> OK
> >>>>
> >>>>> 2) In this log, I have seen MemoryAttributeTable is installed 6 times. 
> >>>>> It
> means this system boot 6 boot options. First 5 fail, and last one success. I 
> am
> not clear what device you want to boot, but it seems "Booting EFI Misc
> Device" category. It is also weird that RT_Data entry is changed every time.
> Does this boot device allocate/free RT_Data?
> >>>>>
> >>>>
> >>>> Good question, I can investigate
> >>>>
> >>>>> 3) In this log, it shows MemoryAttributeTable is always correct. See
> line 1427. I do not know why it is corrupt in efimemmap.log.
> >>>>> This memory attribute table is allocated in "BootServicesData" type
> memory. Are you sure that system does not corrupt BootServicesData when
> efimemmap.log is created?
> >>>>>
> >>>>> 4) So I suggest we check *when* this table is corrupted. I have
> MemoryAttributesDump UEFI APPLICATION (See attachment, password:
> 12345678). Maybe can you help run it in UEFI shell to see if
> MemoryAttributes table is correct or not?
> >>>>> We can use this way to narrow down the corruption - *when* it is
> created, or *after* it is created.
> >>>>>
> >>>>
> >>>> Shell> MemoryAttributesDump.efi
> >>>> MemoryAttributesTable:
> >>>>   Version - 0x0001
> >>>>   NumberOfEntries - 0x0019
> >>>>   DescriptorSize  - 0x0030
> >>>>
> >>>> Type   StartEnd  # Pages
> Attributes
> >>>> RT_DataF5B5-
> 0030 80004000
> >>>> RT_CodeF5B8-
> 0010 80004000
> >>>
> >>> Actually, I did find something strange here: these first two regions
> >>> are both set to EFI_MEMORY_XP, but the second one is
> >>> EfiRuntimeServicesCode
> >>>
> >>> I am not sure if this is related, but it does look wrong to me.
> >>>
> >>
> >> Never mind, this is mandated by the spec for PE/COFF images.
> >
> > OK, looking at the debug output again, there is in fact a problem on
> > the BIOS side.
> > Please refer to the attached debug log.
> >
> > It shows this region in the memory map
> 
> Available  F5B5-F5B6 0020
> 000F
> 
> and this region in the memory attributes table
> 
> RT_DataF5B5- 0030
> 80004000
> 
> This confuses the OS code, since it does not expect the available
> region in the memory map, but there is clearly something wrong on the
> firmware side.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table type issue

2016-04-01 Thread Ard Biesheuvel 
On 1 April 2016 at 14:16, Ard Biesheuvel  wrote:
> On 1 April 2016 at 09:25, Ard Biesheuvel  wrote:
>> On 1 April 2016 at 09:24, Ard Biesheuvel  wrote:
>>> On 31 March 2016 at 15:33, Ard Biesheuvel  wrote:
 On 31 March 2016 at 15:20, Yao, Jiewen  wrote:
> Hi Ard
> Thanks for your log. Yes, it seems new issue, I have never encountered 
> before.
>
> Here is what I found:
>
> 1) MemoryAttributeTable is always installed in ReadyToBoot event. (Sorry, 
> I gave wrong info on EndOfDxe, that is for old properties table)
>

 OK

> 2) In this log, I have seen MemoryAttributeTable is installed 6 times. It 
> means this system boot 6 boot options. First 5 fail, and last one 
> success. I am not clear what device you want to boot, but it seems 
> "Booting EFI Misc Device" category. It is also weird that RT_Data entry 
> is changed every time. Does this boot device allocate/free RT_Data?
>

 Good question, I can investigate

> 3) In this log, it shows MemoryAttributeTable is always correct. See line 
> 1427. I do not know why it is corrupt in efimemmap.log.
> This memory attribute table is allocated in "BootServicesData" type 
> memory. Are you sure that system does not corrupt BootServicesData when 
> efimemmap.log is created?
>
> 4) So I suggest we check *when* this table is corrupted. I have 
> MemoryAttributesDump UEFI APPLICATION (See attachment, password: 
> 12345678). Maybe can you help run it in UEFI shell to see if 
> MemoryAttributes table is correct or not?
> We can use this way to narrow down the corruption - *when* it is created, 
> or *after* it is created.
>

 Shell> MemoryAttributesDump.efi
 MemoryAttributesTable:
   Version - 0x0001
   NumberOfEntries - 0x0019
   DescriptorSize  - 0x0030

 Type   StartEnd  # Pages  Attributes
 RT_DataF5B5- 0030 
 80004000
 RT_CodeF5B8- 0010 
 80004000
>>>
>>> Actually, I did find something strange here: these first two regions
>>> are both set to EFI_MEMORY_XP, but the second one is
>>> EfiRuntimeServicesCode
>>>
>>> I am not sure if this is related, but it does look wrong to me.
>>>
>>
>> Never mind, this is mandated by the spec for PE/COFF images.
>
> OK, looking at the debug output again, there is in fact a problem on
> the BIOS side.
> Please refer to the attached debug log.
>
> It shows this region in the memory map

Available  F5B5-F5B6 0020 000F

and this region in the memory attributes table

RT_DataF5B5- 0030 80004000

This confuses the OS code, since it does not expect the available
region in the memory map, but there is clearly something wrong on the
firmware side.


fvp-memattr-debug-output.2
Description: Binary data
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table type issue

2016-04-01 Thread Ard Biesheuvel 
On 1 April 2016 at 09:24, Ard Biesheuvel  wrote:
> On 31 March 2016 at 15:33, Ard Biesheuvel  wrote:
>> On 31 March 2016 at 15:20, Yao, Jiewen  wrote:
>>> Hi Ard
>>> Thanks for your log. Yes, it seems new issue, I have never encountered 
>>> before.
>>>
>>> Here is what I found:
>>>
>>> 1) MemoryAttributeTable is always installed in ReadyToBoot event. (Sorry, I 
>>> gave wrong info on EndOfDxe, that is for old properties table)
>>>
>>
>> OK
>>
>>> 2) In this log, I have seen MemoryAttributeTable is installed 6 times. It 
>>> means this system boot 6 boot options. First 5 fail, and last one success. 
>>> I am not clear what device you want to boot, but it seems "Booting EFI Misc 
>>> Device" category. It is also weird that RT_Data entry is changed every 
>>> time. Does this boot device allocate/free RT_Data?
>>>
>>
>> Good question, I can investigate
>>
>>> 3) In this log, it shows MemoryAttributeTable is always correct. See line 
>>> 1427. I do not know why it is corrupt in efimemmap.log.
>>> This memory attribute table is allocated in "BootServicesData" type memory. 
>>> Are you sure that system does not corrupt BootServicesData when 
>>> efimemmap.log is created?
>>>
>>> 4) So I suggest we check *when* this table is corrupted. I have 
>>> MemoryAttributesDump UEFI APPLICATION (See attachment, password: 12345678). 
>>> Maybe can you help run it in UEFI shell to see if MemoryAttributes table is 
>>> correct or not?
>>> We can use this way to narrow down the corruption - *when* it is created, 
>>> or *after* it is created.
>>>
>>
>> Shell> MemoryAttributesDump.efi
>> MemoryAttributesTable:
>>   Version - 0x0001
>>   NumberOfEntries - 0x0019
>>   DescriptorSize  - 0x0030
>>
>> Type   StartEnd  # Pages  Attributes
>> RT_DataF5B5- 0030 
>> 80004000
>> RT_CodeF5B8- 0010 
>> 80004000
>
> Actually, I did find something strange here: these first two regions
> are both set to EFI_MEMORY_XP, but the second one is
> EfiRuntimeServicesCode
>
> I am not sure if this is related, but it does look wrong to me.
>

Never mind, this is mandated by the spec for PE/COFF images.

-- 
Ard.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table type issue

2016-04-01 Thread Ard Biesheuvel 
On 31 March 2016 at 15:33, Ard Biesheuvel  wrote:
> On 31 March 2016 at 15:20, Yao, Jiewen  wrote:
>> Hi Ard
>> Thanks for your log. Yes, it seems new issue, I have never encountered 
>> before.
>>
>> Here is what I found:
>>
>> 1) MemoryAttributeTable is always installed in ReadyToBoot event. (Sorry, I 
>> gave wrong info on EndOfDxe, that is for old properties table)
>>
>
> OK
>
>> 2) In this log, I have seen MemoryAttributeTable is installed 6 times. It 
>> means this system boot 6 boot options. First 5 fail, and last one success. I 
>> am not clear what device you want to boot, but it seems "Booting EFI Misc 
>> Device" category. It is also weird that RT_Data entry is changed every time. 
>> Does this boot device allocate/free RT_Data?
>>
>
> Good question, I can investigate
>
>> 3) In this log, it shows MemoryAttributeTable is always correct. See line 
>> 1427. I do not know why it is corrupt in efimemmap.log.
>> This memory attribute table is allocated in "BootServicesData" type memory. 
>> Are you sure that system does not corrupt BootServicesData when 
>> efimemmap.log is created?
>>
>> 4) So I suggest we check *when* this table is corrupted. I have 
>> MemoryAttributesDump UEFI APPLICATION (See attachment, password: 12345678). 
>> Maybe can you help run it in UEFI shell to see if MemoryAttributes table is 
>> correct or not?
>> We can use this way to narrow down the corruption - *when* it is created, or 
>> *after* it is created.
>>
>
> Shell> MemoryAttributesDump.efi
> MemoryAttributesTable:
>   Version - 0x0001
>   NumberOfEntries - 0x0019
>   DescriptorSize  - 0x0030
>
> Type   StartEnd  # Pages  Attributes
> RT_DataF5B5- 0030 80004000
> RT_CodeF5B8- 0010 80004000

Actually, I did find something strange here: these first two regions
are both set to EFI_MEMORY_XP, but the second one is
EfiRuntimeServicesCode

I am not sure if this is related, but it does look wrong to me.

Thanks,
Ard.


> RT_CodeF5B9- 0010 8002
> RT_CodeF5BA- 0030 80004000
> RT_CodeF5BD- 0010 8002
> RT_CodeF5BE- 0020 80004000
> RT_CodeF5C8- 0010 80004000
> RT_CodeF5C9- 0010 8002
> RT_CodeF5CA- 0020 80004000
> RT_DataF5CC- 0090 80004000
> RT_CodeF5D5- 0010 80004000
> RT_CodeF5D6- 0010 8002
> RT_CodeF5D7- 0030 80004000
> RT_DataF5DA- 00F0 80004000
> RT_CodeF5E9- 0010 80004000
> RT_CodeF5EA- 0010 8002
> RT_CodeF5EB- 0030 80004000
> RT_DataF5EE- 0050 80004000
> RT_CodeF5F3- 0010 80004000
> RT_CodeF5F4- 0010 8002
> RT_CodeF5F5- 0030 80004000
> RT_CodeFAF5- 0010 80004000
> RT_CodeFAF6- 0010 8002
> RT_CodeFAF7- 0020 80004000
> RT_DataFAFA- 0050 80004000
>
> So it looks like the table gets corrupted by the OS loader. I will
> investigate a bit more
>
> Thanks,
> Ard.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table type issue

2016-03-31 Thread Yao, Jiewen 
Glad to know BIOS is good. :-)

Thank you
Yao Jiewen

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Friday, April 1, 2016 12:08 AM
> To: Yao, Jiewen <jiewen@intel.com>
> Cc: Gao, Liming <liming@intel.com>; edk2-devel@lists.01.org
> <edk2-de...@ml01.01.org>
> Subject: Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table
> type issue
> 
> On 31 March 2016 at 16:09, Yao, Jiewen <jiewen@intel.com> wrote:
> > Thanks for your quick response.
> >
> > Then I will be waiting for your investigation result.
> >
> > If you see the value to have this dump tool check in, maybe we can put to
> MdeModulePkg/Application.
> > Next time, we do not need share it via email.
> >
> 
> 
> I have to apologise for the noise. This issue is an OS problem, not a
> firmware problem: if I dump the contents of the table very early
> during boot, it looks fine, but later when I process it, the first
> entry is corrupted.
> 
> Thanks for the help!
> Ard.
> 
> 
> >> -Original Message-
> >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >> Sent: Thursday, March 31, 2016 9:34 PM
> >> To: Yao, Jiewen <jiewen@intel.com>
> >> Cc: Gao, Liming <liming@intel.com>; edk2-devel@lists.01.org
> >> <edk2-de...@ml01.01.org>
> >> Subject: Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes
> table
> >> type issue
> >>
> >> On 31 March 2016 at 15:20, Yao, Jiewen <jiewen@intel.com> wrote:
> >> > Hi Ard
> >> > Thanks for your log. Yes, it seems new issue, I have never encountered
> >> before.
> >> >
> >> > Here is what I found:
> >> >
> >> > 1) MemoryAttributeTable is always installed in ReadyToBoot event.
> (Sorry, I
> >> gave wrong info on EndOfDxe, that is for old properties table)
> >> >
> >>
> >> OK
> >>
> >> > 2) In this log, I have seen MemoryAttributeTable is installed 6 times. It
> >> means this system boot 6 boot options. First 5 fail, and last one success. 
> >> I
> am
> >> not clear what device you want to boot, but it seems "Booting EFI Misc
> >> Device" category. It is also weird that RT_Data entry is changed every
> time.
> >> Does this boot device allocate/free RT_Data?
> >> >
> >>
> >> Good question, I can investigate
> >>
> >> > 3) In this log, it shows MemoryAttributeTable is always correct. See line
> >> 1427. I do not know why it is corrupt in efimemmap.log.
> >> > This memory attribute table is allocated in "BootServicesData" type
> >> memory. Are you sure that system does not corrupt BootServicesData
> when
> >> efimemmap.log is created?
> >> >
> >> > 4) So I suggest we check *when* this table is corrupted. I have
> >> MemoryAttributesDump UEFI APPLICATION (See attachment, password:
> >> 12345678). Maybe can you help run it in UEFI shell to see if
> >> MemoryAttributes table is correct or not?
> >> > We can use this way to narrow down the corruption - *when* it is
> created,
> >> or *after* it is created.
> >> >
> >>
> >> Shell> MemoryAttributesDump.efi
> >> MemoryAttributesTable:
> >>   Version - 0x0001
> >>   NumberOfEntries - 0x0019
> >>   DescriptorSize  - 0x0030
> >>
> >> Type   StartEnd  # Pages
> >> Attributes
> >> RT_DataF5B5-
> 0030
> >> 80004000
> >> RT_CodeF5B8-
> 0010
> >> 80004000
> >> RT_CodeF5B9-
> 0010
> >> 8002
> >> RT_CodeF5BA-
> 0030
> >> 80004000
> >> RT_CodeF5BD-
> 0010
> >> 8002
> >> RT_CodeF5BE-
> 0020
> >> 80004000
> >> RT_CodeF5C8-
> 0010
> >> 80004000
> >> RT_CodeF5C9-
> 0010
> >> 8002
> >> RT_CodeF5CA-
> 0020
> >> 80004000
> >> RT_DataF5CC-
&g

Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table type issue

2016-03-31 Thread Ard Biesheuvel 
On 31 March 2016 at 16:09, Yao, Jiewen <jiewen@intel.com> wrote:
> Thanks for your quick response.
>
> Then I will be waiting for your investigation result.
>
> If you see the value to have this dump tool check in, maybe we can put to 
> MdeModulePkg/Application.
> Next time, we do not need share it via email.
>


I have to apologise for the noise. This issue is an OS problem, not a
firmware problem: if I dump the contents of the table very early
during boot, it looks fine, but later when I process it, the first
entry is corrupted.

Thanks for the help!
Ard.


>> -Original Message-
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sent: Thursday, March 31, 2016 9:34 PM
>> To: Yao, Jiewen <jiewen@intel.com>
>> Cc: Gao, Liming <liming@intel.com>; edk2-devel@lists.01.org
>> <edk2-de...@ml01.01.org>
>> Subject: Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table
>> type issue
>>
>> On 31 March 2016 at 15:20, Yao, Jiewen <jiewen@intel.com> wrote:
>> > Hi Ard
>> > Thanks for your log. Yes, it seems new issue, I have never encountered
>> before.
>> >
>> > Here is what I found:
>> >
>> > 1) MemoryAttributeTable is always installed in ReadyToBoot event. (Sorry, I
>> gave wrong info on EndOfDxe, that is for old properties table)
>> >
>>
>> OK
>>
>> > 2) In this log, I have seen MemoryAttributeTable is installed 6 times. It
>> means this system boot 6 boot options. First 5 fail, and last one success. I 
>> am
>> not clear what device you want to boot, but it seems "Booting EFI Misc
>> Device" category. It is also weird that RT_Data entry is changed every time.
>> Does this boot device allocate/free RT_Data?
>> >
>>
>> Good question, I can investigate
>>
>> > 3) In this log, it shows MemoryAttributeTable is always correct. See line
>> 1427. I do not know why it is corrupt in efimemmap.log.
>> > This memory attribute table is allocated in "BootServicesData" type
>> memory. Are you sure that system does not corrupt BootServicesData when
>> efimemmap.log is created?
>> >
>> > 4) So I suggest we check *when* this table is corrupted. I have
>> MemoryAttributesDump UEFI APPLICATION (See attachment, password:
>> 12345678). Maybe can you help run it in UEFI shell to see if
>> MemoryAttributes table is correct or not?
>> > We can use this way to narrow down the corruption - *when* it is created,
>> or *after* it is created.
>> >
>>
>> Shell> MemoryAttributesDump.efi
>> MemoryAttributesTable:
>>   Version - 0x0001
>>   NumberOfEntries - 0x0019
>>   DescriptorSize  - 0x0030
>>
>> Type   StartEnd  # Pages
>> Attributes
>> RT_DataF5B5- 0030
>> 80004000
>> RT_CodeF5B8- 0010
>> 80004000
>> RT_CodeF5B9- 0010
>> 8002
>> RT_CodeF5BA- 0030
>> 80004000
>> RT_CodeF5BD- 0010
>> 8002
>> RT_CodeF5BE- 0020
>> 80004000
>> RT_CodeF5C8- 0010
>> 80004000
>> RT_CodeF5C9- 0010
>> 8002
>> RT_CodeF5CA- 0020
>> 80004000
>> RT_DataF5CC- 0090
>> 80004000
>> RT_CodeF5D5- 0010
>> 80004000
>> RT_CodeF5D6- 0010
>> 8002
>> RT_CodeF5D7- 0030
>> 80004000
>> RT_DataF5DA- 00F0
>> 80004000
>> RT_CodeF5E9- 0010
>> 80004000
>> RT_CodeF5EA- 0010
>> 8002
>> RT_CodeF5EB- 0030
>> 80004000
>> RT_DataF5EE- 0050
>> 80004000
>> RT_CodeF5F3- 0010
>> 80004000
>> RT_CodeF5F4- 001

Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table type issue

2016-03-31 Thread Yao, Jiewen 
Thanks for your quick response.

Then I will be waiting for your investigation result.

If you see the value to have this dump tool check in, maybe we can put to 
MdeModulePkg/Application.
Next time, we do not need share it via email.

Thank you
Yao Jiewen


> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Thursday, March 31, 2016 9:34 PM
> To: Yao, Jiewen <jiewen@intel.com>
> Cc: Gao, Liming <liming@intel.com>; edk2-devel@lists.01.org
> <edk2-de...@ml01.01.org>
> Subject: Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table
> type issue
> 
> On 31 March 2016 at 15:20, Yao, Jiewen <jiewen@intel.com> wrote:
> > Hi Ard
> > Thanks for your log. Yes, it seems new issue, I have never encountered
> before.
> >
> > Here is what I found:
> >
> > 1) MemoryAttributeTable is always installed in ReadyToBoot event. (Sorry, I
> gave wrong info on EndOfDxe, that is for old properties table)
> >
> 
> OK
> 
> > 2) In this log, I have seen MemoryAttributeTable is installed 6 times. It
> means this system boot 6 boot options. First 5 fail, and last one success. I 
> am
> not clear what device you want to boot, but it seems "Booting EFI Misc
> Device" category. It is also weird that RT_Data entry is changed every time.
> Does this boot device allocate/free RT_Data?
> >
> 
> Good question, I can investigate
> 
> > 3) In this log, it shows MemoryAttributeTable is always correct. See line
> 1427. I do not know why it is corrupt in efimemmap.log.
> > This memory attribute table is allocated in "BootServicesData" type
> memory. Are you sure that system does not corrupt BootServicesData when
> efimemmap.log is created?
> >
> > 4) So I suggest we check *when* this table is corrupted. I have
> MemoryAttributesDump UEFI APPLICATION (See attachment, password:
> 12345678). Maybe can you help run it in UEFI shell to see if
> MemoryAttributes table is correct or not?
> > We can use this way to narrow down the corruption - *when* it is created,
> or *after* it is created.
> >
> 
> Shell> MemoryAttributesDump.efi
> MemoryAttributesTable:
>   Version - 0x0001
>   NumberOfEntries - 0x0019
>   DescriptorSize  - 0x0030
> 
> Type   StartEnd  # Pages
> Attributes
> RT_DataF5B5- 0030
> 80004000
> RT_CodeF5B8- 0010
> 80004000
> RT_CodeF5B9- 0010
> 8002
> RT_CodeF5BA- 0030
> 80004000
> RT_CodeF5BD- 0010
> 8002
> RT_CodeF5BE- 0020
> 80004000
> RT_CodeF5C8- 0010
> 80004000
> RT_CodeF5C9- 0010
> 8002
> RT_CodeF5CA- 0020
> 80004000
> RT_DataF5CC- 0090
> 80004000
> RT_CodeF5D5- 0010
> 80004000
> RT_CodeF5D6- 0010
> 8002
> RT_CodeF5D7- 0030
> 80004000
> RT_DataF5DA- 00F0
> 80004000
> RT_CodeF5E9- 0010
> 80004000
> RT_CodeF5EA- 0010
> 8002
> RT_CodeF5EB- 0030
> 80004000
> RT_DataF5EE- 0050
> 80004000
> RT_CodeF5F3- 0010
> 80004000
> RT_CodeF5F4- 0010
> 8002
> RT_CodeF5F5- 0030
> 80004000
> RT_CodeFAF5- 0010
> 80004000
> RT_CodeFAF6- 0010
> 8002
> RT_CodeFAF7- 0020
> 80004000
> RT_DataFAFA- 0050
> 80004000
> 
> So it looks like the table gets corrupted by the OS loader. I will
> investigate a bit more
> 
> Thanks,
> Ard.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table type issue

2016-03-31 Thread Ard Biesheuvel 
On 31 March 2016 at 15:20, Yao, Jiewen  wrote:
> Hi Ard
> Thanks for your log. Yes, it seems new issue, I have never encountered before.
>
> Here is what I found:
>
> 1) MemoryAttributeTable is always installed in ReadyToBoot event. (Sorry, I 
> gave wrong info on EndOfDxe, that is for old properties table)
>

OK

> 2) In this log, I have seen MemoryAttributeTable is installed 6 times. It 
> means this system boot 6 boot options. First 5 fail, and last one success. I 
> am not clear what device you want to boot, but it seems "Booting EFI Misc 
> Device" category. It is also weird that RT_Data entry is changed every time. 
> Does this boot device allocate/free RT_Data?
>

Good question, I can investigate

> 3) In this log, it shows MemoryAttributeTable is always correct. See line 
> 1427. I do not know why it is corrupt in efimemmap.log.
> This memory attribute table is allocated in "BootServicesData" type memory. 
> Are you sure that system does not corrupt BootServicesData when efimemmap.log 
> is created?
>
> 4) So I suggest we check *when* this table is corrupted. I have 
> MemoryAttributesDump UEFI APPLICATION (See attachment, password: 12345678). 
> Maybe can you help run it in UEFI shell to see if MemoryAttributes table is 
> correct or not?
> We can use this way to narrow down the corruption - *when* it is created, or 
> *after* it is created.
>

Shell> MemoryAttributesDump.efi
MemoryAttributesTable:
  Version - 0x0001
  NumberOfEntries - 0x0019
  DescriptorSize  - 0x0030

Type   StartEnd  # Pages  Attributes
RT_DataF5B5- 0030 80004000
RT_CodeF5B8- 0010 80004000
RT_CodeF5B9- 0010 8002
RT_CodeF5BA- 0030 80004000
RT_CodeF5BD- 0010 8002
RT_CodeF5BE- 0020 80004000
RT_CodeF5C8- 0010 80004000
RT_CodeF5C9- 0010 8002
RT_CodeF5CA- 0020 80004000
RT_DataF5CC- 0090 80004000
RT_CodeF5D5- 0010 80004000
RT_CodeF5D6- 0010 8002
RT_CodeF5D7- 0030 80004000
RT_DataF5DA- 00F0 80004000
RT_CodeF5E9- 0010 80004000
RT_CodeF5EA- 0010 8002
RT_CodeF5EB- 0030 80004000
RT_DataF5EE- 0050 80004000
RT_CodeF5F3- 0010 80004000
RT_CodeF5F4- 0010 8002
RT_CodeF5F5- 0030 80004000
RT_CodeFAF5- 0010 80004000
RT_CodeFAF6- 0010 8002
RT_CodeFAF7- 0020 80004000
RT_DataFAFA- 0050 80004000

So it looks like the table gets corrupted by the OS loader. I will
investigate a bit more

Thanks,
Ard.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table type issue

2016-03-31 Thread Ard Biesheuvel 
Full log attached. I have confirmed that the issue also occurs on this
DEBUG build


On 31 March 2016 at 10:57, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
> On 31 March 2016 at 10:54, Yao, Jiewen <jiewen@intel.com> wrote:
>> Correct typo. meat->meet
>>
>> I just thought one possible issue. This properties table is collected at 
>> EndOfDxe.
>>
>
> Hmm, perhaps that is too early then, since the implementation allows
> DXE_RUNTIME_DRIVER modules to be installed from the shell as well
>
>
>> If there is any RT data allocate after that event, they will not be included.
>>
>> Would you please check where these 2 RT_data regions are allocated?
>>
>>
>>
>>> -Original Message-
>>> From: Yao, Jiewen
>>> Sent: Thursday, March 31, 2016 4:51 PM
>>> To: Yao, Jiewen <jiewen@intel.com>; Ard Biesheuvel
>>> <ard.biesheu...@linaro.org>
>>> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Gao, Liming
>>> <liming@intel.com>
>>> Subject: RE: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table
>>> type issue
>>>
>>> BTW: I found below 2 entries are missing in properties table.
>>>
>>> [0.00]   0xf5a1-0xf5a7 [Runtime Data
>>> |RUN|  |  |  |  |  |  |   |WB|WT|WC|UC]*
>>> [0.00]   0xf5b7-0xf5b7 [Runtime Data
>>> |RUN|  |  |  |  |  |  |   |WB|WT|WC|UC]*
>>>
>>> Is that the problem you meet?
>>>
>>>
>>>
>>> Thank you
>>> Yao Jiewen
>>>
>>>
>>> > -Original Message-----
>>> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>>> > Yao, Jiewen
>>> > Sent: Thursday, March 31, 2016 4:49 PM
>>> > To: Ard Biesheuvel <ard.biesheu...@linaro.org>
>>> > Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Gao, Liming
>>> > <liming@intel.com>
>>> > Subject: Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table
>>> > type issue
>>> >
>>> > Hi Ard
>>> > I think you replied mail say this patch works fine at Wednesday, February
>>> 24,
>>> > 2016 4:15 PM.
>>> >
>>> > May I know if this is new issue or old issue?
>>> >
>>> >
>>> > Also, in order to narrow down issue, would you please send me more detail
>>> > log?
>>> > 1)  Would you please enable VERBOSE for DxeCore and send a serial debug
>>> > log to me for analysis?
>>> > You can use below PCD override for DxeMain.inf
>>> > 
>>> >   gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x80400040
>>> >
>>> > 2)  Would you please run SHELL command: memmap? And send log to me
>>> > as well? I would like to know full memory map layout.
>>> >
>>> >
>>> > Thank you
>>> > Yao Jiewen
>>> >
>>> >
>>> > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>>> > Sent: Wednesday, February 24, 2016 4:15 PM
>>> > To: Yao, Jiewen
>>> > Cc: Gao, Liming; edk2-de...@ml01.01.org
>>> > Subject: Re: [patch V3] MdeModulePkg: Fix Memory Attributes table type
>>> > issue
>>> >
>>> > On 24 February 2016 at 07:02, Yao, Jiewen wrote:
>>> > > Hi Ard
>>> > > Liming gave me minor update comment, and I have finished V3.
>>> > >
>>> > > Should I wait for your validation on AArch64?
>>> > >
>>> >
>>> > Still works fine for me. Thanks.
>>> >
>>> > Tested-by: Ard Biesheuvel
>>> >
>>> >
>>> > > -Original Message-
>>> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
>>> Of
>>> > > Ard Biesheuvel
>>> > > Sent: Thursday, March 31, 2016 4:37 PM
>>> > > To: Yao, Jiewen <jiewen@intel.com>
>>> > > Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Gao, Liming
>>> > > <liming@intel.com>
>>> > > Subject: Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes
>>> table
>>> > > type issue
>>> > >
>>> > > On 23 February 2016 at 05:46, Jiewen Yao <jiewen@intel.com>
>>> wrote:
>>> > > > According to the spec, each entry in the Memory
>>> > > > Attributes table shall have the same type as
>>> > > > the region it was carved out of in the UEFI memory map.
>>> > > > The current attribute uses RTData for PE Data, but
>>> > > > it should be RTCode.
>>> > > >
>>> > > > This patch fixed the issue. It is validated with or
>>> > > > without PropertiesTable.
>>> > > >
>>> > >
>>> > > Hello all,
>>> > >
>>> > > I still see issues with this code. I have attached a memory map and
>>> > > the contents of a memory attributes table. The problem is that the
>>> > > first entry is corrupted.
>>> > >
>>> > > Thanks,
>>> > > Ard.
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > ___
>>> > edk2-devel mailing list
>>> > edk2-devel@lists.01.org
>>> > https://lists.01.org/mailman/listinfo/edk2-devel


fvp-memory-attribute-debug-output
Description: Binary data
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table type issue

2016-03-31 Thread Ard Biesheuvel 
On 31 March 2016 at 10:54, Yao, Jiewen <jiewen@intel.com> wrote:
> Correct typo. meat->meet
>
> I just thought one possible issue. This properties table is collected at 
> EndOfDxe.
>

Hmm, perhaps that is too early then, since the implementation allows
DXE_RUNTIME_DRIVER modules to be installed from the shell as well


> If there is any RT data allocate after that event, they will not be included.
>
> Would you please check where these 2 RT_data regions are allocated?
>
>
>
>> -Original Message-
>> From: Yao, Jiewen
>> Sent: Thursday, March 31, 2016 4:51 PM
>> To: Yao, Jiewen <jiewen@intel.com>; Ard Biesheuvel
>> <ard.biesheu...@linaro.org>
>> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Gao, Liming
>> <liming@intel.com>
>> Subject: RE: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table
>> type issue
>>
>> BTW: I found below 2 entries are missing in properties table.
>>
>> [0.00]   0xf5a1-0xf5a7 [Runtime Data
>> |RUN|  |  |  |  |  |  |   |WB|WT|WC|UC]*
>> [0.00]   0xf5b7-0xf5b7 [Runtime Data
>> |RUN|  |  |  |  |  |  |   |WB|WT|WC|UC]*
>>
>> Is that the problem you meet?
>>
>>
>>
>> Thank you
>> Yao Jiewen
>>
>>
>> > -Original Message-
>> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> > Yao, Jiewen
>> > Sent: Thursday, March 31, 2016 4:49 PM
>> > To: Ard Biesheuvel <ard.biesheu...@linaro.org>
>> > Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Gao, Liming
>> > <liming@intel.com>
>> > Subject: Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table
>> > type issue
>> >
>> > Hi Ard
>> > I think you replied mail say this patch works fine at Wednesday, February
>> 24,
>> > 2016 4:15 PM.
>> >
>> > May I know if this is new issue or old issue?
>> >
>> >
>> > Also, in order to narrow down issue, would you please send me more detail
>> > log?
>> > 1)  Would you please enable VERBOSE for DxeCore and send a serial debug
>> > log to me for analysis?
>> > You can use below PCD override for DxeMain.inf
>> > 
>> >   gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x80400040
>> >
>> > 2)  Would you please run SHELL command: memmap? And send log to me
>> > as well? I would like to know full memory map layout.
>> >
>> >
>> > Thank you
>> > Yao Jiewen
>> >
>> >
>> > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> > Sent: Wednesday, February 24, 2016 4:15 PM
>> > To: Yao, Jiewen
>> > Cc: Gao, Liming; edk2-de...@ml01.01.org
>> > Subject: Re: [patch V3] MdeModulePkg: Fix Memory Attributes table type
>> > issue
>> >
>> > On 24 February 2016 at 07:02, Yao, Jiewen wrote:
>> > > Hi Ard
>> > > Liming gave me minor update comment, and I have finished V3.
>> > >
>> > > Should I wait for your validation on AArch64?
>> > >
>> >
>> > Still works fine for me. Thanks.
>> >
>> > Tested-by: Ard Biesheuvel
>> >
>> >
>> > > -Original Message-
>> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
>> Of
>> > > Ard Biesheuvel
>> > > Sent: Thursday, March 31, 2016 4:37 PM
>> > > To: Yao, Jiewen <jiewen@intel.com>
>> > > Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Gao, Liming
>> > > <liming@intel.com>
>> > > Subject: Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes
>> table
>> > > type issue
>> > >
>> > > On 23 February 2016 at 05:46, Jiewen Yao <jiewen@intel.com>
>> wrote:
>> > > > According to the spec, each entry in the Memory
>> > > > Attributes table shall have the same type as
>> > > > the region it was carved out of in the UEFI memory map.
>> > > > The current attribute uses RTData for PE Data, but
>> > > > it should be RTCode.
>> > > >
>> > > > This patch fixed the issue. It is validated with or
>> > > > without PropertiesTable.
>> > > >
>> > >
>> > > Hello all,
>> > >
>> > > I still see issues with this code. I have attached a memory map and
>> > > the contents of a memory attributes table. The problem is that the
>> > > first entry is corrupted.
>> > >
>> > > Thanks,
>> > > Ard.
>> > >
>> > >
>> > >
>> > >
>> > >
>> > ___
>> > 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

Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table type issue

2016-03-31 Thread Ard Biesheuvel 
On 31 March 2016 at 10:48, Yao, Jiewen  wrote:
> Hi Ard
> I think you replied mail say this patch works fine at Wednesday, February 24, 
> 2016 4:15 PM.
>
> May I know if this is new issue or old issue?
>

This is a new issue.

>
> Also, in order to narrow down issue, would you please send me more detail log?
> 1)  Would you please enable VERBOSE for DxeCore and send a serial debug 
> log to me for analysis?
> You can use below PCD override for DxeMain.inf
> 
>   gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x80400040
>
> 2)  Would you please run SHELL command: memmap? And send log to me as 
> well? I would like to know full memory map layout.
>

OK

I will collect as much information as I can (including the allocation
of the missing RT regions)
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table type issue

2016-03-31 Thread Yao, Jiewen 
Hi Ard
I think you replied mail say this patch works fine at Wednesday, February 24, 
2016 4:15 PM.

May I know if this is new issue or old issue?


Also, in order to narrow down issue, would you please send me more detail log?
1)  Would you please enable VERBOSE for DxeCore and send a serial debug log 
to me for analysis?
You can use below PCD override for DxeMain.inf

  gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x80400040

2)  Would you please run SHELL command: memmap? And send log to me as well? 
I would like to know full memory map layout.


Thank you
Yao Jiewen


From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] 
Sent: Wednesday, February 24, 2016 4:15 PM
To: Yao, Jiewen
Cc: Gao, Liming; edk2-de...@ml01.01.org
Subject: Re: [patch V3] MdeModulePkg: Fix Memory Attributes table type issue

On 24 February 2016 at 07:02, Yao, Jiewen wrote:
> Hi Ard
> Liming gave me minor update comment, and I have finished V3.
>
> Should I wait for your validation on AArch64?
>

Still works fine for me. Thanks.

Tested-by: Ard Biesheuvel


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ard Biesheuvel
> Sent: Thursday, March 31, 2016 4:37 PM
> To: Yao, Jiewen <jiewen@intel.com>
> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Gao, Liming
> <liming@intel.com>
> Subject: Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table
> type issue
> 
> On 23 February 2016 at 05:46, Jiewen Yao <jiewen@intel.com> wrote:
> > According to the spec, each entry in the Memory
> > Attributes table shall have the same type as
> > the region it was carved out of in the UEFI memory map.
> > The current attribute uses RTData for PE Data, but
> > it should be RTCode.
> >
> > This patch fixed the issue. It is validated with or
> > without PropertiesTable.
> >
> 
> Hello all,
> 
> I still see issues with this code. I have attached a memory map and
> the contents of a memory attributes table. The problem is that the
> first entry is corrupted.
> 
> Thanks,
> Ard.
> 
> 
> 
> 
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table type issue

2016-03-31 Thread Ard Biesheuvel 
On 23 February 2016 at 05:46, Jiewen Yao  wrote:
> According to the spec, each entry in the Memory
> Attributes table shall have the same type as
> the region it was carved out of in the UEFI memory map.
> The current attribute uses RTData for PE Data, but
> it should be RTCode.
>
> This patch fixed the issue. It is validated with or
> without PropertiesTable.
>

Hello all,

I still see issues with this code. I have attached a memory map and
the contents of a memory attributes table. The problem is that the
first entry is corrupted.

Thanks,
Ard.





> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: "Yao, Jiewen" 
> Cc: "Ard Biesheuvel" 
> Cc: "Gao, Liming" 
> ---
>  MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c |   6 --
>  MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c   | 114 
> +++--
>  2 files changed, 37 insertions(+), 83 deletions(-)
>
> diff --git a/MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c 
> b/MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c
> index c84146a..416ed3d 100644
> --- a/MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c
> +++ b/MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c
> @@ -72,8 +72,6 @@ CoreGetMemoryMapPropertiesTable (
>
>  extern EFI_PROPERTIES_TABLE  mPropertiesTable;
>
> -BOOLEAN mIsConstructingMemoryAttributesTable = FALSE;
> -
>  /**
>Install MemoryAttributesTable.
>
> @@ -105,8 +103,6 @@ InstallMemoryAttributesTable (
>  return ;
>}
>
> -  mIsConstructingMemoryAttributesTable = TRUE;
> -
>MemoryMapSize = 0;
>MemoryMap = NULL;
>Status = CoreGetMemoryMapPropertiesTable (
> @@ -181,8 +177,6 @@ InstallMemoryAttributesTable (
>
>Status = gBS->InstallConfigurationTable (, 
> MemoryAttributesTable);
>ASSERT_EFI_ERROR (Status);
> -
> -  mIsConstructingMemoryAttributesTable = FALSE;
>  }
>
>  /**
> diff --git a/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c 
> b/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c
> index 6e5ad03..ebe7096 100644
> --- a/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c
> +++ b/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c
> @@ -1,7 +1,7 @@
>  /** @file
>UEFI PropertiesTable support
>
> -Copyright (c) 2015, Intel Corporation. All rights reserved.
> +Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.
>  This program and the accompanying materials
>  are licensed and made available under the terms and conditions of the BSD 
> License
>  which accompanies this distribution.  The full text of the license may be 
> found at
> @@ -80,14 +80,7 @@ EFI_PROPERTIES_TABLE  mPropertiesTable = {
>
>  EFI_LOCK   mPropertiesTableLock = EFI_INITIALIZE_LOCK_VARIABLE 
> (TPL_NOTIFY);
>
> -//
> -// Temporary save for original memory map.
> -// This is for MemoryAttributesTable only.
> -//
> -extern BOOLEAN mIsConstructingMemoryAttributesTable;
> -EFI_MEMORY_DESCRIPTOR  *mMemoryMapOrg;
> -UINTN  mMemoryMapOrgSize;
> -UINTN  mDescriptorSize;
> +BOOLEANmPropertiesTableEnable;
>
>  //
>  // Below functions are for MemoryMap
> @@ -199,42 +192,6 @@ SortMemoryMap (
>  }
>
>  /**
> -  Check if this memory entry spans across original memory map boundary.
> -
> -  @param PhysicalStart   The PhysicalStart of memory
> -  @param NumberOfPages   The NumberOfPages of memory
> -
> -  @retval TRUE  This memory entry spans across original memory map boundary.
> -  @retval FALSE This memory entry does not span cross original memory map 
> boundary.
> -**/
> -STATIC
> -BOOLEAN
> -DoesEntrySpanAcrossBoundary (
> -  IN UINT64  PhysicalStart,
> -  IN UINT64  NumberOfPages
> -  )
> -{
> -  EFI_MEMORY_DESCRIPTOR   *MemoryMapEntry;
> -  EFI_MEMORY_DESCRIPTOR   *MemoryMapEnd;
> -  UINT64  MemoryBlockLength;
> -
> -  MemoryMapEntry = mMemoryMapOrg;
> -  MemoryMapEnd   = (EFI_MEMORY_DESCRIPTOR *) ((UINT8 *) mMemoryMapOrg + 
> mMemoryMapOrgSize);
> -  while (MemoryMapEntry < MemoryMapEnd) {
> -MemoryBlockLength = (UINT64) (EfiPagesToSize 
> (MemoryMapEntry->NumberOfPages));
> -
> -if ((MemoryMapEntry->PhysicalStart <= PhysicalStart) &&
> -(MemoryMapEntry->PhysicalStart + MemoryBlockLength > PhysicalStart) 
> &&
> -(MemoryMapEntry->PhysicalStart + MemoryBlockLength < PhysicalStart + 
> EfiPagesToSize (NumberOfPages))) {
> -  return TRUE;
> -}
> -
> -MemoryMapEntry = NEXT_MEMORY_DESCRIPTOR (MemoryMapEntry, 
> mDescriptorSize);
> -  }
> -  return FALSE;
> -}
> -
> -/**
>Merge continous memory map entries whose have same attributes.
>
>@param  MemoryMap  A pointer to the buffer in which firmware 
> places
> @@ -271,8 +228,7 @@ MergeMemoryMap (
>if (((UINTN)NextMemoryMapEntry < (UINTN)MemoryMapEnd) &&
>(MemoryMapEntry->Type == NextMemoryMapEntry->Type) &&
>(MemoryMapEntry->Attribute ==

Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table type issue

2016-02-24 Thread Yao, Jiewen 
Thank you very much!

From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Wednesday, February 24, 2016 4:15 PM
To: Yao, Jiewen
Cc: Gao, Liming; edk2-de...@ml01.01.org
Subject: Re: [patch V3] MdeModulePkg: Fix Memory Attributes table type issue

On 24 February 2016 at 07:02, Yao, Jiewen wrote:
> Hi Ard
> Liming gave me minor update comment, and I have finished V3.
>
> Should I wait for your validation on AArch64?
>

Still works fine for me. Thanks.

Tested-by: Ard Biesheuvel

> -Original Message-
> From: Gao, Liming
> Sent: Tuesday, February 23, 2016 1:10 PM
> To: Yao, Jiewen; edk2-de...@ml01.01.org
> Cc: Ard Biesheuvel
> Subject: RE: [patch V3] MdeModulePkg: Fix Memory Attributes table type
> issue
>
>
> Reviewed-by: Liming Gao -Original
> Message-
> From: Yao, Jiewen
> Sent: Tuesday, February 23, 2016 12:47 PM
> To: edk2-de...@ml01.01.org
> Cc: Yao, Jiewen ; Ard Biesheuvel
> ; Gao, Liming
> Subject: [patch V3] MdeModulePkg: Fix Memory Attributes table type
> issue
>
> According to the spec, each entry in the Memory Attributes table shall have 
> the same type as the region it was carved out of in the UEFI memory map.
> The current attribute uses RTData for PE Data, but it should be RTCode.
>
> This patch fixed the issue. It is validated with or without PropertiesTable.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: "Yao, Jiewen"
> Cc: "Ard Biesheuvel"
> Cc: "Gao, Liming"
> ---
> MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c | 6 --
> MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c | 114 +++--
> 2 files changed, 37 insertions(+), 83 deletions(-)
>
> diff --git a/MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c
> b/MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c
> index c84146a..416ed3d 100644
> --- a/MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c
> +++ b/MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c
> @@ -72,8 +72,6 @@ CoreGetMemoryMapPropertiesTable (
>
> extern EFI_PROPERTIES_TABLE mPropertiesTable;
>
> -BOOLEAN mIsConstructingMemoryAttributesTable = FALSE;
> -
> /**
> Install MemoryAttributesTable.
>
> @@ -105,8 +103,6 @@ InstallMemoryAttributesTable (
> return ;
> }
>
> - mIsConstructingMemoryAttributesTable = TRUE;
> -
> MemoryMapSize = 0;
> MemoryMap = NULL;
> Status = CoreGetMemoryMapPropertiesTable ( @@ -181,8 +177,6 @@
> InstallMemoryAttributesTable (
>
> Status = gBS->InstallConfigurationTable (, 
> MemoryAttributesTable);
> ASSERT_EFI_ERROR (Status);
> -
> - mIsConstructingMemoryAttributesTable = FALSE; }
>
> /**
> diff --git a/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c
> b/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c
> index 6e5ad03..ebe7096 100644
> --- a/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c
> +++ b/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c
> @@ -1,7 +1,7 @@
> /** @file
> UEFI PropertiesTable support
>
> -Copyright (c) 2015, Intel Corporation. All rights reserved.

> +Copyright (c) 2015 - 2016, Intel Corporation. All rights
> +reserved.

> This program and the accompanying materials are licensed and made
> available under the terms and conditions of the BSD License which
> accompanies this distribution. The full text of the license may be
> found at @@ -80,14 +80,7 @@ EFI_PROPERTIES_TABLE mPropertiesTable = {
>
> EFI_LOCK mPropertiesTableLock = EFI_INITIALIZE_LOCK_VARIABLE (TPL_NOTIFY);
>
> -//
> -// Temporary save for original memory map.
> -// This is for MemoryAttributesTable only.
> -//
> -extern BOOLEAN mIsConstructingMemoryAttributesTable;
> -EFI_MEMORY_DESCRIPTOR *mMemoryMapOrg;
> -UINTN mMemoryMapOrgSize;
> -UINTN mDescriptorSize;
> +BOOLEAN mPropertiesTableEnable;
>
> //
> // Below functions are for MemoryMap
> @@ -199,42 +192,6 @@ SortMemoryMap (
> }
>
> /**
> - Check if this memory entry spans across original memory map boundary.
> -
> - @param PhysicalStart The PhysicalStart of memory
> - @param NumberOfPages The NumberOfPages of memory
> -
> - @retval TRUE This memory entry spans across original memory map boundary.
> - @retval FALSE This memory entry does not span cross original memory map 
> boundary.
> -**/
> -STATIC
> -BOOLEAN
> -DoesEntrySpanAcrossBoundary (
> - IN UINT64 PhysicalStart,
> - IN UINT64 NumberOfPages
> - )
> -{
> - EFI_MEMORY_DESCRIPTOR *MemoryMapEntry;
> - EFI_MEMORY_DESCRIPTOR *MemoryMapEnd;
> - UINT64 MemoryBlockLength;
> -
> - MemoryMapEntry = mMemoryMapOrg;
> - MemoryMapEnd = (EFI_MEMORY_DESCRIPTOR *) ((UINT8 *) mMemoryMapOrg + 
> mMemoryMapOrgSize);
> - while (MemoryMapEntry < MemoryMapEnd) {
> - MemoryBlockLength = (UINT64) (EfiPagesToSize 
> (MemoryMapEntry->NumberOfPages));
> -
> - if ((MemoryMapEntry->PhysicalStart <= PhysicalStart) &&
> - (MemoryMapEntry->PhysicalStart + MemoryBlockLength > PhysicalStart) &&
> - (MemoryMapEntry->PhysicalStart + MemoryBlockLength < PhysicalStart + 
> EfiPagesToSize (NumberOfPages))) {
> - return TRUE;
> - }
> -
> - MemoryMapEntry = NEXT_MEMORY_DESCRIPTOR

Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table type issue

2016-02-23 Thread Yao, Jiewen 
Hi Ard
Liming gave me minor update comment, and I have finished V3.

Should I wait for your validation on AArch64?

Thank you
Yao Jiewen

-Original Message-
From: Gao, Liming 
Sent: Tuesday, February 23, 2016 1:10 PM
To: Yao, Jiewen; edk2-de...@ml01.01.org
Cc: Ard Biesheuvel
Subject: RE: [patch V3] MdeModulePkg: Fix Memory Attributes table type issue


Reviewed-by: Liming Gao  -Original Message-
From: Yao, Jiewen
Sent: Tuesday, February 23, 2016 12:47 PM
To: edk2-de...@ml01.01.org
Cc: Yao, Jiewen ; Ard Biesheuvel 
; Gao, Liming 
Subject: [patch V3] MdeModulePkg: Fix Memory Attributes table type issue

According to the spec, each entry in the Memory Attributes table shall have the 
same type as the region it was carved out of in the UEFI memory map.
The current attribute uses RTData for PE Data, but it should be RTCode.

This patch fixed the issue. It is validated with or without PropertiesTable.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" 
Cc: "Ard Biesheuvel" 
Cc: "Gao, Liming" 
---
 MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c |   6 --
 MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c   | 114 +++--
 2 files changed, 37 insertions(+), 83 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c 
b/MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c
index c84146a..416ed3d 100644
--- a/MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c
+++ b/MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c
@@ -72,8 +72,6 @@ CoreGetMemoryMapPropertiesTable (
 
 extern EFI_PROPERTIES_TABLE  mPropertiesTable;
 
-BOOLEAN mIsConstructingMemoryAttributesTable = FALSE;
-
 /**
   Install MemoryAttributesTable.
 
@@ -105,8 +103,6 @@ InstallMemoryAttributesTable (
 return ;
   }
 
-  mIsConstructingMemoryAttributesTable = TRUE;
-
   MemoryMapSize = 0;
   MemoryMap = NULL;
   Status = CoreGetMemoryMapPropertiesTable ( @@ -181,8 +177,6 @@ 
InstallMemoryAttributesTable (
 
   Status = gBS->InstallConfigurationTable (, 
MemoryAttributesTable);
   ASSERT_EFI_ERROR (Status);
-
-  mIsConstructingMemoryAttributesTable = FALSE;  }
 
 /**
diff --git a/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c 
b/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c
index 6e5ad03..ebe7096 100644
--- a/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c
+++ b/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c
@@ -1,7 +1,7 @@
 /** @file
   UEFI PropertiesTable support
 
-Copyright (c) 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD License  which accompanies this 
distribution.  The full text of the license may be found at @@ -80,14 +80,7 @@ 
EFI_PROPERTIES_TABLE  mPropertiesTable = {
 
 EFI_LOCK   mPropertiesTableLock = EFI_INITIALIZE_LOCK_VARIABLE 
(TPL_NOTIFY);
 
-//
-// Temporary save for original memory map.
-// This is for MemoryAttributesTable only.
-//
-extern BOOLEAN mIsConstructingMemoryAttributesTable;
-EFI_MEMORY_DESCRIPTOR  *mMemoryMapOrg;
-UINTN  mMemoryMapOrgSize;
-UINTN  mDescriptorSize;
+BOOLEANmPropertiesTableEnable;
 
 //
 // Below functions are for MemoryMap
@@ -199,42 +192,6 @@ SortMemoryMap (
 }
 
 /**
-  Check if this memory entry spans across original memory map boundary.
-
-  @param PhysicalStart   The PhysicalStart of memory
-  @param NumberOfPages   The NumberOfPages of memory
-
-  @retval TRUE  This memory entry spans across original memory map boundary.
-  @retval FALSE This memory entry does not span cross original memory map 
boundary.
-**/
-STATIC
-BOOLEAN
-DoesEntrySpanAcrossBoundary (
-  IN UINT64  PhysicalStart,
-  IN UINT64  NumberOfPages
-  )
-{
-  EFI_MEMORY_DESCRIPTOR   *MemoryMapEntry;
-  EFI_MEMORY_DESCRIPTOR   *MemoryMapEnd;
-  UINT64  MemoryBlockLength;
-
-  MemoryMapEntry = mMemoryMapOrg;
-  MemoryMapEnd   = (EFI_MEMORY_DESCRIPTOR *) ((UINT8 *) mMemoryMapOrg + 
mMemoryMapOrgSize);
-  while (MemoryMapEntry < MemoryMapEnd) {
-MemoryBlockLength = (UINT64) (EfiPagesToSize 
(MemoryMapEntry->NumberOfPages));
-
-if ((MemoryMapEntry->PhysicalStart <= PhysicalStart) &&
-(MemoryMapEntry->PhysicalStart + MemoryBlockLength > PhysicalStart) &&
-(MemoryMapEntry->PhysicalStart + MemoryBlockLength < PhysicalStart + 
EfiPagesToSize (NumberOfPages))) {
-  return TRUE;
-}
-
-MemoryMapEntry = NEXT_MEMORY_DESCRIPTOR (MemoryMapEntry, mDescriptorSize);
-  }
-  return FALSE;
-}
-
-/**
   Merge continous memory map entries whose have same attributes.
 
   @param  MemoryMap  A pointer to the buffer in which firmware 
places
@@ -271,8

Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table type issue

2016-02-22 Thread Gao, Liming 

Reviewed-by: Liming Gao 
-Original Message-
From: Yao, Jiewen 
Sent: Tuesday, February 23, 2016 12:47 PM
To: edk2-de...@ml01.01.org
Cc: Yao, Jiewen ; Ard Biesheuvel 
; Gao, Liming 
Subject: [patch V3] MdeModulePkg: Fix Memory Attributes table type issue

According to the spec, each entry in the Memory
Attributes table shall have the same type as
the region it was carved out of in the UEFI memory map.
The current attribute uses RTData for PE Data, but
it should be RTCode.

This patch fixed the issue. It is validated with or
without PropertiesTable.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" 
Cc: "Ard Biesheuvel" 
Cc: "Gao, Liming" 
---
 MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c |   6 --
 MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c   | 114 +++--
 2 files changed, 37 insertions(+), 83 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c 
b/MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c
index c84146a..416ed3d 100644
--- a/MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c
+++ b/MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c
@@ -72,8 +72,6 @@ CoreGetMemoryMapPropertiesTable (
 
 extern EFI_PROPERTIES_TABLE  mPropertiesTable;
 
-BOOLEAN mIsConstructingMemoryAttributesTable = FALSE;
-
 /**
   Install MemoryAttributesTable.
 
@@ -105,8 +103,6 @@ InstallMemoryAttributesTable (
 return ;
   }
 
-  mIsConstructingMemoryAttributesTable = TRUE;
-
   MemoryMapSize = 0;
   MemoryMap = NULL;
   Status = CoreGetMemoryMapPropertiesTable (
@@ -181,8 +177,6 @@ InstallMemoryAttributesTable (
 
   Status = gBS->InstallConfigurationTable (, 
MemoryAttributesTable);
   ASSERT_EFI_ERROR (Status);
-
-  mIsConstructingMemoryAttributesTable = FALSE;
 }
 
 /**
diff --git a/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c 
b/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c
index 6e5ad03..ebe7096 100644
--- a/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c
+++ b/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c
@@ -1,7 +1,7 @@
 /** @file
   UEFI PropertiesTable support
 
-Copyright (c) 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -80,14 +80,7 @@ EFI_PROPERTIES_TABLE  mPropertiesTable = {
 
 EFI_LOCK   mPropertiesTableLock = EFI_INITIALIZE_LOCK_VARIABLE 
(TPL_NOTIFY);
 
-//
-// Temporary save for original memory map.
-// This is for MemoryAttributesTable only.
-//
-extern BOOLEAN mIsConstructingMemoryAttributesTable;
-EFI_MEMORY_DESCRIPTOR  *mMemoryMapOrg;
-UINTN  mMemoryMapOrgSize;
-UINTN  mDescriptorSize;
+BOOLEANmPropertiesTableEnable;
 
 //
 // Below functions are for MemoryMap
@@ -199,42 +192,6 @@ SortMemoryMap (
 }
 
 /**
-  Check if this memory entry spans across original memory map boundary.
-
-  @param PhysicalStart   The PhysicalStart of memory
-  @param NumberOfPages   The NumberOfPages of memory
-
-  @retval TRUE  This memory entry spans across original memory map boundary.
-  @retval FALSE This memory entry does not span cross original memory map 
boundary.
-**/
-STATIC
-BOOLEAN
-DoesEntrySpanAcrossBoundary (
-  IN UINT64  PhysicalStart,
-  IN UINT64  NumberOfPages
-  )
-{
-  EFI_MEMORY_DESCRIPTOR   *MemoryMapEntry;
-  EFI_MEMORY_DESCRIPTOR   *MemoryMapEnd;
-  UINT64  MemoryBlockLength;
-
-  MemoryMapEntry = mMemoryMapOrg;
-  MemoryMapEnd   = (EFI_MEMORY_DESCRIPTOR *) ((UINT8 *) mMemoryMapOrg + 
mMemoryMapOrgSize);
-  while (MemoryMapEntry < MemoryMapEnd) {
-MemoryBlockLength = (UINT64) (EfiPagesToSize 
(MemoryMapEntry->NumberOfPages));
-
-if ((MemoryMapEntry->PhysicalStart <= PhysicalStart) &&
-(MemoryMapEntry->PhysicalStart + MemoryBlockLength > PhysicalStart) &&
-(MemoryMapEntry->PhysicalStart + MemoryBlockLength < PhysicalStart + 
EfiPagesToSize (NumberOfPages))) {
-  return TRUE;
-}
-
-MemoryMapEntry = NEXT_MEMORY_DESCRIPTOR (MemoryMapEntry, mDescriptorSize);
-  }
-  return FALSE;
-}
-
-/**
   Merge continous memory map entries whose have same attributes.
 
   @param  MemoryMap  A pointer to the buffer in which firmware 
places
@@ -271,8 +228,7 @@ MergeMemoryMap (
   if (((UINTN)NextMemoryMapEntry < (UINTN)MemoryMapEnd) &&
   (MemoryMapEntry->Type == NextMemoryMapEntry->Type) &&
   (MemoryMapEntry->Attribute == NextMemoryMapEntry->Attribute) &&
-  ((MemoryMapEntry->PhysicalStart + MemoryBlockLength) == 
NextMemoryMapEntry->PhysicalStart) &&
-