date:20160816

Re: [edk2] USB 3.1 Support in UEFI

2016-08-16 Thread Tian, Feng

DP support depends on the graphic card you are using. You need consult IHV 
rather than us☺

Thanks
Feng

From: GN Keshava [mailto:keshava...@gmail.com]
Sent: Tuesday, August 16, 2016 12:37 PM
To: Tian, Feng ; edk2-devel@lists.01.org
Subject: Re: [edk2] USB 3.1 Support in UEFI

Hello Feng,

Thank you for the reply.

I understood, USB type C displayport alternate mode needs mux switch, and hence 
should be supported by silicon vendor.

Whether DisplayPort is supported ? (not usb type c, i just need to use 
DisplayPort (instead of vga display, i want to use displayport and supported 
monitor and cable)).

Thanks again,
Keshava

On Mon, 15 Aug 2016 at 07:29 Tian, Feng 
> wrote:
Yes, UEFI bios supports those usb3.0 host controllers which follow XHCI 
spec(http://www.intel.com/content/www/us/en/io/universal-serial-bus/extensible-host-controler-interface-usb-xhci.html),
 and usb3.0 device.

As for usb 3.1, it's a little complicated. What I can say is we got feedback it 
works at the configuration of usb3.0/3.1 devices plus XHCI 1.1 compliance 
controllers.

Last, for USB Type-C and DisplayPort Alternate Mode on USB Type-C, it's totally 
transparent for UEFI USB host controller driver and usb device driver. It 
should be supported by platform/silicon driver to switch the MUX.

Thanks
Feng

-Original Message-
From: edk2-devel 
[mailto:edk2-devel-boun...@lists.01.org]
 On Behalf Of GN Keshava
Sent: Saturday, August 13, 2016 4:40 PM
To: edk2-devel@lists.01.org
Subject: [edk2] USB 3.1 Support in UEFI

Hi all,

I heard that UEFI supports USB3.0. Please confirm.
Also let me know if *USB3.1 is supported in UEFI?*

Als, It would be helpful if anybody please let me know DisplayPort or USB type 
C is supported in UEFI.

Thanks,
With regards,
Keshava
___
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] DHCP Automatic Configure at Driver Connect

2016-08-16 Thread Wu, Jiaxin

Eugene,

> > I mean I didn't know whether the *un-configured* status you want
> > contain *no policy setting * or not. But it doesn't matter now, from
> > your statement here, I know you don't care the policy setting.
> 
> Correct the static vs dhcp is irrelevant - it's the fact that the IP layer 
> comes up
> that is the issue.
> 
> > As I said in previous email, " The current behavior of Ip4Config2:
> > DHCP policy together with D.O.R.A process, which is the same case as
> > the old Ip4Config behavior ".
> 
> I'm confused by this statement because I can see a distinct difference in
> behavior from the past.  I can see the new code which enables the new
> behavior as well Ip4Config2OnDhcp4SbInstalled- when the DHCP SB is
> installed you do a configure automatically - this code simply did not exist
> before -- see Ip4Config2OnDhcp4SbInstalled.
> 

Ip4Config2OnDhcp4SbInstalled() maybe confused you, but it's not accurate as you 
said "when the DHCP SB is installed you do a configure automatically". It's 
more proper to say "IPv4 driver is requiring DHCP SB due to it detects the DHCP 
policy." In such a case, it's reasonable with the function 
Ip4Config2OnDhcp4SbInstalled().

  Status = NetLibCreateServiceChild (
 IpSb->Controller,
 IpSb->Image,
 ,
 >Dhcp4Handle
 );

  if (Status == EFI_UNSUPPORTED) {
//
// No DHCPv4 Service Binding protocol, register a notify.
//
if (Instance->Dhcp4SbNotifyEvent == NULL) {
  Instance->Dhcp4SbNotifyEvent = EfiCreateProtocolNotifyEvent (
   ,
   TPL_CALLBACK,
   Ip4Config2OnDhcp4SbInstalled,
   (VOID *) Instance,
   >Registration
   );
}
  }  

I agree with you this code did not exist in *Ip4Dxe* before. We implemented 
this function because of we need start the AutoConfig due to the DHCP policy is 
detected by Ip4Dxe driver (DHCP policy (note: NOT DHCP SB) together with 
D.O.R.A process). It does may appear AutoConfig straight away with DHCP SB if 
Ip4Dxe ahead of Dhcp4Dxe. But the precondition is that the DHCP policy has been 
detected.  If the policy is not DHCP during the system boot, I think your 
concern will not appear.

Now, compared to old Ip4Config behavior, we take 'ifconfig' tool command as 
example - "ifconfig -s eth0 dhcp":
The Ip4Config->Start will be invoked to start the auto configuration. It was 
implemented in the deprecated driver -- Ip4ConfigDxe. When the system boot next 
time, the previous IP configuration will cleaned and the interface will be in 
UN-CONFIG status again.  Current implementation don't have this clean-up 
operation no matter Static/DHCP policy has been set. Is this the difference you 
mentioned? 

> > From the case you described here, are you want to separate the DHCP
> > policy setting and D.O.R.A process? We don't know.
> 
> Yes, You could say I want to separate the DHCP vs static policy from D.O.R.A.
> but I don't think that's a good way to state it - I would state that we don't
> want the IP protocol (whether it be DHCP or statically configured) to be "up"
> until a piece of UEFI calls Configure().
> 
> > The provided solution for you (such a DXE Driver) is only based on you
> > want an *un-configured* status at each boot time until the third part
> > configuration. I think it does an approach for this. But I think Ting
> > is right, "we need fully understand your usage case before analyzing
> > the problem". Perhaps you have more detailed requirements we don't
> > know clearly.
> 
> We want the IP config information stored in NVRAM (dhcp or static) to be
> preserved but want a separate policy choice to delay the IP interface coming
> "up" until a component calls Configure().

Now, let us  consider your requirement: 
1) The IP config information stored in NVRAM 
2) A separate policy to delay the IP interface coming up until a component 
calls Configure ().

#1 is also the current implementation. For 2), I remember you have one patch to 
do this implementation, can you share it to us for better understanding? 


> 
> Eugene
> 
> 
> 
> 
> ___
> 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] UefiCpuPkg: MTRR_PHYSMASK.Valid should be one bit instead of 8 bits

2016-08-16 Thread Tian, Feng

Reviewed-by: Feng Tian 

Thanks
Feng

-Original Message-
From: Ni, Ruiyu 
Sent: Monday, August 15, 2016 4:41 PM
To: edk2-devel@lists.01.org
Cc: Tian, Feng 
Subject: [PATCH] UefiCpuPkg: MTRR_PHYSMASK.Valid should be one bit instead of 8 
bits

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Feng Tian 
---
 UefiCpuPkg/Include/Register/ArchitecturalMsr.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/UefiCpuPkg/Include/Register/ArchitecturalMsr.h 
b/UefiCpuPkg/Include/Register/ArchitecturalMsr.h
index a4702ed..4d4ade4 100644
--- a/UefiCpuPkg/Include/Register/ArchitecturalMsr.h
+++ b/UefiCpuPkg/Include/Register/ArchitecturalMsr.h
@@ -2092,7 +2092,7 @@ typedef union {
 ///
 /// [Bit 11] Valid Enable range mask.
 ///
-UINT32  V:8;
+UINT32  V:1;
 ///
 /// [Bits 31:12] PhysMask.  MTRR address range mask.
 ///
-- 
2.9.0.windows.1

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

[edk2] [PATCH] PcAtChipsetPkg AcpiTimerLib: Wait 363 ACPI timer counts to get TSC Freq

2016-08-16 Thread Star Zeng

Compute the number of ticks to wait to measure TSC frequency.
Instead of (ACPI_TIMER_FREQUENCY / 1) = 357 and 357 * 1 = 357,
use 363 * 9861 = 3579543 Hz which is within 2 Hz of ACPI_TIMER_FREQUENCY.
363 counts is a calibration time of 101.4 uS.

The idea comes from Michael and Paolo.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Paolo Bonzini 
Cc: Paul A Lohr 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 PcAtChipsetPkg/Library/AcpiTimerLib/AcpiTimerLib.c | 32 +-
 .../Library/AcpiTimerLib/BaseAcpiTimerLib.c| 14 +-
 .../Library/AcpiTimerLib/DxeAcpiTimerLib.c | 14 +-
 3 files changed, 33 insertions(+), 27 deletions(-)

diff --git a/PcAtChipsetPkg/Library/AcpiTimerLib/AcpiTimerLib.c 
b/PcAtChipsetPkg/Library/AcpiTimerLib/AcpiTimerLib.c
index e6fea231123d..020031e3f4a5 100644
--- a/PcAtChipsetPkg/Library/AcpiTimerLib/AcpiTimerLib.c
+++ b/PcAtChipsetPkg/Library/AcpiTimerLib/AcpiTimerLib.c
@@ -340,13 +340,13 @@ GetTimeInNanoSecond (
   Calculate TSC frequency.
 
   The TSC counting frequency is determined by comparing how far it counts
-  during a 100us period as determined by the ACPI timer. The ACPI timer is
-  used because it counts at a known frequency.
-  The TSC is sampled, followed by waiting for ACPI_TIMER_FREQUENCY / 1
-  clocks of the ACPI timer, or 100us. The TSC is then sampled again. The
-  difference multiplied by 1 is the TSC frequency. There will be a small
-  error because of the overhead of reading the ACPI timer. An attempt is
-  made to determine and compensate for this error.
+  during a 101.4 us period as determined by the ACPI timer.
+  The ACPI timer is used because it counts at a known frequency.
+  The TSC is sampled, followed by waiting 363 counts of the ACPI timer,
+  or 101.4 us. The TSC is then sampled again. The difference multiplied by
+  9861 is the TSC frequency. There will be a small error because of the
+  overhead of reading the ACPI timer. An attempt is made to determine and
+  compensate for this error.
 
   @return The number of TSC counts per second.
 
@@ -366,22 +366,28 @@ InternalCalculateTscFrequency (
   InterruptState = SaveAndDisableInterrupts ();
 
   TimerAddr = InternalAcpiGetAcpiTimerIoPort ();
-  Ticks = IoRead32 (TimerAddr) + (ACPI_TIMER_FREQUENCY / 1);// Set 
Ticks to 100us in the future
+  //
+  // Compute the number of ticks to wait to measure TSC frequency.
+  // Use 363 * 9861 = 3579543 Hz which is within 2 Hz of ACPI_TIMER_FREQUENCY.
+  // 363 counts is a calibration time of 101.4 uS.
+  //
+  Ticks = IoRead32 (TimerAddr) + 363;
 
   StartTSC = AsmReadTsc (); // Get 
base value for the TSC
   //
-  // Wait until the ACPI timer has counted 100us.
+  // Wait until the ACPI timer has counted 101.4 us.
   // Timer wrap-arounds are handled correctly by this function.
-  // When the current ACPI timer value is greater than 'Ticks', the while loop 
will exit.
+  // When the current ACPI timer value is greater than 'Ticks',
+  // the while loop will exit.
   //
   while (((Ticks - IoRead32 (TimerAddr)) & BIT23) == 0) {
 CpuPause();
   }
-  EndTSC = AsmReadTsc ();   // TSC 
value 100us later
+  EndTSC = AsmReadTsc ();   // TSC 
value 101.4 us later
 
   TscFrequency = MultU64x32 (
-   (EndTSC - StartTSC), // Number 
of TSC counts in 100us
-   1// Number 
of 100us in a second
+   (EndTSC - StartTSC), // Number 
of TSC counts in 101.4 us
+   9861 // Number 
of 101.4 us in a second
);
 
   SetInterruptState (InterruptState);
diff --git a/PcAtChipsetPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.c 
b/PcAtChipsetPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.c
index 8819ebcfccef..29521f8b220b 100644
--- a/PcAtChipsetPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.c
+++ b/PcAtChipsetPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.c
@@ -20,13 +20,13 @@
   Calculate TSC frequency.
 
   The TSC counting frequency is determined by comparing how far it counts
-  during a 100us period as determined by the ACPI timer. The ACPI timer is
-  used because it counts at a known frequency.
-  The TSC is sampled, followed by waiting for ACPI_TIMER_FREQUENCY / 1
-  clocks of the ACPI timer, or 100us. The TSC is then sampled again. The
-  difference multiplied by 1 is the TSC frequency. There will be a small
-  error because of the overhead of reading the ACPI timer. An attempt is
-  made to determine and compensate for this error.
+  during a 101.4 us period as determined by the ACPI timer.
+  The ACPI timer is used

Re: [edk2] IP4 Config Troubles with DHCP

2016-08-16 Thread Wu, Jiaxin

Eugene,

> > Yeah. When I was drafting the UDP APP to test the new fix, I found the
> > same case you mentioned. We must issue another UDP Configure () to
> > clean the previous state once the  Ip4Mode.IsConfigured is TRUE. So,
> > the above example is not accurate with my the current
> > implementation:(. But I'm still not recommend to loop the UDP
> > configuration every time if Ip4Mode.IsConfigured is false. The right
> > behavior for UDP/TCP is 1) timer check the Ip4Mode.IsConfigured, 2)
> > Once Ip4Mode.IsConfigured is TRUE, reconfigure the instance again.
> > Sorry for the above example was troubling you. Also use UDP as
> > example, correct as below:
> 
> Can't we just call this a defect and make it so the first Configure() that 
> returns
> IsConfigured=TRUE works?  It seems much safer to handle this in the stack
> than to expect hundreds or thousands of different network applications and
> services to try to implement this sequence correctly.
> 
> I don't see where in the UEFI spec it states that you must call Configure(cfg)
> Configure(NULL) Configure(cfg) just to make it work...

For the Spec or API itself part, I can't deem the current implementation of 
Configure() as a defect. EFI_NO_MAPPING means the configuration is not finished 
yet due to the underlying driver unavailable.  So, from the point of view of 
those Configure() APIs, the up caller should recall the Configure() again until 
EFI_SUCCESS returned.

I thought we could call  the corresponding UDP.GetModeData() to know UDP itself 
configured data (not the underlying driver state), but EFI_NOT_STARTED is 
returned directly if it's not configured properly. 

I think it's easy to update the implementation to avoid those sequence calling, 
but the behavior changed, which will affect many existing application/up 
caller. So, let's keep the current implementation.



> 
> Thanks,
> 
> Eugene
> ___
> 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

[edk2] Do BSPs only have to be logical thread 0 ?

2016-08-16 Thread Shubha Ramani

In other words, suppose a BSP  is running in hyperthreaded ON mode and it has 2 
threads per physical core. Can the BSP be either thread 0 or thread 1 ?Is this 
documented somewhere ?
Thanks,
Shubha Shubha D. ramanishubharam...@gmail.com
shubharam...@yahoo.com
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] IP4 Config Troubles with DHCP

2016-08-16 Thread Cohen, Eugene

Jiaxin,

> Yeah. When I was drafting the UDP APP to test the new fix, I found the
> same case you mentioned. We must issue another UDP Configure () to
> clean the previous state once the  Ip4Mode.IsConfigured is TRUE. So,
> the above example is not accurate with my the current
> implementation:(. But I'm still not recommend to loop the UDP
> configuration every time if Ip4Mode.IsConfigured is false. The right
> behavior for UDP/TCP is 1) timer check the Ip4Mode.IsConfigured, 2)
> Once Ip4Mode.IsConfigured is TRUE, reconfigure the instance again.
> Sorry for the above example was troubling you. Also use UDP as
> example, correct as below:

Can't we just call this a defect and make it so the first Configure() that 
returns IsConfigured=TRUE works?  It seems much safer to handle this in the 
stack than to expect hundreds or thousands of different network applications 
and services to try to implement this sequence correctly.

I don't see where in the UEFI spec it states that you must call Configure(cfg) 
Configure(NULL) Configure(cfg) just to make it work...

Thanks,

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

Re: [edk2] DHCP Automatic Configure at Driver Connect

2016-08-16 Thread Cohen, Eugene

Jiaxin,
 
> I mean I didn't know whether the *un-configured* status you want
> contain *no policy setting * or not. But it doesn't matter now, from
> your statement here, I know you don't care the policy setting.

Correct the static vs dhcp is irrelevant - it's the fact that the IP layer 
comes up that is the issue.

> As I said in previous email, " The current behavior of Ip4Config2: DHCP
> policy together with D.O.R.A process, which is the same case as the old
> Ip4Config behavior ". 

I'm confused by this statement because I can see a distinct difference in 
behavior from the past.  I can see the new code which enables the new behavior 
as well Ip4Config2OnDhcp4SbInstalled- when the DHCP SB is installed you do a 
configure automatically - this code simply did not exist before -- see 
Ip4Config2OnDhcp4SbInstalled.

> From the case you described here, are you want
> to separate the DHCP policy setting and D.O.R.A process? We don't
> know.

Yes, You could say I want to separate the DHCP vs static policy from D.O.R.A. 
but I don't think that's a good way to state it - I would state that we don't 
want the IP protocol (whether it be DHCP or statically configured) to be "up" 
until a piece of UEFI calls Configure().
 
> The provided solution for you (such a DXE Driver) is only based on you
> want an *un-configured* status at each boot time until the third part
> configuration. I think it does an approach for this. But I think Ting is
> right, "we need fully understand your usage case before analyzing the
> problem". Perhaps you have more detailed requirements we don't
> know clearly.

We want the IP config information stored in NVRAM (dhcp or static) to be 
preserved but want a separate policy choice to delay the IP interface coming 
"up" until a component calls Configure().

Eugene




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

Re: [edk2] DHCP Automatic Configure at Driver Connect

2016-08-16 Thread Cohen, Eugene

 
> Hi Eugene,
> 
> I think we need fully understand your usage before analyzing the
> problem. Could you please explain more details? You mentioned you
> only wanted to enable the network interface when directed by an
> application. If so, is it possible that you don't connect your network
> device until you really need that?
> 
> Thanks,
> Ting

Ting,

I agree that if we could suppress driver connection for the network devices 
then that would result in the network being disabled.  Our use case is that we 
still want to connect all drivers but not have the network start until directed 
through a Configure() call.

Thanks,

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

Re: [edk2] [staging/HTTPS-TLS][PATCH 0/2] Readme.MD and TlsAuthConfigDxe update

2016-08-16 Thread Samer El Haj Mahmoud

Series reviewed-by: Samer El-Haj-Mahmoud 




Samer El-Haj-Mahmoud
SESM - OS / SW Architect
Systems Management Development, Data Center Group
Lenovo United States
+1.919.908.5833
+1.512.659.1523
smahm...@lenovo.com
 

Lenovo.com /us 
Twitter | Facebook | Instagram | Blogs | Forums






-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jiaxin Wu
Sent: Tuesday, August 16, 2016 3:20 AM
To: edk2-devel@lists.01.org
Cc: Ye Ting ; Fu Siyuan ; Long Qin 

Subject: [edk2] [staging/HTTPS-TLS][PATCH 0/2] Readme.MD and TlsAuthConfigDxe 
update

Cc: Palmer Thomas 
Cc: Long Qin 
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 

Jiaxin Wu (2):
  Readme.MD: Clarify the feature support scope
  NetworkPkg/TlsAuthConfigDxe: TlsCaCertificate variable attribute update

 NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.c | 2 +-  
NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.h | 2 ++
 Readme.MD   | 8 +++-
 3 files changed, 10 insertions(+), 2 deletions(-)

--
1.9.5.msysgit.1

___
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] Setting BuildOptions by module type does not seem to work

2016-08-16 Thread Gao, Liming

Andrew:
  I got your point. Yes. The precedence rules can be updated to reflect their 
order.

Thanks
Liming
From: af...@apple.com [mailto:af...@apple.com]
Sent: Wednesday, August 17, 2016 12:28 AM
To: Gao, Liming 
Cc: Kurt Kennett ; edk2-devel 

Subject: Re: [edk2] Setting BuildOptions by module type does not seem to work


> On Aug 16, 2016, at 9:21 AM, Gao, Liming wrote:
>
> Andrew:
> arch value may be common. 3.3.1 Common Definitions, ::= {"IA32"} {"X64"} 
> {"IPF"} {"EBC"} {} {"common"}.
> I agree [BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER should be supported. 
> We will look it.
>

I agree but precedence rules seem different for *.*.*.Edk2ModuleType. It should 
follow $(arch) overrides common pattern of the other examples?

• Highest, DSC file’s component scoped for individual INF files.
• [BuildOptions.$(arch).CodeBase.Edk2ModuleType]
missing [BuildOptions.common.CodeBase.Edk2ModuleType]
• [BuildOptions.$(arch).CodeBase]
• [BuildOptions.common.CodeBase]
• [BuildOptions.$(arch)]
• [BuildOptions.common]
• [BuildOptions]
• INF File’s [BuildOptions] section
• Lowest - tools_def.txt entry

Thanks,

Andrew Fish


> Thanks
> Liming
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Tuesday, August 16, 2016 11:47 PM
> To: Kurt Kennett
> Cc: edk2-devel ; Gao, Liming
> Subject: Re: [edk2] Setting BuildOptions by module type does not seem to work
>
>
>> On Aug 16, 2016, at 8:22 AM, Kurt Kennett wrote:
>>
>> Thanks for your help, Andre. I appreciate it. ☺
>>
>> [BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER]
>> Does not work.
>>
>
> Can you file a bugzilla report on the tools, and another on the spec to 
> mention BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER
>
> Thanks,
>
> Andrew Fish
>
>> [BuildOptions.AARCH64.common.EDKII.DXE_RUNTIME_DRIVER]
>> Does not work.
>>
>> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
>> Works.
>>
>>
>> K2
>>
>> From: af...@apple.com [mailto:af...@apple.com]
>> Sent: Tuesday, August 16, 2016 8:15 AM
>> To: Kurt Kennett
>> Cc: Gao, Liming ; edk2-devel
>> Subject: Re: [edk2] Setting BuildOptions by module type does not seem to work
>>
>>
>> On Aug 16, 2016, at 7:49 AM, Kurt Kennett 
>> > wrote:
>>
>> Hi Liming. I’m a bit confused by your email.
>>
>> I my original email below, I reference directly:
>>
 DSC spec (January 2016 1.26) says I can do this:

 (Section 3.6 pp 76)
>>
>>
>> In this section it says:
>>
>> …
>> Build options priority (appended from lowest to highest and/or highest 
>> replacement) is:
>> • Highest, DSC file’s component scoped for individual INF files.
>> • [BuildOptions.$(arch).CodeBase.Edk2ModuleType]
>> • [BuildOptions.$(arch).CodeBase]
>> • [BuildOptions.common.CodeBase]
>> • [BuildOptions.$(arch)]
>> • [BuildOptions.common]
>> • [BuildOptions]
>> • INF File’s [BuildOptions] section
>> • Lowest - tools_def.txt entry
>>
>> In the “Prototype” section immediately below this (Page 79) is the grammar.
>>
>> There is no interpretation of the grammar corresponds to
>>
>> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
>>
>> Kurt,
>>
>> It looks like a bug in the spec as there is a missing Edk2ModuleType common 
>> type.
>> • [BuildOptions.$(arch).CodeBase.Edk2ModuleType]
>> • [BuildOptions.common.CodeBase.Edk2ModuleType]
>> • [BuildOptions.$(arch).CodeBase]
>>
>> Or I guess you could interpret the spec that the last 
>> BuildOptions.$(arch).CodeBase.Edk2ModuleType wins either common or matching 
>> $(arch)?
>>
>> Did [BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER] not work? Did you try 
>> without the illegal entry 
>> [BuildOptions.AARCH64.common.EDKII.DXE_RUNTIME_DRIVER]
>>
>> Thanks,
>>
>> Andrew Fish
>>
>>
>>
>> Which is the format that actually works in the code.
>>
>> Is there some other section or interpretation that you are referring to?
>>
>> K2
>>
>> From: Gao, Liming [mailto:liming@intel.com]
>> Sent: Monday, August 15, 2016 7:17 PM
>> To: Kurt Kennett 
>> >; 
>> af...@apple.com
>> Cc: edk2-devel >
>> Subject: RE: [edk2] Setting BuildOptions by module type does not seem to work
>>
>> Hi,
>> This style has been defined in DSC spec 1.26. It can be downloaded from 
>> https://github.com/tianocore/tianocore.github.io/wiki/EDK%20II%20Specifications
>>
>> Thanks
>> Liming
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Kurt 
>> Kennett
>> Sent: Tuesday, August 16, 2016 1:56 AM
>> To: af...@apple.com
>> Cc: edk2-devel >
>> Subject: Re: [edk2] Setting BuildOptions by module type does not seem to work
>>
>> Okay this seems to work:
>>
>> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
>>
>> Thanks Andrew.
>>

Re: [edk2] [MdeModulePkg][PeiCore] I seemed to have crashed the PEI Core by grabbing memory from PeiTemporaryRamBase?

2016-08-16 Thread Gao, Liming

Andrew:
  PI spec has not defined such information. But, PPI implementation and PeiCore 
needs to align new heap and stack layout. The full PPI should include new heap 
base and new stack base. Current PPI has only one Base. Then, PPI 
implementation needs mach PeiCore implementation.

Thanks
Liming
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew 
Fish
Sent: Tuesday, August 16, 2016 12:12 AM
To: Gao, Liming 
Cc: edk2-devel 
Subject: Re: [edk2] [MdeModulePkg][PeiCore] I seemed to have crashed the PEI 
Core by grabbing memory from PeiTemporaryRamBase?

> On Aug 15, 2016, at 8:54 AM, Gao, Liming wrote:
>
> Andrew:
> In permanent memory, PeiCore places heap base as stack top. Heap is above 
> stack. There is no hole between them. SEC needs to follow this layout and 
> migrate the temporary memory to permanent memory. It should copy TemporaryRam 
> HEAP and STACK range separately. HEAP range is specified by 
> PeiTemporaryRamBase and PeiTemporaryRamSize, and STACK range is specified by 
> StackBase and StackSize. The grabbed memory is not migrated, because PeiCore 
> doesn't know it. But, EmulatorPkg Sec SecTemporaryRamSupport() migrates the 
> whole temporary memory together. The grabbed memory is also migrated and 
> wrongly regarded as heap data. So, the fix is to update 
> SecTemporaryRamSupport() implementation in SEC.
>

Limiing,

I don't see any info in the PPI definition or the PI spec that defines the heap 
and stack are copied separately? The PPI just passes the entire ranges? That is 
why I assumes in the PPI case the offsets should be relative to the big shift?

/**
This service of the EFI_PEI_TEMPORARY_RAM_SUPPORT_PPI that migrates temporary 
RAM into
permanent memory.

@param PeiServices Pointer to the PEI Services Table.
@param TemporaryMemoryBase Source Address in temporary memory from which the 
SEC or PEIM will copy the
Temporary RAM contents.
@param PermanentMemoryBase Destination Address in permanent memory into which 
the SEC or PEIM will copy the
Temporary RAM contents.
@param CopySize Amount of memory to migrate from temporary to permanent memory.

@retval EFI_SUCCESS The data was successfully returned.
@retval EFI_INVALID_PARAMETER PermanentMemoryBase + CopySize > 
TemporaryMemoryBase when
TemporaryMemoryBase > PermanentMemoryBase.

**/
typedef
EFI_STATUS
(EFIAPI * TEMPORARY_RAM_MIGRATION)(
IN CONST EFI_PEI_SERVICES **PeiServices,
IN EFI_PHYSICAL_ADDRESS TemporaryMemoryBase,
IN EFI_PHYSICAL_ADDRESS PermanentMemoryBase,
IN UINTN CopySize
);

Thanks,

Andrew Fish

> Thanks
> Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew 
> Fish
> Sent: Saturday, August 13, 2016 7:25 AM
> To: edk2-devel
> Subject: [edk2] [MdeModulePkg][PeiCore] I seemed to have crashed the PEI Core 
> by grabbing memory from PeiTemporaryRamBase?
>
> I grabbed some memory between SEC and the PEI Core by adjusting SecCoreData-> 
> PeiTemporaryRamBase and SecCoreData-> PeiTemporaryRamSize.
>
> When looking at the code I don't really understand the logic of the 
> algorithm? So maybe I'm doing something wrong.
>
> This adjustment does not seem right to me?
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c#L768
> //
> // Heap Offset
> //
> BaseOfNewHeap = TopOfNewStack;
> if (BaseOfNewHeap >= (UINTN)SecCoreData->PeiTemporaryRamBase) {
> Private->HeapOffsetPositive = TRUE;
> Private->HeapOffset = (UINTN)(BaseOfNewHeap - 
> (UINTN)SecCoreData->PeiTemporaryRamBase);
> } else {
> Private->HeapOffsetPositive = FALSE;
> Private->HeapOffset = (UINTN)((UINTN)SecCoreData->PeiTemporaryRamBase - 
> BaseOfNewHeap);
> }
>
>
> The above code seems to be making a very strange adjustment. I noticed the 
> adjustment in my failing case was off by 0xC0 which is the amount of memory I 
> carved out prior to entering the PEI Core.
>
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c#L796
>
> //
> // Temporary Ram Support PPI is provided by platform, it will copy
> // temporary memory to permenent memory and do stack switching.
> // After invoking Temporary Ram Support PPI, the following code's
> // stack is in permanent memory.
> //
> TemporaryRamSupportPpi->TemporaryRamMigration (
> PeiServices,
> TemporaryRamBase,
> (EFI_PHYSICAL_ADDRESS)(UINTN)(TopOfNewStack - TemporaryStackSize),
> TemporaryRamSize
> );
>
>
> And this is also a case in which the stack got bigger. But it seems to me the 
> shift if really defined by TemporaryRamBase, TopOfNewStack, and 
> TemporaryStackSize in this case.
>
> The failure I hit was OldCoreData->Fv pointer was shifted so when the PPI was 
> called the system crashed. Is this a bug in the 
> gEfiTemporaryRamSupportPpiGuid path?
>
> If I changed the HeadOffset algorithm my crash went away? Private->HeapOffset 
> = ((UINTN)TopOfNewStack - TemporaryStackSize) - TemporaryRamBase;
>
>

Re: [edk2] [staging/HTTPS-TLS][PATCH 0/2] Readme.MD and TlsAuthConfigDxe update

2016-08-16 Thread Palmer, Thomas

Reviewed by Thomas Palmer 

-Original Message-
From: Jiaxin Wu [mailto:jiaxin...@intel.com] 
Sent: Tuesday, August 16, 2016 2:20 AM
To: edk2-devel@lists.01.org
Cc: Palmer, Thomas ; Long Qin ; Ye 
Ting ; Fu Siyuan 
Subject: [staging/HTTPS-TLS][PATCH 0/2] Readme.MD and TlsAuthConfigDxe update

Cc: Palmer Thomas 
Cc: Long Qin 
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 

Jiaxin Wu (2):
  Readme.MD: Clarify the feature support scope
  NetworkPkg/TlsAuthConfigDxe: TlsCaCertificate variable attribute update

 NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.c | 2 +-  
NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.h | 2 ++
 Readme.MD   | 8 +++-
 3 files changed, 10 insertions(+), 2 deletions(-)

--
1.9.5.msysgit.1

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

Re: [edk2] Setting BuildOptions by module type does not seem to work

2016-08-16 Thread Andrew Fish


> On Aug 16, 2016, at 9:21 AM, Gao, Liming  wrote:
> 
> Andrew:
>  arch value may be common. 3.3.1 Common Definitions,  ::= {"IA32"} 
> {"X64"} {"IPF"} {"EBC"} {} {"common"}.
>  I agree [BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER should be supported. 
> We will look it.
> 

I agree but precedence rules seem different for *.*.*.Edk2ModuleType. It should 
follow $(arch) overrides common pattern of the other examples?

• Highest, DSC file’s component scoped for individual INF files.
• [BuildOptions.$(arch).CodeBase.Edk2ModuleType]
missing [BuildOptions.common.CodeBase.Edk2ModuleType]
• [BuildOptions.$(arch).CodeBase]
• [BuildOptions.common.CodeBase]
• [BuildOptions.$(arch)]
• [BuildOptions.common]
• [BuildOptions]
• INF File’s [BuildOptions] section
• Lowest - tools_def.txt entry

Thanks,

Andrew Fish


> Thanks
> Liming
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Tuesday, August 16, 2016 11:47 PM
> To: Kurt Kennett 
> Cc: edk2-devel ; Gao, Liming 
> Subject: Re: [edk2] Setting BuildOptions by module type does not seem to work
> 
> 
>> On Aug 16, 2016, at 8:22 AM, Kurt Kennett wrote:
>> 
>> Thanks for your help, Andre. I appreciate it. ☺
>> 
>> [BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER]
>> Does not work.
>> 
> 
> Can you file a bugzilla report on the tools, and another on the spec to 
> mention BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER
> 
> Thanks,
> 
> Andrew Fish
> 
>> [BuildOptions.AARCH64.common.EDKII.DXE_RUNTIME_DRIVER]
>> Does not work.
>> 
>> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
>> Works.
>> 
>> 
>> K2
>> 
>> From: af...@apple.com [mailto:af...@apple.com]
>> Sent: Tuesday, August 16, 2016 8:15 AM
>> To: Kurt Kennett
>> Cc: Gao, Liming ; edk2-devel
>> Subject: Re: [edk2] Setting BuildOptions by module type does not seem to work
>> 
>> 
>> On Aug 16, 2016, at 7:49 AM, Kurt Kennett 
>> > wrote:
>> 
>> Hi Liming. I’m a bit confused by your email.
>> 
>> I my original email below, I reference directly:
>> 
 DSC spec (January 2016 1.26) says I can do this:
 
 (Section 3.6 pp 76)
>> 
>> 
>> In this section it says:
>> 
>> …
>> Build options priority (appended from lowest to highest and/or highest 
>> replacement) is:
>> • Highest, DSC file’s component scoped for individual INF files.
>> • [BuildOptions.$(arch).CodeBase.Edk2ModuleType]
>> • [BuildOptions.$(arch).CodeBase]
>> • [BuildOptions.common.CodeBase]
>> • [BuildOptions.$(arch)]
>> • [BuildOptions.common]
>> • [BuildOptions]
>> • INF File’s [BuildOptions] section
>> • Lowest - tools_def.txt entry
>> 
>> In the “Prototype” section immediately below this (Page 79) is the grammar.
>> 
>> There is no interpretation of the grammar corresponds to
>> 
>> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
>> 
>> Kurt,
>> 
>> It looks like a bug in the spec as there is a missing Edk2ModuleType common 
>> type.
>> • [BuildOptions.$(arch).CodeBase.Edk2ModuleType]
>> • [BuildOptions.common.CodeBase.Edk2ModuleType]
>> • [BuildOptions.$(arch).CodeBase]
>> 
>> Or I guess you could interpret the spec that the last 
>> BuildOptions.$(arch).CodeBase.Edk2ModuleType wins either common or matching 
>> $(arch)?
>> 
>> Did [BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER] not work? Did you try 
>> without the illegal entry 
>> [BuildOptions.AARCH64.common.EDKII.DXE_RUNTIME_DRIVER]
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>> 
>> 
>> Which is the format that actually works in the code.
>> 
>> Is there some other section or interpretation that you are referring to?
>> 
>> K2
>> 
>> From: Gao, Liming [mailto:liming@intel.com]
>> Sent: Monday, August 15, 2016 7:17 PM
>> To: Kurt Kennett 
>> >; 
>> af...@apple.com
>> Cc: edk2-devel >
>> Subject: RE: [edk2] Setting BuildOptions by module type does not seem to work
>> 
>> Hi,
>> This style has been defined in DSC spec 1.26. It can be downloaded from 
>> https://github.com/tianocore/tianocore.github.io/wiki/EDK%20II%20Specifications
>> 
>> Thanks
>> Liming
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Kurt 
>> Kennett
>> Sent: Tuesday, August 16, 2016 1:56 AM
>> To: af...@apple.com
>> Cc: edk2-devel >
>> Subject: Re: [edk2] Setting BuildOptions by module type does not seem to work
>> 
>> Okay this seems to work:
>> 
>> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
>> 
>> Thanks Andrew.
>> 
>> (doesn't match the spec though :) )
>> 
>> K2
>> 
>> -Original Message-
>> From: af...@apple.com [mailto:af...@apple.com]
>> Sent: Monday, August 15, 2016 10:30 AM
>> To: Kurt Kennett
>> Cc: edk2-devel
>> Subject: Re: [edk2] Setting

Re: [edk2] Setting BuildOptions by module type does not seem to work

2016-08-16 Thread Gao, Liming

Andrew:
  arch value may be common. 3.3.1 Common Definitions,  ::= {"IA32"} 
{"X64"} {"IPF"} {"EBC"} {} {"common"}.
  I agree [BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER should be supported. 
We will look it.

Thanks
Liming
From: af...@apple.com [mailto:af...@apple.com]
Sent: Tuesday, August 16, 2016 11:47 PM
To: Kurt Kennett 
Cc: edk2-devel ; Gao, Liming 
Subject: Re: [edk2] Setting BuildOptions by module type does not seem to work


> On Aug 16, 2016, at 8:22 AM, Kurt Kennett wrote:
>
> Thanks for your help, Andre. I appreciate it. ☺
>
> [BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER]
> Does not work.
>

Can you file a bugzilla report on the tools, and another on the spec to mention 
BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER

Thanks,

Andrew Fish

> [BuildOptions.AARCH64.common.EDKII.DXE_RUNTIME_DRIVER]
> Does not work.
>
> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> Works.
>
>
> K2
>
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Tuesday, August 16, 2016 8:15 AM
> To: Kurt Kennett
> Cc: Gao, Liming ; edk2-devel
> Subject: Re: [edk2] Setting BuildOptions by module type does not seem to work
>
>
> On Aug 16, 2016, at 7:49 AM, Kurt Kennett 
> > wrote:
>
> Hi Liming. I’m a bit confused by your email.
>
> I my original email below, I reference directly:
>
>>> DSC spec (January 2016 1.26) says I can do this:
>>>
>>> (Section 3.6 pp 76)
>
>
> In this section it says:
>
> …
> Build options priority (appended from lowest to highest and/or highest 
> replacement) is:
> • Highest, DSC file’s component scoped for individual INF files.
> • [BuildOptions.$(arch).CodeBase.Edk2ModuleType]
> • [BuildOptions.$(arch).CodeBase]
> • [BuildOptions.common.CodeBase]
> • [BuildOptions.$(arch)]
> • [BuildOptions.common]
> • [BuildOptions]
> • INF File’s [BuildOptions] section
> • Lowest - tools_def.txt entry
>
> In the “Prototype” section immediately below this (Page 79) is the grammar.
>
> There is no interpretation of the grammar corresponds to
>
> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
>
> Kurt,
>
> It looks like a bug in the spec as there is a missing Edk2ModuleType common 
> type.
> • [BuildOptions.$(arch).CodeBase.Edk2ModuleType]
> • [BuildOptions.common.CodeBase.Edk2ModuleType]
> • [BuildOptions.$(arch).CodeBase]
>
> Or I guess you could interpret the spec that the last 
> BuildOptions.$(arch).CodeBase.Edk2ModuleType wins either common or matching 
> $(arch)?
>
> Did [BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER] not work? Did you try 
> without the illegal entry 
> [BuildOptions.AARCH64.common.EDKII.DXE_RUNTIME_DRIVER]
>
> Thanks,
>
> Andrew Fish
>
>
>
> Which is the format that actually works in the code.
>
> Is there some other section or interpretation that you are referring to?
>
> K2
>
> From: Gao, Liming [mailto:liming@intel.com]
> Sent: Monday, August 15, 2016 7:17 PM
> To: Kurt Kennett 
> >; 
> af...@apple.com
> Cc: edk2-devel >
> Subject: RE: [edk2] Setting BuildOptions by module type does not seem to work
>
> Hi,
> This style has been defined in DSC spec 1.26. It can be downloaded from 
> https://github.com/tianocore/tianocore.github.io/wiki/EDK%20II%20Specifications
>
> Thanks
> Liming
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Kurt 
> Kennett
> Sent: Tuesday, August 16, 2016 1:56 AM
> To: af...@apple.com
> Cc: edk2-devel >
> Subject: Re: [edk2] Setting BuildOptions by module type does not seem to work
>
> Okay this seems to work:
>
> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
>
> Thanks Andrew.
>
> (doesn't match the spec though :) )
>
> K2
>
> -Original Message-
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Monday, August 15, 2016 10:30 AM
> To: Kurt Kennett
> Cc: edk2-devel
> Subject: Re: [edk2] Setting BuildOptions by module type does not seem to work
>
>
>> On Aug 15, 2016, at 9:34 AM, Kurt Kennett wrote:
>>
>> No, I had not tried that. I tried it now and it does not seem to work.
>>
>> I have:
>>
>> [BuildOptions.AARCH64.common]
>> *_VS2015x86_AARCH64_DLINK_FLAGS = /BORK
>>
>> [BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER]
>> *_VS2015x86_AARCH64_DLINK_FLAGS = /PLOR
>>
>> [BuildOptions.AARCH64.common.EDKII.DXE_RUNTIME_DRIVER]
>> *_VS2015x86_AARCH64_DLINK_FLAGS = /BONK
>>
>> And the only one that makes it to the command line is the /BORK one.
>>
>> (The tools do not complain about the specification of options as above).
>>
>
> I'm guessing the syntax checking is not very good?
> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> [BuildOptions.AARCH64.common.EDKII.DXE_RUNTIME_DRIVER]
>
> I see the

Re: [edk2] Setting BuildOptions by module type does not seem to work

2016-08-16 Thread Andrew Fish


> On Aug 16, 2016, at 8:22 AM, Kurt Kennett  wrote:
> 
> Thanks for your help, Andre. I appreciate it. ☺
> 
> [BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER]
> Does not work.
> 

Can you file a bugzilla report on the tools, and another on the spec to mention 
BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER

Thanks,

Andrew Fish

> [BuildOptions.AARCH64.common.EDKII.DXE_RUNTIME_DRIVER]
> Does not work.
> 
> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> Works.
> 
> 
> K2
> 
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Tuesday, August 16, 2016 8:15 AM
> To: Kurt Kennett 
> Cc: Gao, Liming ; edk2-devel 
> Subject: Re: [edk2] Setting BuildOptions by module type does not seem to work
> 
> 
> On Aug 16, 2016, at 7:49 AM, Kurt Kennett 
> > wrote:
> 
> Hi Liming.  I’m a bit confused by your email.
> 
> I my original email below, I reference directly:
> 
>>> DSC spec (January 2016 1.26) says I can do this:
>>> 
>>> (Section 3.6 pp 76)
> 
> 
> In this section it says:
> 
> …
> Build options priority (appended from lowest to highest and/or highest 
> replacement) is:
> • Highest, DSC file’s component scoped  for individual INF 
> files.
> • [BuildOptions.$(arch).CodeBase.Edk2ModuleType]
> • [BuildOptions.$(arch).CodeBase]
> • [BuildOptions.common.CodeBase]
> • [BuildOptions.$(arch)]
> • [BuildOptions.common]
> • [BuildOptions]
> • INF File’s [BuildOptions] section
> • Lowest - tools_def.txt entry
> 
> In the “Prototype” section immediately below this (Page 79) is the grammar.
> 
> There is no interpretation of the grammar corresponds to
> 
> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> 
> Kurt,
> 
> It looks like a bug in the spec as there is a missing Edk2ModuleType common 
> type.
> • [BuildOptions.$(arch).CodeBase.Edk2ModuleType]
> • [BuildOptions.common.CodeBase.Edk2ModuleType]
> • [BuildOptions.$(arch).CodeBase]
> 
> Or I guess you could interpret the spec that the last 
> BuildOptions.$(arch).CodeBase.Edk2ModuleType wins either common or matching 
> $(arch)?
> 
> Did [BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER] not work? Did you try 
> without the illegal entry 
> [BuildOptions.AARCH64.common.EDKII.DXE_RUNTIME_DRIVER]
> 
> Thanks,
> 
> Andrew Fish
> 
> 
> 
> Which is the format that actually works in the code.
> 
> Is there some other section or interpretation that you are referring to?
> 
> K2
> 
> From: Gao, Liming [mailto:liming@intel.com]
> Sent: Monday, August 15, 2016 7:17 PM
> To: Kurt Kennett 
> >; 
> af...@apple.com
> Cc: edk2-devel >
> Subject: RE: [edk2] Setting BuildOptions by module type does not seem to work
> 
> Hi,
>  This style has been defined in DSC spec 1.26. It can be downloaded from 
> https://github.com/tianocore/tianocore.github.io/wiki/EDK%20II%20Specifications
> 
> Thanks
> Liming
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Kurt 
> Kennett
> Sent: Tuesday, August 16, 2016 1:56 AM
> To: af...@apple.com
> Cc: edk2-devel >
> Subject: Re: [edk2] Setting BuildOptions by module type does not seem to work
> 
> Okay this seems to work:
> 
> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> 
> Thanks Andrew.
> 
> (doesn't match the spec though :) )
> 
> K2
> 
> -Original Message-
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Monday, August 15, 2016 10:30 AM
> To: Kurt Kennett
> Cc: edk2-devel
> Subject: Re: [edk2] Setting BuildOptions by module type does not seem to work
> 
> 
>> On Aug 15, 2016, at 9:34 AM, Kurt Kennett wrote:
>> 
>> No, I had not tried that. I tried it now and it does not seem to work.
>> 
>> I have:
>> 
>> [BuildOptions.AARCH64.common]
>> *_VS2015x86_AARCH64_DLINK_FLAGS = /BORK
>> 
>> [BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER]
>> *_VS2015x86_AARCH64_DLINK_FLAGS = /PLOR
>> 
>> [BuildOptions.AARCH64.common.EDKII.DXE_RUNTIME_DRIVER]
>> *_VS2015x86_AARCH64_DLINK_FLAGS = /BONK
>> 
>> And the only one that makes it to the command line is the /BORK one.
>> 
>> (The tools do not complain about the specification of options as above).
>> 
> 
> I'm guessing the syntax checking is not very good?
> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> [BuildOptions.AARCH64.common.EDKII.DXE_RUNTIME_DRIVER]
> 
> I see the [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER] form used in other 
> places, but you have an extra .common?
> 
> Thanks,
> 
> Andrew Fish
> 
>> K2
>> 
>> -Original Message-
>> From: af...@apple.com [mailto:af...@apple.com]
>> Sent: Monday, August 15, 2016 9:22 AM
>> To: Kurt Kennett
>> Cc: edk2-devel
>> Subject: Re: [edk2] Setting BuildOptions by module type does

Re: [edk2] Setting BuildOptions by module type does not seem to work

2016-08-16 Thread Kurt Kennett

Thanks for your help, Andre. I appreciate it. ☺

[BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER]
Does not work.

[BuildOptions.AARCH64.common.EDKII.DXE_RUNTIME_DRIVER]
Does not work.

[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
Works.

K2

From: af...@apple.com [mailto:af...@apple.com]
Sent: Tuesday, August 16, 2016 8:15 AM
To: Kurt Kennett 
Cc: Gao, Liming ; edk2-devel 
Subject: Re: [edk2] Setting BuildOptions by module type does not seem to work

On Aug 16, 2016, at 7:49 AM, Kurt Kennett 
> wrote:

Hi Liming.  I’m a bit confused by your email.

I my original email below, I reference directly:

>> DSC spec (January 2016 1.26) says I can do this:
>>
>> (Section 3.6 pp 76)

In this section it says:

…
Build options priority (appended from lowest to highest and/or highest 
replacement) is:
• Highest, DSC file’s component scoped  for individual INF files.
• [BuildOptions.$(arch).CodeBase.Edk2ModuleType]
• [BuildOptions.$(arch).CodeBase]
• [BuildOptions.common.CodeBase]
• [BuildOptions.$(arch)]
• [BuildOptions.common]
• [BuildOptions]
• INF File’s [BuildOptions] section
• Lowest - tools_def.txt entry

In the “Prototype” section immediately below this (Page 79) is the grammar.

There is no interpretation of the grammar corresponds to

[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]

Kurt,

It looks like a bug in the spec as there is a missing Edk2ModuleType common 
type.
• [BuildOptions.$(arch).CodeBase.Edk2ModuleType]
• [BuildOptions.common.CodeBase.Edk2ModuleType]
• [BuildOptions.$(arch).CodeBase]

Or I guess you could interpret the spec that the last 
BuildOptions.$(arch).CodeBase.Edk2ModuleType wins either common or matching 
$(arch)?

Did [BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER] not work? Did you try 
without the illegal entry [BuildOptions.AARCH64.common.EDKII.DXE_RUNTIME_DRIVER]

Thanks,

Andrew Fish

Which is the format that actually works in the code.

Is there some other section or interpretation that you are referring to?

K2

From: Gao, Liming [mailto:liming@intel.com]
Sent: Monday, August 15, 2016 7:17 PM
To: Kurt Kennett 
>; 
af...@apple.com
Cc: edk2-devel >
Subject: RE: [edk2] Setting BuildOptions by module type does not seem to work

Hi,
  This style has been defined in DSC spec 1.26. It can be downloaded from 
https://github.com/tianocore/tianocore.github.io/wiki/EDK%20II%20Specifications

Thanks
Liming
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Kurt 
Kennett
Sent: Tuesday, August 16, 2016 1:56 AM
To: af...@apple.com
Cc: edk2-devel >
Subject: Re: [edk2] Setting BuildOptions by module type does not seem to work

Okay this seems to work:

[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]

Thanks Andrew.

(doesn't match the spec though :) )

K2

-Original Message-
From: af...@apple.com [mailto:af...@apple.com]
Sent: Monday, August 15, 2016 10:30 AM
To: Kurt Kennett
Cc: edk2-devel
Subject: Re: [edk2] Setting BuildOptions by module type does not seem to work

> On Aug 15, 2016, at 9:34 AM, Kurt Kennett wrote:
>
> No, I had not tried that. I tried it now and it does not seem to work.
>
> I have:
>
> [BuildOptions.AARCH64.common]
> *_VS2015x86_AARCH64_DLINK_FLAGS = /BORK
>
> [BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER]
> *_VS2015x86_AARCH64_DLINK_FLAGS = /PLOR
>
> [BuildOptions.AARCH64.common.EDKII.DXE_RUNTIME_DRIVER]
> *_VS2015x86_AARCH64_DLINK_FLAGS = /BONK
>
> And the only one that makes it to the command line is the /BORK one.
>
> (The tools do not complain about the specification of options as above).
>

I'm guessing the syntax checking is not very good?
[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
[BuildOptions.AARCH64.common.EDKII.DXE_RUNTIME_DRIVER]

I see the [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER] form used in other 
places, but you have an extra .common?

Thanks,

Andrew Fish

> K2
>
> -Original Message-
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Monday, August 15, 2016 9:22 AM
> To: Kurt Kennett
> Cc: edk2-devel
> Subject: Re: [edk2] Setting BuildOptions by module type does not seem
> to work
>
>
>> On Aug 15, 2016, at 9:10 AM, Kurt Kennett wrote:
>>
>> DSC spec (January 2016 1.26) says I can do this:
>>
>> (Section 3.6 pp 76)
>>
>> ...
>> * [BuildOptions.$(arch).CodeBase.Edk2ModuleType]
>> ...
>>
>> And this works fine:
>>
>> [BuildOptions.AARCH64.common]
>> *_VS2015x86_*_DLINK_FLAGS = /BORK
>>
>> But when I also do:
>>
>> [BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER]
>> *_VS2015x86_*_DLINK_FLAGS = /PLOR
>>
>> The link flags are not affected on the command line - they get the /BORK for 
>> all

Re: [edk2] Setting BuildOptions by module type does not seem to work

2016-08-16 Thread Andrew Fish


> On Aug 16, 2016, at 7:49 AM, Kurt Kennett  wrote:
> 
> Hi Liming.  I’m a bit confused by your email.
>  
> I my original email below, I reference directly:
>  
> >> DSC spec (January 2016 1.26) says I can do this:
> >> 
> >> (Section 3.6 pp 76)
> 
> In this section it says:
>  
> …
> Build options priority (appended from lowest to highest and/or highest 
> replacement) is:
> • Highest, DSC file’s component scoped  for individual INF 
> files.
> • [BuildOptions.$(arch).CodeBase.Edk2ModuleType]
> • [BuildOptions.$(arch).CodeBase]
> • [BuildOptions.common.CodeBase]
> • [BuildOptions.$(arch)]
> • [BuildOptions.common]
> • [BuildOptions]
> • INF File’s [BuildOptions] section
> • Lowest - tools_def.txt entry
>  
> In the “Prototype” section immediately below this (Page 79) is the grammar.
>  
> There is no interpretation of the grammar corresponds to
>  
> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]

Kurt,

It looks like a bug in the spec as there is a missing Edk2ModuleType common 
type. 
• [BuildOptions.$(arch).CodeBase.Edk2ModuleType]
• [BuildOptions.common.CodeBase.Edk2ModuleType]
• [BuildOptions.$(arch).CodeBase]

Or I guess you could interpret the spec that the last 
BuildOptions.$(arch).CodeBase.Edk2ModuleType wins either common or matching 
$(arch)? 

Did [BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER] not work? Did you try 
without the illegal entry [BuildOptions.AARCH64.common.EDKII.DXE_RUNTIME_DRIVER]

Thanks,

Andrew Fish

>  
> Which is the format that actually works in the code.
>  
> Is there some other section or interpretation that you are referring to?
>  
> K2
>  
> From: Gao, Liming [mailto:liming@intel.com] 
> Sent: Monday, August 15, 2016 7:17 PM
> To: Kurt Kennett ; af...@apple.com
> Cc: edk2-devel 
> Subject: RE: [edk2] Setting BuildOptions by module type does not seem to work
>  
> Hi,
>   This style has been defined in DSC spec 1.26. It can be downloaded from 
> https://github.com/tianocore/tianocore.github.io/wiki/EDK%20II%20Specifications
>  
> 
>  
> Thanks
> Liming
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org 
> ] On Behalf Of Kurt Kennett
> Sent: Tuesday, August 16, 2016 1:56 AM
> To: af...@apple.com 
> Cc: edk2-devel >
> Subject: Re: [edk2] Setting BuildOptions by module type does not seem to work
>  
> Okay this seems to work:
> 
> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> 
> Thanks Andrew.
> 
> (doesn't match the spec though :) )
> 
> K2
> 
> -Original Message-
> From: af...@apple.com  [mailto:af...@apple.com 
> ] 
> Sent: Monday, August 15, 2016 10:30 AM
> To: Kurt Kennett 
> Cc: edk2-devel 
> Subject: Re: [edk2] Setting BuildOptions by module type does not seem to work
> 
> 
> > On Aug 15, 2016, at 9:34 AM, Kurt Kennett wrote:
> > 
> > No, I had not tried that. I tried it now and it does not seem to work.
> > 
> > I have:
> > 
> > [BuildOptions.AARCH64.common]
> > *_VS2015x86_AARCH64_DLINK_FLAGS = /BORK
> > 
> > [BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER]
> > *_VS2015x86_AARCH64_DLINK_FLAGS = /PLOR
> > 
> > [BuildOptions.AARCH64.common.EDKII.DXE_RUNTIME_DRIVER]
> > *_VS2015x86_AARCH64_DLINK_FLAGS = /BONK
> > 
> > And the only one that makes it to the command line is the /BORK one.
> > 
> > (The tools do not complain about the specification of options as above).
> > 
> 
> I'm guessing the syntax checking is not very good? 
> [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> [BuildOptions.AARCH64.common.EDKII.DXE_RUNTIME_DRIVER]
> 
> I see the [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER] form used in other 
> places, but you have an extra .common? 
> 
> Thanks,
> 
> Andrew Fish
> 
> > K2
> > 
> > -Original Message-
> > From: af...@apple.com  [mailto:af...@apple.com 
> > ]
> > Sent: Monday, August 15, 2016 9:22 AM
> > To: Kurt Kennett 
> > Cc: edk2-devel 
> > Subject: Re: [edk2] Setting BuildOptions by module type does not seem 
> > to work
> > 
> > 
> >> On Aug 15, 2016, at 9:10 AM, Kurt Kennett wrote:
> >> 
> >> DSC spec (January 2016 1.26) says I can do this:
> >> 
> >> (Section 3.6 pp 76)
> >> 
> >> ...
> >> * [BuildOptions.$(arch).CodeBase.Edk2ModuleType]
> >> ...
> >> 
> >> And this works fine:
> >> 
> >> [BuildOptions.AARCH64.common]
> >> *_VS2015x86_*_DLINK_FLAGS = /BORK
> >> 
> >> But when I also do:
> >> 
> >> [BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER]
> >> *_VS2015x86_*_DLINK_FLAGS = /PLOR
> >> 
> >> The link flags are not affected on the command line - they get the /BORK 
> >> for all module types, but not the /PLOR for DXE_RUNTIME_DRIVERs.
> >> 
> > 
> > Kurt,
> > 
> > Have you tried [BuildOptions.AARCH64.EDKII.DXE_RUNTIME_DRIVER]? Do

Re: [edk2] Setting BuildOptions by module type does not seem to work

2016-08-16 Thread Kurt Kennett

Hi Liming.  I'm a bit confused by your email.

I my original email below, I reference directly:

>> DSC spec (January 2016 1.26) says I can do this:
>>
>> (Section 3.6 pp 76)

In this section it says:

...
Build options priority (appended from lowest to highest and/or highest 
replacement) is:
* Highest, DSC file's component scoped  for individual INF files.
* [BuildOptions.$(arch).CodeBase.Edk2ModuleType]
* [BuildOptions.$(arch).CodeBase]
* [BuildOptions.common.CodeBase]
* [BuildOptions.$(arch)]
* [BuildOptions.common]
* [BuildOptions]
* INF File's [BuildOptions] section
* Lowest - tools_def.txt entry

In the "Prototype" section immediately below this (Page 79) is the grammar.

There is no interpretation of the grammar corresponds to

[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]

Which is the format that actually works in the code.

Is there some other section or interpretation that you are referring to?

K2

From: Gao, Liming [mailto:liming@intel.com]
Sent: Monday, August 15, 2016 7:17 PM
To: Kurt Kennett ; af...@apple.com
Cc: edk2-devel 
Subject: RE: [edk2] Setting BuildOptions by module type does not seem to work

Hi,
  This style has been defined in DSC spec 1.26. It can be downloaded from 
https://github.com/tianocore/tianocore.github.io/wiki/EDK%20II%20Specifications

Thanks
Liming
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Kurt 
Kennett
Sent: Tuesday, August 16, 2016 1:56 AM
To: af...@apple.com
Cc: edk2-devel >
Subject: Re: [edk2] Setting BuildOptions by module type does not seem to work

Okay this seems to work:

[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]

Thanks Andrew.

(doesn't match the spec though :) )

K2

-Original Message-
From: af...@apple.com [mailto:af...@apple.com]
Sent: Monday, August 15, 2016 10:30 AM
To: Kurt Kennett
Cc: edk2-devel
Subject: Re: [edk2] Setting BuildOptions by module type does not seem to work


> On Aug 15, 2016, at 9:34 AM, Kurt Kennett wrote:
>
> No, I had not tried that. I tried it now and it does not seem to work.
>
> I have:
>
> [BuildOptions.AARCH64.common]
> *_VS2015x86_AARCH64_DLINK_FLAGS = /BORK
>
> [BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER]
> *_VS2015x86_AARCH64_DLINK_FLAGS = /PLOR
>
> [BuildOptions.AARCH64.common.EDKII.DXE_RUNTIME_DRIVER]
> *_VS2015x86_AARCH64_DLINK_FLAGS = /BONK
>
> And the only one that makes it to the command line is the /BORK one.
>
> (The tools do not complain about the specification of options as above).
>

I'm guessing the syntax checking is not very good?
[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
[BuildOptions.AARCH64.common.EDKII.DXE_RUNTIME_DRIVER]

I see the [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER] form used in other 
places, but you have an extra .common?

Thanks,

Andrew Fish

> K2
>
> -Original Message-
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Monday, August 15, 2016 9:22 AM
> To: Kurt Kennett
> Cc: edk2-devel
> Subject: Re: [edk2] Setting BuildOptions by module type does not seem
> to work
>
>
>> On Aug 15, 2016, at 9:10 AM, Kurt Kennett wrote:
>>
>> DSC spec (January 2016 1.26) says I can do this:
>>
>> (Section 3.6 pp 76)
>>
>> ...
>> * [BuildOptions.$(arch).CodeBase.Edk2ModuleType]
>> ...
>>
>> And this works fine:
>>
>> [BuildOptions.AARCH64.common]
>> *_VS2015x86_*_DLINK_FLAGS = /BORK
>>
>> But when I also do:
>>
>> [BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER]
>> *_VS2015x86_*_DLINK_FLAGS = /PLOR
>>
>> The link flags are not affected on the command line - they get the /BORK for 
>> all module types, but not the /PLOR for DXE_RUNTIME_DRIVERs.
>>
>
> Kurt,
>
> Have you tried [BuildOptions.AARCH64.EDKII.DXE_RUNTIME_DRIVER]? Do you need 
> EDK compatibility?
>
> I'm guessing that works given:
> ~/work/src/edk2(master)>git grep "BuildOptions." -- *.dsc | grep
> DXE_RUNTIME_DRIVER
> OvmfPkg/OvmfPkgIa32.dsc:49:[BuildOptions.common.EDKII.DXE_RUNTIME_DRIV
> ER]
> OvmfPkg/OvmfPkgIa32X64.dsc:54:[BuildOptions.common.EDKII.DXE_RUNTIME_D
> RIVER]
> OvmfPkg/OvmfPkgX64.dsc:54:[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVE
> R]
> QuarkPlatformPkg/Quark.dsc:885:[BuildOptions.common.EDKII.DXE_RUNTIME_
> DRIVER]
>
>
>> I'm not familiar with the DSC processing tools source. Anybody know where to 
>> look to see why not?
>>
>
> It starts here:
> https://github.com/tianocore/edk2/blob/master/BaseTools/Source/Python/
> build/build.py and uses some code from:
> https://github.com/tianocore/edk2/tree/master/BaseTools/Source/Python/
> Common
>
> Thanks,
>
> Andrew Fish
>
>> K2
>>
>>
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
>
> ___
> edk2-devel mailing list
>

Re: [edk2] [Patch] MdeModulePkg: Fix potential failure if UseDefaultAddress configured

2016-08-16 Thread Ye, Ting

Looks good to me.
Reviewed-by: Ye Ting  

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jiaxin Wu
Sent: Monday, August 15, 2016 10:47 AM
To: edk2-devel@lists.01.org
Cc: Ye, Ting ; Fu, Siyuan ; Cohen 
Eugene 
Subject: [edk2] [Patch] MdeModulePkg: Fix potential failure if 
UseDefaultAddress configured

IpSb->Reconfig should not be set to TRUE to focal the reconfiguration
during the policy changes from Static to DHCP. It's redundancy because the 
default router table and default addresses have been freed ahead ( Detailed see 
Ip4Config2OnPolicyChanged() function). Otherwise, the potential failure will 
appear if UseDefaultAddress configured. Reproduce steps see below:

#1. Set policy to DHCP.
#2. If DHCP process is not complete yet, then run one APP to invoke UDP4 
Configure with "UseDefaultAddress = TRUE" (loop to call UDP4 Configure until 
Ip4Mode.IsConfigured changes to TRUE).
#3. Even DHCP succeed but Ip4Mode.IsConfigured flag never set to TRUE

Concrete analysis is as follows:
In #1, the policy will be set to DHCP, and then Ip4Config2OnPolicyChanged() 
will be called. In this function, if "IpSb->Reconfig" flag is set to TRUE, the 
original "IpSb->DefaultInterface" will be abandoned/freed once the DHCP process 
finished.

In #2, UDP4 Configure with "UseDefaultAddress = TRUE" is called, that means the 
default interface (IpSb->DefaultInterface) will be selected as current 
instance's interface.

In #3, when DHCP process finished, the original DefaultInterface will be 
abandoned/freed because "IpSb->Reconfig" flag is true. Meanwhile, one new 
interface is assigned to "IpSb->DefaultInterface". This new interface is 
different to the original one assigned to the UDP4 Configured instance. So, 
even DHCP process succeed, the up caller will never have the chance to get it's 
truly status.

Cc: Cohen Eugene 
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 
---
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c 
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
index f91a935..75ad301 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
@@ -148,11 +148,10 @@ Ip4Config2OnPolicyChanged (

   //
   // Start the dhcp configuration.
   //
   if (NewPolicy == Ip4Config2PolicyDhcp) {
-IpSb->Reconfig = TRUE;
 Ip4StartAutoConfig (>Ip4Config2Instance);
   }

 }

--
1.9.5.msysgit.1

___
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] [staging/HTTPS-TLS][PATCH 0/2] Readme.MD and TlsAuthConfigDxe update

2016-08-16 Thread Ye, Ting

Series reviewed by: Ye Ting  

-Original Message-
From: Wu, Jiaxin 
Sent: Tuesday, August 16, 2016 3:20 PM
To: edk2-devel@lists.01.org
Cc: Palmer Thomas ; Long, Qin ; Ye, 
Ting ; Fu, Siyuan 
Subject: [staging/HTTPS-TLS][PATCH 0/2] Readme.MD and TlsAuthConfigDxe update

Cc: Palmer Thomas 
Cc: Long Qin 
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 

Jiaxin Wu (2):
  Readme.MD: Clarify the feature support scope
  NetworkPkg/TlsAuthConfigDxe: TlsCaCertificate variable attribute update

 NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.c | 2 +-  
NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.h | 2 ++
 Readme.MD   | 8 +++-
 3 files changed, 10 insertions(+), 2 deletions(-)

--
1.9.5.msysgit.1

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

Re: [edk2] [PATCH] ShellPkg/Ls: Handle the case when SearchString is NULL

2016-08-16 Thread Wu, Hao A

Reviewed-by: Hao Wu 

Best Regards,
Hao Wu

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ruiyu
> Ni
> Sent: Tuesday, August 16, 2016 3:33 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A
> Subject: [edk2] [PATCH] ShellPkg/Ls: Handle the case when SearchString is
> NULL
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ruiyu Ni 
> Cc: Hao Wu 
> ---
>  ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
> b/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
> index 0b80195..9b4c452 100644
> --- a/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
> +++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
> @@ -709,6 +709,11 @@ ShellCommandRunLs (
>// must split off the search part that applies to files from 
> the end of
> the directory part
>//
>StrnCatGrow(, NULL, FullPath, 0);
> +  if (SearchString == NULL) {
> +FreePool (FullPath);
> +ShellCommandLineFreeVarList (Package);
> +return SHELL_OUT_OF_RESOURCES;
> +  }
>PathRemoveLastItem (FullPath);
>CopyMem (SearchString, SearchString + StrLen (FullPath), 
> StrSize
> (SearchString + StrLen (FullPath)));
>  }
> --
> 2.9.0.windows.1
> 
> ___
> 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

[edk2] [PATCH] ShellPkg/Ls: Handle the case when SearchString is NULL

2016-08-16 Thread Ruiyu Ni

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Hao Wu 
---
 ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c 
b/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
index 0b80195..9b4c452 100644
--- a/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
+++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
@@ -709,6 +709,11 @@ ShellCommandRunLs (
   // must split off the search part that applies to files from the 
end of the directory part
   //
   StrnCatGrow(, NULL, FullPath, 0);
+  if (SearchString == NULL) {
+FreePool (FullPath);
+ShellCommandLineFreeVarList (Package);
+return SHELL_OUT_OF_RESOURCES;
+  }
   PathRemoveLastItem (FullPath);
   CopyMem (SearchString, SearchString + StrLen (FullPath), StrSize 
(SearchString + StrLen (FullPath)));
 }
-- 
2.9.0.windows.1

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

[edk2] [staging/HTTPS-TLS][PATCH 0/2] Readme.MD and TlsAuthConfigDxe update

2016-08-16 Thread Jiaxin Wu

Cc: Palmer Thomas 
Cc: Long Qin 
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 

Jiaxin Wu (2):
  Readme.MD: Clarify the feature support scope
  NetworkPkg/TlsAuthConfigDxe: TlsCaCertificate variable attribute update

 NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.c | 2 +-
 NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.h | 2 ++
 Readme.MD   | 8 +++-
 3 files changed, 10 insertions(+), 2 deletions(-)

-- 
1.9.5.msysgit.1

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

[edk2] [staging/HTTPS-TLS][PATCH 1/2] Readme.MD: Clarify the feature support scope

2016-08-16 Thread Jiaxin Wu

Cc: Palmer Thomas 
Cc: Long Qin 
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 
---
 Readme.MD | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/Readme.MD b/Readme.MD
index 2411042..389935e 100644
--- a/Readme.MD
+++ b/Readme.MD
@@ -31,11 +31,17 @@ CryptoPkg/Library/TlsLib/TlsLib.inf
 NetworkPkg/TlsDxe/TlsDxe.inf
 NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf
 ```
 
  HTTPS Authentication
-Currently, HTTPS boot feature only support server authentication with an 
unauthenticated client mode [RFC5246](https://tools.ietf.org/html/rfc5246). To 
support this mode, server CA certificate is required by Client. Private 
variable is used to configure this CA certificate. **EFI_SIGNATURE_LIST** 
format is used for this variable. In sum, the Server CA certificate must be 
configured first to enable HTTPS boot feature. The variable name and GUID are 
defined as below.
+TLS supports three authentication modes 
([RFC5246](https://tools.ietf.org/html/rfc5246)):
+```
+1. Total anonymity: the server and client won???t authenticate each other.
+2. One-way authentication: server authentication with an unauthenticated 
client.
+3. Two-way authentication: authentication of both parties.
+```
+Currently, HTTPS boot feature only support server authentication with an 
unauthenticated client mode. Others are not in our current feature support 
scope. To support one-way authentication mode, server CA certificate is 
required by Client. Private variable is used to configure this CA certificate. 
**EFI_SIGNATURE_LIST** format is used for this variable. In sum, the Server CA 
certificate must be configured first to enable HTTPS boot feature. The variable 
name and GUID are defined as below.
 ```
 #define EFI_TLS_CA_CERTIFICATE_GUID \
   { \
 0xfd2340D0, 0x3dab, 0x4349, { 0xa6, 0xc7, 0x3b, 0x4f, 0x12, 0xb4, 0x8e, 
0xae } \
   }
-- 
1.9.5.msysgit.1

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

[edk2] [staging/HTTPS-TLS][PATCH 2/2] NetworkPkg/TlsAuthConfigDxe: TlsCaCertificate variable attribute update

2016-08-16 Thread Jiaxin Wu

Remove the RT attribute for TlsCaCertificate variable protecting. If so,
we can treat this variable as security in certain case.

Cc: Palmer Thomas 
Cc: Long Qin 
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 
---
 NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.c | 2 +-
 NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.h | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.c 
b/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.c
index f265b42..1132cac 100644
--- a/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.c
+++ b/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.c
@@ -999,11 +999,11 @@ EnrollX509toVariable (
   //
   // Check if signature database entry has been already existed.
   // If true, use EFI_VARIABLE_APPEND_WRITE attribute to append the
   // new signature data to original variable
   //
-  Attr = EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_RUNTIME_ACCESS | 
EFI_VARIABLE_BOOTSERVICE_ACCESS;
+  Attr = TLS_AUTH_CONFIG_VAR_BASE_ATTR;
 
   Status = gRT->GetVariable(
   VariableName,
   ,
   NULL,
diff --git a/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.h 
b/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.h
index dea3cda..398f7b6 100644
--- a/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.h
+++ b/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.h
@@ -51,10 +51,12 @@ extern   UINT8   TlsAuthConfigDxeStrings[];
 extern   UINT8   TlsAuthConfigVfrBin[];
 
 #define TLS_AUTH_CONFIG_PRIVATE_DATA_SIGNATURESIGNATURE_32 ('T', 'A', 'C', 
'D')
 #define TLS_AUTH_CONFIG_PRIVATE_FROM_THIS(a)  CR (a, 
TLS_AUTH_CONFIG_PRIVATE_DATA, ConfigAccess, 
TLS_AUTH_CONFIG_PRIVATE_DATA_SIGNATURE)
 
+#define TLS_AUTH_CONFIG_VAR_BASE_ATTR  (EFI_VARIABLE_NON_VOLATILE | 
EFI_VARIABLE_BOOTSERVICE_ACCESS)
+
 typedef struct _TLS_AUTH_CONFIG_PRIVATE_DATA  TLS_AUTH_CONFIG_PRIVATE_DATA;
 typedef struct _TLS_AUTH_CONFIG_FILE_CONTEXT  TLS_AUTH_CONFIG_FILE_CONTEXT;
 
 ///
 /// HII specific Vendor Device Path definition.
-- 
1.9.5.msysgit.1

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

Re: [edk2] [Patch] MdePkg: Fix guid conflict.

2016-08-16 Thread Jordan Justen

Some notes for future reference, since this is already committed.

I think subject should have been something like:

MdePkg/ImageDecoder: Fix GUID conflict with PCI Root Bridge Protocol

When browsing commits with just the subject line, you should have a
good idea of what the commit is about. (For example: gitk, or tig, or
git log --oneline)

On 2016-08-11 19:09:48, Eric Dong wrote:
> -  { 0x2f707ebb, 0x4a1a, 0x11d4, {0x9a,0x38,0x00,0x90,0x27,0x3f,0xc1,0x4d}}
> +  {0x9e66f251, 0x727c, 0x418c, { 0xbf, 0xd6, 0xc2, 0xb4, 0x25, 0x28, 0x18, 
> 0xea }}

Should have a space before 0x9e66f251.

>## Include/Guid/MemoryOverwriteControl.h
>gEfiMemoryOverwriteControlDataGuid = { 0xe20939be, 0x32d4, 0x41be, {0xa1, 
> 0x50, 0x89, 0x7f, 0x85, 0xd4, 0x98, 0x29 }}
> -  
> +
>## Include/IndustryStandard/MemoryOverwriteRequestControlLock.h
>gEfiMemoryOverwriteRequestControlLockGuid = { 0xBB983CCF, 0x151D, 0x40E1, 
> {0xA0, 0x7B, 0x4A, 0x17, 0xBE, 0x16, 0x82, 0x92}}
>  
> @@ -1384,7 +1384,7 @@
>  
>## Include/Protocol/TrEEProtocol.h
>gEfiTrEEProtocolGuid   = {0x607f766c, 0x7455, 0x42be, { 0x93, 
> 0x0b, 0xe4, 0xd7, 0x6d, 0xb2, 0x72, 0x0f }}
> -  
> +

I don't think we need to update lines that are unrelated to the patch.
It just distracts from the change.

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

Re: [edk2] USB 3.1 Support in UEFI

Re: [edk2] DHCP Automatic Configure at Driver Connect

Re: [edk2] [PATCH] UefiCpuPkg: MTRR_PHYSMASK.Valid should be one bit instead of 8 bits

[edk2] [PATCH] PcAtChipsetPkg AcpiTimerLib: Wait 363 ACPI timer counts to get TSC Freq

Re: [edk2] IP4 Config Troubles with DHCP

[edk2] Do BSPs only have to be logical thread 0 ?

Re: [edk2] IP4 Config Troubles with DHCP

Re: [edk2] DHCP Automatic Configure at Driver Connect

Re: [edk2] DHCP Automatic Configure at Driver Connect

Re: [edk2] [staging/HTTPS-TLS][PATCH 0/2] Readme.MD and TlsAuthConfigDxe update

Re: [edk2] Setting BuildOptions by module type does not seem to work

Re: [edk2] [MdeModulePkg][PeiCore] I seemed to have crashed the PEI Core by grabbing memory from PeiTemporaryRamBase?

Re: [edk2] [staging/HTTPS-TLS][PATCH 0/2] Readme.MD and TlsAuthConfigDxe update

Re: [edk2] Setting BuildOptions by module type does not seem to work

Re: [edk2] Setting BuildOptions by module type does not seem to work

Re: [edk2] Setting BuildOptions by module type does not seem to work

Re: [edk2] Setting BuildOptions by module type does not seem to work

Re: [edk2] Setting BuildOptions by module type does not seem to work

Re: [edk2] Setting BuildOptions by module type does not seem to work

Re: [edk2] [Patch] MdeModulePkg: Fix potential failure if UseDefaultAddress configured

Re: [edk2] [staging/HTTPS-TLS][PATCH 0/2] Readme.MD and TlsAuthConfigDxe update

Re: [edk2] [PATCH] ShellPkg/Ls: Handle the case when SearchString is NULL

[edk2] [PATCH] ShellPkg/Ls: Handle the case when SearchString is NULL

[edk2] [staging/HTTPS-TLS][PATCH 0/2] Readme.MD and TlsAuthConfigDxe update

[edk2] [staging/HTTPS-TLS][PATCH 1/2] Readme.MD: Clarify the feature support scope

[edk2] [staging/HTTPS-TLS][PATCH 2/2] NetworkPkg/TlsAuthConfigDxe: TlsCaCertificate variable attribute update

Re: [edk2] [Patch] MdePkg: Fix guid conflict.

27 matches

Site Navigation

Mail list logo

Footer information