[edk2] Status of gcc link time optimization for EDK2 use

2014-11-06 Thread Scott Duplichan 
http://notabs.org/uefi/gcc-lto.htm

Thanks,
Scott


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] MdePkg patches to fix Xcode dead stripping issues.

2014-11-06 Thread Gao, Liming 
Andrew:
  Is this a full list? I find some missing .S files in MdePkg, such as 
BaseCpuLib/X64/CpuSleep.S, BaseMemoryLibSse2/X64/ScanMem8.S.

Thanks
Liming
From: Andrew Fish [mailto:af...@apple.com]
Sent: Friday, November 07, 2014 3:15 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] MdePkg patches to fix Xcode dead stripping issues.

For an assembly function to be stripped by the Xcode linker the .S file must 
contain the .subsections_via_symbols directive. The edk2 abstracts this away 
via ASM_FUNCTION_REMOVE_IF_UNREFERENCED.

If the .S does not contain a ASM_FUNCTION_REMOVE_IF_UNREFERENCED, then when 
this library is included those assemble functions always end up in the final 
image even if they are not called. If there are unreferenced intermediate 
symbols that do not start with L, that are not accessed then the the code from 
that label to the next label will be removed. Thus multiple assembly functions 
can be in a single file and each one gets dead stripped independent.

The patch should be low risk as ASM_FUNCTION_REMOVE_IF_UNREFERENCED is mapped 
to nothing on assemblers other than Xcode.

Thanks,

Andrew Fish

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 000/345] Convert EDK II core packages to NASM for IA32/X64

2014-11-06 Thread Kinney, Michael D 
Jordan,

I would like to understand the XCODE issues with using NASM before we explore 
tool enhancements.

Once we get to a state where a NASM file is fully validated and accepted by all 
community members for all build environments, I would prefer the INF be updated 
to only point at NASM file and delete the .asm and .S file.  The .asm and .S 
file will always be available in the history and previous releases.

Mike

-Original Message-
From: Jordan Justen [mailto:jordan.l.jus...@intel.com] 
Sent: Thursday, November 06, 2014 5:31 PM
To: Zimmer, Vincent; edk2-devel@lists.sourceforge.net; Gao, Liming
Cc: Fan, Jeff
Subject: Re: [edk2] [PATCH 000/345] Convert EDK II core packages to NASM for 
IA32/X64

On 2014-11-06 11:18:16, Zimmer, Vincent wrote:
> I agree.  I would keep the original .asm and .s, along w/ new .nasm, at
> least as part of a transition period of engagement w/ the community.
> Vincent

I think the .asm and .S are harmful if no .inf references
them. (Generally speaking, as in another thread I'm making the
opposite argument that a .asm file should be retained even though the
.inf doesn't reference it. :) In that case it can be viewed as
documentation for a .c file.)

Andrew has requested that we find a way to retain the .S for the XCODE
toolchain. I'd like to hear what the BaseTools developers think about
that request.

-Jordan

> -Original Message-
> From: Yao, Jiewen [mailto:jiewen@intel.com] 
> Sent: Wednesday, November 05, 2014 7:23 PM
> To: Gao, Liming; Justen, Jordan L; edk2-devel@lists.sourceforge.net
> Cc: Fan, Jeff
> Subject: Re: [edk2] [PATCH 000/345] Convert EDK II core packages to NASM for
> IA32/X64
> 
> Hi
> I have concern on removing original .asm and .S file, without a full
> validation for .nasm file.
> 
> I am fine on adding .nasm. But can we still keep original .asm and .S file?
> 
> 
> Thank you
> Yao Jiewen
> 
> -Original Message-
> From: Gao, Liming 
> Sent: Thursday, November 06, 2014 10:48 AM
> To: Justen, Jordan L; edk2-devel@lists.sourceforge.net
> Cc: Kinney, Michael D; Tian, Feng; Fan, Jeff; Dong, Guo; Long, Qin; Ni,
> Ruiyu; Yao, Jiewen
> Subject: RE: [PATCH 000/345] Convert EDK II core packages to NASM for
> IA32/X64
> 
> Jordan:
>   This patch updates module INF with .nasm only, and remove the original
> .asm and .S. Right? 
> 
>   After apply this patch, all developers are required to install nasm
> compiler. 
> 
> Thanks
> Liming
> -Original Message-
> From: Justen, Jordan L 
> Sent: Thursday, November 6, 2014 10:01 AM
> To: edk2-devel@lists.sourceforge.net
> Cc: Justen, Jordan L; Kinney, Michael D; Tian, Feng; Fan, Jeff; Dong, Guo;
> Long, Qin; Ni, Ruiyu; Yao, Jiewen; Gao, Liming
> Subject: [PATCH 000/345] Convert EDK II core packages to NASM for IA32/X64
> 
> Nope. I don't plan to actually send out these 345 patches. :)
> 
> But, these patches are available in git:
> git://github.com/jljusten/edk2 nasm-edk2-core
>   or
> https://github.com/jljusten/edk2.git nasm-edk2-core
> 
> Or, view the branch in a web browser:
> https://github.com/jljusten/edk2/tree/nasm-edk2-core
> 
> These patches convert these package to use NASM for IA32 & X64
> * MdePkg
> * MdeModulePkg
> * IntelFrameworkModulePkg
> * UefiCpuPkg
> * SourceLevelDebugPkg
> * SecurityPkg
> * CryptoPkg
> * PcAtChipsetPkg
> * IntelFspPkg
> * IntelFspWrapperPkg
> 
> Package maintainers: Can I get a Tested-by, Reviewed-by or Acked-by
> for the patches affecting the packages that you maintain? (I think
> Liming is also working to get some of these tested.)
> 
> These patches will cause NASM to be required for all IA32 and X64
> toolchains.
> 
> The first 35 patches are a combination of
> BaseTools/Scripts/ConvertMasmToNasm.py output, and manual editing.
> 
> Patch 36 is a nop marker patch so I can keep track of the items that
> have manual edits.
> 
> The remaining patches are the result of running:
> python BaseTools/Scripts/ConvertMasmToNasm.py --git MdePkg MdeModulePkg
> IntelFrameworkPkg IntelFrameworkModulePkg UefiCpuPkg SourceLevelDebugPkg
> SecurityPkg NetworkPkg CryptoPkg PcAtChipsetPkg ShellPkg IntelFspPkg
> IntelFspWrapperPkg
> 
> Jordan Justen (345):
>   MdeModulePkg DebugSupportDxe: Fix build error with GNU assembler
>   MdePkg BaseLib: EXTERNDEF=>EXTERN in X64/SetJump
>   MdePkg BaseMemoryLibSse2: Use movq for 64-bit move to xmm0
>   MdePkg BaseLib Ia32 assembly: Specify DWORD sizes
>   MdeModulePkg BootScriptExecutorDxe: Use NASM compatible syntax
>   MdeModulePkg BootScriptExecutorDxe: EXTERNDEF=>EXTERN in S3Asm
>   MdeModulePkg EbcDxe: Use NASM compatible syntax
>   MdePkg BaseLib X64: Tag MSFT/INTEL for .asm routines in GccInline.c
>   MdePkg BaseLib Ia32/DivU64x64Remainder: Make _@DivRemU64x64 private
>   MdePkg BaseLib Thunk16: Replace IA32 & X64 MASM Thunk16 with NASM
> version
>   MdePkg BaseLib: Remove unused GNU assembly files
>   UefiCpuPkg BaseUefiCpuLib: Convert Ia32/InitializeFpu.asm to NASM
>   UefiCpuPkg BaseUefiCpuLib: Convert X64/Initialize

Re: [edk2] [Patch] ShellPkg: Add type cast to avoid build failure in VS2005

2014-11-06 Thread Qiu, Shumin 
Hi Jaben,
Patch updated. Could you help review?

Thanks,
Shumin

From: Qiu, Shumin [mailto:shumin@intel.com]
Sent: Friday, November 07, 2014 9:27 AM
To: Carsey, Jaben
Cc: edk2-devel@lists.sourceforge.net
Subject: [edk2] [Patch] ShellPkg: Add type cast to avoid build failure in VS2005

Hi Jaben,
Could you help review the patch? The patch adds type cast to avoid build 
failure in VS2005.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin mailto:shumin@intel.com>>

Thanks,
Shumin



UefiShellLib.c.patch
Description: UefiShellLib.c.patch
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 000/345] Convert EDK II core packages to NASM for IA32/X64

2014-11-06 Thread Jordan Justen 
On 2014-11-06 11:18:16, Zimmer, Vincent wrote:
> I agree.  I would keep the original .asm and .s, along w/ new .nasm, at
> least as part of a transition period of engagement w/ the community.
> Vincent

I think the .asm and .S are harmful if no .inf references
them. (Generally speaking, as in another thread I'm making the
opposite argument that a .asm file should be retained even though the
.inf doesn't reference it. :) In that case it can be viewed as
documentation for a .c file.)

Andrew has requested that we find a way to retain the .S for the XCODE
toolchain. I'd like to hear what the BaseTools developers think about
that request.

-Jordan

> -Original Message-
> From: Yao, Jiewen [mailto:jiewen@intel.com] 
> Sent: Wednesday, November 05, 2014 7:23 PM
> To: Gao, Liming; Justen, Jordan L; edk2-devel@lists.sourceforge.net
> Cc: Fan, Jeff
> Subject: Re: [edk2] [PATCH 000/345] Convert EDK II core packages to NASM for
> IA32/X64
> 
> Hi
> I have concern on removing original .asm and .S file, without a full
> validation for .nasm file.
> 
> I am fine on adding .nasm. But can we still keep original .asm and .S file?
> 
> 
> Thank you
> Yao Jiewen
> 
> -Original Message-
> From: Gao, Liming 
> Sent: Thursday, November 06, 2014 10:48 AM
> To: Justen, Jordan L; edk2-devel@lists.sourceforge.net
> Cc: Kinney, Michael D; Tian, Feng; Fan, Jeff; Dong, Guo; Long, Qin; Ni,
> Ruiyu; Yao, Jiewen
> Subject: RE: [PATCH 000/345] Convert EDK II core packages to NASM for
> IA32/X64
> 
> Jordan:
>   This patch updates module INF with .nasm only, and remove the original
> .asm and .S. Right? 
> 
>   After apply this patch, all developers are required to install nasm
> compiler. 
> 
> Thanks
> Liming
> -Original Message-
> From: Justen, Jordan L 
> Sent: Thursday, November 6, 2014 10:01 AM
> To: edk2-devel@lists.sourceforge.net
> Cc: Justen, Jordan L; Kinney, Michael D; Tian, Feng; Fan, Jeff; Dong, Guo;
> Long, Qin; Ni, Ruiyu; Yao, Jiewen; Gao, Liming
> Subject: [PATCH 000/345] Convert EDK II core packages to NASM for IA32/X64
> 
> Nope. I don't plan to actually send out these 345 patches. :)
> 
> But, these patches are available in git:
> git://github.com/jljusten/edk2 nasm-edk2-core
>   or
> https://github.com/jljusten/edk2.git nasm-edk2-core
> 
> Or, view the branch in a web browser:
> https://github.com/jljusten/edk2/tree/nasm-edk2-core
> 
> These patches convert these package to use NASM for IA32 & X64
> * MdePkg
> * MdeModulePkg
> * IntelFrameworkModulePkg
> * UefiCpuPkg
> * SourceLevelDebugPkg
> * SecurityPkg
> * CryptoPkg
> * PcAtChipsetPkg
> * IntelFspPkg
> * IntelFspWrapperPkg
> 
> Package maintainers: Can I get a Tested-by, Reviewed-by or Acked-by
> for the patches affecting the packages that you maintain? (I think
> Liming is also working to get some of these tested.)
> 
> These patches will cause NASM to be required for all IA32 and X64
> toolchains.
> 
> The first 35 patches are a combination of
> BaseTools/Scripts/ConvertMasmToNasm.py output, and manual editing.
> 
> Patch 36 is a nop marker patch so I can keep track of the items that
> have manual edits.
> 
> The remaining patches are the result of running:
> python BaseTools/Scripts/ConvertMasmToNasm.py --git MdePkg MdeModulePkg
> IntelFrameworkPkg IntelFrameworkModulePkg UefiCpuPkg SourceLevelDebugPkg
> SecurityPkg NetworkPkg CryptoPkg PcAtChipsetPkg ShellPkg IntelFspPkg
> IntelFspWrapperPkg
> 
> Jordan Justen (345):
>   MdeModulePkg DebugSupportDxe: Fix build error with GNU assembler
>   MdePkg BaseLib: EXTERNDEF=>EXTERN in X64/SetJump
>   MdePkg BaseMemoryLibSse2: Use movq for 64-bit move to xmm0
>   MdePkg BaseLib Ia32 assembly: Specify DWORD sizes
>   MdeModulePkg BootScriptExecutorDxe: Use NASM compatible syntax
>   MdeModulePkg BootScriptExecutorDxe: EXTERNDEF=>EXTERN in S3Asm
>   MdeModulePkg EbcDxe: Use NASM compatible syntax
>   MdePkg BaseLib X64: Tag MSFT/INTEL for .asm routines in GccInline.c
>   MdePkg BaseLib Ia32/DivU64x64Remainder: Make _@DivRemU64x64 private
>   MdePkg BaseLib Thunk16: Replace IA32 & X64 MASM Thunk16 with NASM
> version
>   MdePkg BaseLib: Remove unused GNU assembly files
>   UefiCpuPkg BaseUefiCpuLib: Convert Ia32/InitializeFpu.asm to NASM
>   UefiCpuPkg BaseUefiCpuLib: Convert X64/InitializeFpu.asm to NASM
>   UefiCpuPkg CpuExceptionHandlerLib: Convert
> Ia32/ExceptionHandlerAsm.asm to NASM
>   UefiCpuPkg CpuExceptionHandlerLib: Convert X64/ExceptionHandlerAsm.asm
> to NASM
>   UefiCpuPkg CpuDxe: Convert Ia32/CpuAsm.asm to NASM
>   UefiCpuPkg CpuDxe: Convert X64/CpuAsm.asm to NASM
>   MdeModulePkg DebugSupportDxe: Convert Ia32/AsmFuncs.asm to NASM
>   MdeModulePkg DebugSupportDxe: Convert X64/AsmFuncs.asm to NASM
>   SourceLevelDebugPkg DebugAgent: Convert
> DebugAgentCommon/Ia32/AsmFuncs.asm to NASM
>   SourceLevelDebugPkg DebugAgent: Convert
> DebugAgentCommon/X64/AsmFuncs.asm to NASM
>   MdeModulePkg DxeIplPeim: Convert Ia32/IdtVectorAsm.asm to NASM
>   CryptoPkg BaseCryptLib

[edk2] [Patch] ShellPkg: Add type cast to avoid build failure in VS2005

2014-11-06 Thread Qiu, Shumin 
Hi Jaben,
Could you help review the patch? The patch adds type cast to avoid build 
failure in VS2005.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin mailto:shumin@intel.com>>

Thanks,
Shumin



UefiShellLib.c.patch
Description: UefiShellLib.c.patch
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [RFC PATCH V7 00/27] Introduce Mp Service protocol to UefiCpuPkg

2014-11-06 Thread Fan, Jeff 
Chen,

Thanks your contribution.  I will check-in your patch if there is no further 
comments from other guys.

Reviewed-by: Jeff Fan 

Thanks!
Jeff

-Original Message-
From: Chen, Fan [mailto:chen.fan.f...@cn.fujitsu.com] 
Sent: Thursday, November 06, 2014 5:13 PM
To: Fan, Jeff
Cc: Izumi, Taku; edk2-devel@lists.sourceforge.net; Jordan Justen
Subject: Re: [RFC PATCH V7 00/27] Introduce Mp Service protocol to UefiCpuPkg

On Thu, 2014-11-06 at 06:11 +, Fan, Jeff wrote: 
> Chen,
> 
> Thanks your updating. I attached one addition updating based on you're the 
> latest patches. Please evaluate and sync it into your patches.
> 
> BTW, please delete ApStartup.asm from CpuDxe, it seems to be one dummy file.
Thanks for you review.
I had merged the changes to my patches as you attachment said. see at:
  https://github.com/ChenFanFnst/edk2/tree/cpu-mp-service

and as for file ApStartup.asm, I moved the asm code to ApStartup.c as comments 
for guiding to create startup code, then deleted ApStartup.asm.


Thanks,
Chen


> 
> Thanks!
> Jeff
> -Original Message-
> From: Chen Fan [mailto:chen.fan.f...@cn.fujitsu.com]
> Sent: Tuesday, November 04, 2014 5:59 PM
> To: edk2-devel@lists.sourceforge.net
> Cc: Jordan Justen; Fan, Jeff; izumi.t...@jp.fujitsu.com
> Subject: [RFC PATCH V7 00/27] Introduce Mp Service protocol to 
> UefiCpuPkg
> 
> This series patchsets try to implement Mp Service protocol in UefiCpuPkg, 
> Jordan had implemented the startup APs code, and I try to add more 
> initialization code to let all APs work up, this Mp Service protocol's 
> implementation used EmulatorPkg/MpService for reference.
> this patches works on my github:
>   https://github.com/ChenFanFnst/edk2/tree/cpu-mp-service
> 
> and made StartCorePkg app for testing Mp Service Protocol on:
>   https://github.com/ChenFanFnst/edk2/tree/startcore
> 
> I had tested the Mp protocol with the test code, and all cases passed.
> 
>   v6-v7:
>   1. fix some trivial bugs pointed out by Jeff.
>   2. free unused cpu buffer data.
> 
>   v5-v6:
>   1. using only one timer to check all APs status instead of timers for each 
> AP.
>   2. cancel timer each time avoid timer handler reentrancy.
>   3. some bug fix.
> 
>   v4-v5:
>   1. introduce PcdCpuMaxLogicalProcessorNumber to pre-allocate
>  stack buffer before starting the APs.
>   2. implement the function that if procedure routine timeout,
>  reset AP by sending init ipi.
>   3. some bug fix.
> 
>   v3-v4:
>   1. change the order of the patches.
>   2. update some minor format suggested by Jeff.
>   3. add a PCD value to configure StackSize.
>   4. the last patch add assembly code for MSFT, but didn't
>  test.
> 
>   V3-V3.1:
>   1. use AcquireSpinLockOrFail() intead of AcquireSpinLock()
>  to avoid ASSERT sugguested by Jeff.
> 
>   V2-V3:
>   1. rebase codes due to Jordan'tree updated:
>  https://github.com/jljusten/edk2/tree/ap-startup-example
>   2. add supported on Ia32 arch
>   3. add a new Lock to replace present SpinLock mechanisms in mutilple
>  processors, maybe the SpinLock mechanisms is not MP safe.
>   4. add function header
>   5. add StartupAllAPs() supported
>   6. add SwitchBSP() function, which is unsupported.
> 
>   V1-V2:
>   1. do not call anything EFI API from APs.
>   2. add AP busy-wait for task assignment from BSP and get rid of
>  IPI sent mechanism.
> 
> Chen Fan (22):
>   UefiCpuPkg/CpuDxe: introduce two PCD value
>   UefiCpuPkg/CpuDxe: Switch Ap Stack to NewStack
>   UefiCpuPkg/CpuDxe: introduce EFI_MP_SERVICES_PROTOCOL
>   UefiCpuPkg/CpuDxe: introduce MP_SYSTEM_DATA for Mp Service Protocol
>   UefiCpuPkg/CpuDxe: implement Mp Protocol: WhoAmI()
>   UefiCpuPkg/CpuDxe: implement Mp Protocol:GetNumberOfProcessors()
>   UefiCpuPkg/CpuDxe: implement Mp Services:GetProcessorInfo()
>   UefiCpuPkg/CpuDxe: implement Mp Protocol:EnableDisableAP()
>   UefiCpuPkg/CpuDxe: implement Mp Protocol:StartupThisAP()
>   UefiCpuPkg/CpuDxe: implement Mp Services:StartupAllAPs()
>   UefiCpuPkg/CpuDxe: implement Mp Services:SwitchBSP()
>   UefiCpuPkg/CpuDxe: Ap do loop routine to execute procedure
>   UefiCpuPkg/MpService: move settimer out to InitMpSystemData
>   UefiCpuPkg/MpService: Simply Lock usage
>   UefiCpuPkg/MpService: avoid next timer getting into
> CheckAllAPsStatus()
>   UefiCpuPkg/CpuDxe: split out StartupCode from StartApsStackless()
>   UefiCpuPkg/CpuDxe: introduce ResetApStackless()
>   UefiCpuPkg/MpService: free the unused cpu data buffer
>   UefiCpuPkg/MpService: avoid reset AP still hold a lock
>   UefiCpuPkg/MpService: avoid dead lock caused by CheckAllAPsStatus
>   UefiCpuPkg/CpuDxe: Startup APs
>   UefiCpuPkg/CpuDxe: install Mp Service protocol
> 
> Jordan Justen (5):
>   UefiCpuPkg/CpuDxe: Add no-op InitializeMpSupport
>   UefiCpuPkg/CpuDxe: Add ApEntryPointInC
>   UefiCpuPkg/CpuDxe: Add stackless assembly AP entry points
>   UefiCpuPkg/CpuDxe: Move GDT structures into CpuGdt.h
>   UefiCpuPkg/CpuDxe: Add StartApsStackless routi

Re: [edk2] [PATCH] [BaseTools] Put all include search paths of a module into a file

2014-11-06 Thread Liu, Yingke D 
Hi Scott,

Thanks for your comments. I will replace '\\' with '/' by using the same rule 
used in object files and static library files.
This patch applied to all sections including [C-Code-File] which is the first 
several lines in this patch :)

Thanks,
Dennis

-Original Message-
From: Scott Duplichan [mailto:sc...@notabs.org] 
Sent: Thursday, November 06, 2014 10:56 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH] [BaseTools] Put all include search paths of a 
module into a file

Liu, Yingke D [mailto:yingke.d@intel.com]  wrote:

]Dear All,
]
]This patch is going to put all -I or /I options followed by include search 
path into a ]file (inc.lst) just as object files and static library files. 
There are cases that too ]many /I options on the command line, and NMAKE fails 
due to command-line length limitation.
]
]Please let me know any impact of this patch to you.
]
]Thanks,
]Dennis

Hello Dennis,

This patch is not working with Windows hosted gcc tools. The cause is the 
single back slash path separator. I believe a single back slash in a gcc 
response file is interpreted as a continuation character. The solution is to 
use either '/' or '\\' as the path separator.
When the include files are on the command line, I believe the mingw library 
code for path processing fixes the back slash problem. But when a response file 
is used, the file continuation character processing runs before the path 
processing code has a chance to reverse the back slashes.

A question, why is the change not applied to [C-Code-File]? Isn't the $(CC) 
command it generates the worst case for command line length?

Thanks,
Scott



--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] FindImageBase and FVs with 0xff padding.

2014-11-06 Thread Tim Lewis 
There are several instances of a function like FindImageBase() 
(IntelFspWrapperPkg, OvmfPkg/Sec). These functions all share common flaws:


1)  If the FV does not begin with a file, then the code does not correctly 
skip the empty space at the beginning of the FV that is filled with 0xFF. This 
happens when the gap at the beginning of the FV is less than 24 bytes. This 
happens because a FILETYPE_PAD file requires at least 24 bytes for the header 
and header alignment only needs to be 8 bytes. Per the PI specification, it is 
filled with the ERASE_POLARITY value (0x00 or 0xff)

2)  If the FV does not end with a file, a similar result happens because 
the empty space is assumed to be a file header and the new "size" of the file 
is either 0x or 0x, both of which lead to problems.

3)  If the FV is less than 24 bytes in length the code will fail. This is a 
rare case, but it is possible to have valid FVs like this, per the spec.

Consider this piece from IntelFspWrapperPkg

for (EndOfFile = CurrentAddress + BootFirmwareVolumePtr->HeaderLength; ; ) {

CurrentAddress = (EndOfFile + 7) & 0xfff8ULL;
if (CurrentAddress > EndOfFirmwareVolume) {
  return EFI_NOT_FOUND;
}

   /* CONSIDER THE CASE WHERE THERE IS EMPTY SPACE AT THE BEGINNING OF THE FV */
File = (EFI_FFS_FILE_HEADER*)(UINTN) CurrentAddress;
if (IS_FFS_FILE2 (File)) {
  Size = FFS_FILE2_SIZE (File);
  if (Size <= 0x00FF) {
return EFI_NOT_FOUND;
  }
} else {
  Size = FFS_FILE_SIZE (File);
  if (Size < sizeof (EFI_FFS_FILE_HEADER)) {
return EFI_NOT_FOUND;
  }
}

EndOfFile = CurrentAddress + Size;
  /* AT THIS POINT, WE MIGHT BE POINTING TO EndOfFirmwareVolume - 16, pointing 
to 0x */

if (EndOfFile > EndOfFirmwareVolume) {
  return EFI_NOT_FOUND;
}

//
// Look for SEC Core / PEI Core files
//
if (File->Type != EFI_FV_FILETYPE_SECURITY_CORE &&
File->Type != EFI_FV_FILETYPE_PEI_CORE) {
  continue;
}
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Win32 Compress and UEFI Decompress Question

2014-11-06 Thread Jim_Dailey 
Thanks for the suggestion, Andrew. Unfortunately, the decompress
protocol doesn't like the gensec compression format either (after
I manipulated the header as appropriate).

I found some Lzma decompress source and incorporated it into my
EFI appp and used LzmaCompress to compress the data that I append
to the app.

Regards,
Jim


From: Andrew Fish [mailto:af...@apple.com]
Sent: Wednesday, November 05, 2014 1:23 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Win32 Compress and UEFI Decompress Question


On Nov 5, 2014, at 8:08 AM, jim_dai...@dell.com 
wrote:

I'm building an EFI utility under Windows. I want to compress some data and 
append
it to the utility. Later, when the utility is executed in the EFI shell, I want 
to
have the utility decompress the data.

I tried using BaseTools\Bin\Win32\LzmaCompress.exe to compress the data and 
found
that it doesn't place the compressed and uncompressed sizes of the data at the
beginning of the compressed data.  So, I tried 
BaseTools\Bin\Win32\TianoCompress.exe.

That utility does seem to create an output that the EFI_DECOMPRESS_PROTOCOL's
GetInfo() function likes.  However, that protocol's Decompress() function does 
not
like the compressed data's format (returns Invalid Parameter).

I also tried using the UefiDecompressLib functions to decompress the data, but
that fails similarly.

So, is there some Win32 utility that compresses data in the format that the
EFI_DECOMPRESS_PROTOCOL expects?  If so, what/where is it?


Interesting question. Looks like the tools have code that does the compression.
https://svn.code.sf.net/p/edk2/code/trunk/edk2/BaseTools/Source/C/Common/EfiCompress.c

The stand alone tools are used for GUID’ed compression schemes. These map to an 
EFI_SECTION_GUID_DEFINED in the FV FFS file section, while the 
EFI_SECTION_COMPRESSION is used for the EFI compression type. I think this is 
only reason stand alone tools exist is for the other forms of compression.

A hack would be to use the GenSec tool.

GenSec -s EFI_SECTION_COMPRESSION -o compressedFileSection RawFile

I think it would generate the compressed data that starts with a 
EFI_COMPRESSION_SECTION structure. So if you just point pass the the 
EFI_COMPRESSION_SECTION the decompress should “just work”?

https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Include/Pi/PiFirmwareFile.h

///

/// An encapsulation section type in which the

/// section data is compressed.

///

typedef struct {

  ///

  /// Usual common section header. CommonHeader.Type = EFI_SECTION_COMPRESSION.

  ///

  EFI_COMMON_SECTION_HEADER   CommonHeader;

  ///

  /// The UINT32 that indicates the size of the section data after 
decompression.

  ///

  UINT32  UncompressedLength;

  ///

  /// Indicates which compression algorithm is used.

  ///

  UINT8   CompressionType;

} EFI_COMPRESSION_SECTION;

If the file is to big to fit in a EFI_COMPRESSION_SECTION it will end up in a 
EFI_COMPRESSION_SECTION2.


typedef struct {

  ///

  /// Usual common section header. CommonHeader.Type = EFI_SECTION_COMPRESSION.

  ///

  EFI_COMMON_SECTION_HEADER2CommonHeader;

  ///

  /// UINT32 that indicates the size of the section data after decompression.

  ///

  UINT32UncompressedLength;

  ///

  /// Indicates which compression algorithm is used.

  ///

  UINT8 CompressionType;

} EFI_COMPRESSION_SECTION2;

typedef struct {

  ///

  /// A 24-bit unsigned integer that contains the total size of the section in 
bytes,

  /// including the EFI_COMMON_SECTION_HEADER.

  ///

  UINT8 Size[3];



  EFI_SECTION_TYPE  Type;



  ///

  /// If Size is 0xFF, then ExtendedSize contains the size of the section. 
If

  /// Size is not equal to 0xFF, then this field does not exist.

  ///

  UINT32ExtendedSize;

} EFI_COMMON_SECTION_HEADER2;


Thanks,

Andrew Fish



Thanks,
Jim
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 000/345] Convert EDK II core packages to NASM for IA32/X64

2014-11-06 Thread Laszlo Ersek 
On 11/06/14 20:18, Zimmer, Vincent wrote:
> I agree.  I would keep the original .asm and .s, along w/ new .nasm, at
> least as part of a transition period of engagement w/ the community.
> Vincent

Well I'm not in a position to argue :), but if .S, .asm, and .nasm[b]
files are *all* preserved, then that's a worse situation than what's in
the tree right now: three flavors instead of two.

I also don't believe that a transition would happen this way, gradually.
Keeping the .S and .asm files in sync is already a problem. I don't see
an incentive for developers to keep one more file in sync, when they
change the .asm.

I think the conversion can be smoothed along another axis: perform the
conversion like Jordan proposes (add .nasm[b], kill .asm and .S
immediately), but do it only for a handful of files per patch series.
Noone's going to verify 345 patches, but an individual maintainer might
be willing to verify 15 patches per month.

Just my (unsolicited) opinion...

Thanks
Laszlo


> 
> -Original Message-
> From: Yao, Jiewen [mailto:jiewen@intel.com] 
> Sent: Wednesday, November 05, 2014 7:23 PM
> To: Gao, Liming; Justen, Jordan L; edk2-devel@lists.sourceforge.net
> Cc: Fan, Jeff
> Subject: Re: [edk2] [PATCH 000/345] Convert EDK II core packages to NASM for
> IA32/X64
> 
> Hi
> I have concern on removing original .asm and .S file, without a full
> validation for .nasm file.
> 
> I am fine on adding .nasm. But can we still keep original .asm and .S file?
> 
> 
> Thank you
> Yao Jiewen
> 
> -Original Message-
> From: Gao, Liming 
> Sent: Thursday, November 06, 2014 10:48 AM
> To: Justen, Jordan L; edk2-devel@lists.sourceforge.net
> Cc: Kinney, Michael D; Tian, Feng; Fan, Jeff; Dong, Guo; Long, Qin; Ni,
> Ruiyu; Yao, Jiewen
> Subject: RE: [PATCH 000/345] Convert EDK II core packages to NASM for
> IA32/X64
> 
> Jordan:
>   This patch updates module INF with .nasm only, and remove the original
> .asm and .S. Right? 
> 
>   After apply this patch, all developers are required to install nasm
> compiler. 
> 
> Thanks
> Liming
> -Original Message-
> From: Justen, Jordan L 
> Sent: Thursday, November 6, 2014 10:01 AM
> To: edk2-devel@lists.sourceforge.net
> Cc: Justen, Jordan L; Kinney, Michael D; Tian, Feng; Fan, Jeff; Dong, Guo;
> Long, Qin; Ni, Ruiyu; Yao, Jiewen; Gao, Liming
> Subject: [PATCH 000/345] Convert EDK II core packages to NASM for IA32/X64
> 
> Nope. I don't plan to actually send out these 345 patches. :)
> 
> But, these patches are available in git:
> git://github.com/jljusten/edk2 nasm-edk2-core
>   or
> https://github.com/jljusten/edk2.git nasm-edk2-core
> 
> Or, view the branch in a web browser:
> https://github.com/jljusten/edk2/tree/nasm-edk2-core
> 
> These patches convert these package to use NASM for IA32 & X64
> * MdePkg
> * MdeModulePkg
> * IntelFrameworkModulePkg
> * UefiCpuPkg
> * SourceLevelDebugPkg
> * SecurityPkg
> * CryptoPkg
> * PcAtChipsetPkg
> * IntelFspPkg
> * IntelFspWrapperPkg
> 
> Package maintainers: Can I get a Tested-by, Reviewed-by or Acked-by
> for the patches affecting the packages that you maintain? (I think
> Liming is also working to get some of these tested.)
> 
> These patches will cause NASM to be required for all IA32 and X64
> toolchains.
> 
> The first 35 patches are a combination of
> BaseTools/Scripts/ConvertMasmToNasm.py output, and manual editing.
> 
> Patch 36 is a nop marker patch so I can keep track of the items that
> have manual edits.
> 
> The remaining patches are the result of running:
> python BaseTools/Scripts/ConvertMasmToNasm.py --git MdePkg MdeModulePkg
> IntelFrameworkPkg IntelFrameworkModulePkg UefiCpuPkg SourceLevelDebugPkg
> SecurityPkg NetworkPkg CryptoPkg PcAtChipsetPkg ShellPkg IntelFspPkg
> IntelFspWrapperPkg
> 
> Jordan Justen (345):
>   MdeModulePkg DebugSupportDxe: Fix build error with GNU assembler
>   MdePkg BaseLib: EXTERNDEF=>EXTERN in X64/SetJump
>   MdePkg BaseMemoryLibSse2: Use movq for 64-bit move to xmm0
>   MdePkg BaseLib Ia32 assembly: Specify DWORD sizes
>   MdeModulePkg BootScriptExecutorDxe: Use NASM compatible syntax
>   MdeModulePkg BootScriptExecutorDxe: EXTERNDEF=>EXTERN in S3Asm
>   MdeModulePkg EbcDxe: Use NASM compatible syntax
>   MdePkg BaseLib X64: Tag MSFT/INTEL for .asm routines in GccInline.c
>   MdePkg BaseLib Ia32/DivU64x64Remainder: Make _@DivRemU64x64 private
>   MdePkg BaseLib Thunk16: Replace IA32 & X64 MASM Thunk16 with NASM
> version
>   MdePkg BaseLib: Remove unused GNU assembly files
>   UefiCpuPkg BaseUefiCpuLib: Convert Ia32/InitializeFpu.asm to NASM
>   UefiCpuPkg BaseUefiCpuLib: Convert X64/InitializeFpu.asm to NASM
>   UefiCpuPkg CpuExceptionHandlerLib: Convert
> Ia32/ExceptionHandlerAsm.asm to NASM
>   UefiCpuPkg CpuExceptionHandlerLib: Convert X64/ExceptionHandlerAsm.asm
> to NASM
>   UefiCpuPkg CpuDxe: Convert Ia32/CpuAsm.asm to NASM
>   UefiCpuPkg CpuDxe: Convert X64/CpuAsm.asm to NASM
>   MdeModulePkg DebugSupportDxe: Convert Ia32/AsmFuncs.asm to NASM
>

Re: [edk2] [PATCH 000/345] Convert EDK II core packages to NASM for IA32/X64

2014-11-06 Thread Zimmer, Vincent 
I agree.  I would keep the original .asm and .s, along w/ new .nasm, at
least as part of a transition period of engagement w/ the community.
Vincent

-Original Message-
From: Yao, Jiewen [mailto:jiewen@intel.com] 
Sent: Wednesday, November 05, 2014 7:23 PM
To: Gao, Liming; Justen, Jordan L; edk2-devel@lists.sourceforge.net
Cc: Fan, Jeff
Subject: Re: [edk2] [PATCH 000/345] Convert EDK II core packages to NASM for
IA32/X64

Hi
I have concern on removing original .asm and .S file, without a full
validation for .nasm file.

I am fine on adding .nasm. But can we still keep original .asm and .S file?


Thank you
Yao Jiewen

-Original Message-
From: Gao, Liming 
Sent: Thursday, November 06, 2014 10:48 AM
To: Justen, Jordan L; edk2-devel@lists.sourceforge.net
Cc: Kinney, Michael D; Tian, Feng; Fan, Jeff; Dong, Guo; Long, Qin; Ni,
Ruiyu; Yao, Jiewen
Subject: RE: [PATCH 000/345] Convert EDK II core packages to NASM for
IA32/X64

Jordan:
  This patch updates module INF with .nasm only, and remove the original
.asm and .S. Right? 

  After apply this patch, all developers are required to install nasm
compiler. 

Thanks
Liming
-Original Message-
From: Justen, Jordan L 
Sent: Thursday, November 6, 2014 10:01 AM
To: edk2-devel@lists.sourceforge.net
Cc: Justen, Jordan L; Kinney, Michael D; Tian, Feng; Fan, Jeff; Dong, Guo;
Long, Qin; Ni, Ruiyu; Yao, Jiewen; Gao, Liming
Subject: [PATCH 000/345] Convert EDK II core packages to NASM for IA32/X64

Nope. I don't plan to actually send out these 345 patches. :)

But, these patches are available in git:
git://github.com/jljusten/edk2 nasm-edk2-core
  or
https://github.com/jljusten/edk2.git nasm-edk2-core

Or, view the branch in a web browser:
https://github.com/jljusten/edk2/tree/nasm-edk2-core

These patches convert these package to use NASM for IA32 & X64
* MdePkg
* MdeModulePkg
* IntelFrameworkModulePkg
* UefiCpuPkg
* SourceLevelDebugPkg
* SecurityPkg
* CryptoPkg
* PcAtChipsetPkg
* IntelFspPkg
* IntelFspWrapperPkg

Package maintainers: Can I get a Tested-by, Reviewed-by or Acked-by
for the patches affecting the packages that you maintain? (I think
Liming is also working to get some of these tested.)

These patches will cause NASM to be required for all IA32 and X64
toolchains.

The first 35 patches are a combination of
BaseTools/Scripts/ConvertMasmToNasm.py output, and manual editing.

Patch 36 is a nop marker patch so I can keep track of the items that
have manual edits.

The remaining patches are the result of running:
python BaseTools/Scripts/ConvertMasmToNasm.py --git MdePkg MdeModulePkg
IntelFrameworkPkg IntelFrameworkModulePkg UefiCpuPkg SourceLevelDebugPkg
SecurityPkg NetworkPkg CryptoPkg PcAtChipsetPkg ShellPkg IntelFspPkg
IntelFspWrapperPkg

Jordan Justen (345):
  MdeModulePkg DebugSupportDxe: Fix build error with GNU assembler
  MdePkg BaseLib: EXTERNDEF=>EXTERN in X64/SetJump
  MdePkg BaseMemoryLibSse2: Use movq for 64-bit move to xmm0
  MdePkg BaseLib Ia32 assembly: Specify DWORD sizes
  MdeModulePkg BootScriptExecutorDxe: Use NASM compatible syntax
  MdeModulePkg BootScriptExecutorDxe: EXTERNDEF=>EXTERN in S3Asm
  MdeModulePkg EbcDxe: Use NASM compatible syntax
  MdePkg BaseLib X64: Tag MSFT/INTEL for .asm routines in GccInline.c
  MdePkg BaseLib Ia32/DivU64x64Remainder: Make _@DivRemU64x64 private
  MdePkg BaseLib Thunk16: Replace IA32 & X64 MASM Thunk16 with NASM
version
  MdePkg BaseLib: Remove unused GNU assembly files
  UefiCpuPkg BaseUefiCpuLib: Convert Ia32/InitializeFpu.asm to NASM
  UefiCpuPkg BaseUefiCpuLib: Convert X64/InitializeFpu.asm to NASM
  UefiCpuPkg CpuExceptionHandlerLib: Convert
Ia32/ExceptionHandlerAsm.asm to NASM
  UefiCpuPkg CpuExceptionHandlerLib: Convert X64/ExceptionHandlerAsm.asm
to NASM
  UefiCpuPkg CpuDxe: Convert Ia32/CpuAsm.asm to NASM
  UefiCpuPkg CpuDxe: Convert X64/CpuAsm.asm to NASM
  MdeModulePkg DebugSupportDxe: Convert Ia32/AsmFuncs.asm to NASM
  MdeModulePkg DebugSupportDxe: Convert X64/AsmFuncs.asm to NASM
  SourceLevelDebugPkg DebugAgent: Convert
DebugAgentCommon/Ia32/AsmFuncs.asm to NASM
  SourceLevelDebugPkg DebugAgent: Convert
DebugAgentCommon/X64/AsmFuncs.asm to NASM
  MdeModulePkg DxeIplPeim: Convert Ia32/IdtVectorAsm.asm to NASM
  CryptoPkg BaseCryptLib: Convert Ia32/MathMultS64x64.S to NASM
  CryptoPkg BaseCryptLib: Convert Ia32/MathDivU64x64.S to NASM
  CryptoPkg BaseCryptLib: Convert Ia32/MathReminderU64x64.S to NASM
  CryptoPkg BaseCryptLib: Convert Ia32/MathLShiftS64.S to NASM
  CryptoPkg BaseCryptLib: Convert Ia32/MathRShiftU64.S to NASM
  IntelFspPkg FspSecCore: Convert Ia32/InitializeFpu.asm to NASM
  IntelFspPkg BaseFspSwitchStackLib: Convert Ia32/Stack.asm to NASM
  IntelFspPkg FspSecCore: Convert Ia32/Stack.asm to NASM
  IntelFspPkg/FspSecCore FspApiEntry assembly: Don't use weak externs
  IntelFspPkg FspSecCore: Convert Ia32/FspApiEntry.asm to NASM
  IntelFspWrapperPkg SecPeiFspPlatformSecLibSample: Convert
Ia32/PeiCoreEntry.asm to NASM
  IntelFspWrapper

[edk2] MdePkg patches to fix Xcode dead stripping issues.

2014-11-06 Thread Andrew Fish 
For an assembly function to be stripped by the Xcode linker the .S file must contain the .subsections_via_symbols directive. The edk2 abstracts this away via ASM_FUNCTION_REMOVE_IF_UNREFERENCED.If the .S does not contain a ASM_FUNCTION_REMOVE_IF_UNREFERENCED, then when this library is included those assemble functions always end up in the final image even if they are not called. If there are unreferenced intermediate symbols that do not start with L, that are not accessed then the the code from that label to the next label will be removed. Thus multiple assembly functions can be in a single file and each one gets dead stripped independent. The patch should be low risk as ASM_FUNCTION_REMOVE_IF_UNREFERENCED is mapped to nothing on assemblers other than Xcode. Thanks,Andrew Fish

ASM_FUNCTION_REMOVE_IF_UNREFERENCED.patch
Description: Binary data
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] BeagleBoneBlackPkg: Moving to Intel BDS

2014-11-06 Thread Olivier Martin 
What I sometimes do when I have potential problem with EFI device paths, I dump 
all the EFI device paths available.

It is important they exactly match what you are expected to use.

 

 

From: Varad Gautam [mailto:varadgau...@gmail.com] 
Sent: 05 November 2014 14:01
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] BeagleBoneBlackPkg: Moving to Intel BDS

 

I am now able to load the Intel BDS, but I'm having some trouble with receiving 
console
input with ArmPlatformPkg BDS or Intel BDS. I've got 

gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"VenHw(D3987D4B-971A-43
5F-8CAF-4967EB627241)/Uart(115200,8,N,1)/VenPcAnsi()"
gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|L"VenHw(D3987D4B-971A-435F
-8CAF-4967EB627241)/Uart(115200,8,N,1)/VenPcAnsi()"

as the default console paths [1], and have been digging around in 
ArmPlatformPkg/Bds 
to learn how the console devices are connected. The boot gets stuck at the 
selection 
prompt and does not register any input. Using the BeagleBoard BDS (which 
connects 
ConIn and ConOut by protocol guids rather than device paths [2]) works alright. 
I need 
some help to figure out how I can get ConIn working.

[1] 
https://github.com/varadgautam/edk2/blob/kern/TexasInstrumentsPkg/BeagleBoneBl
ackPkg/BeagleBoneBlackPkg.dsc#L309
[2] 
https://github.com/varadgautam/edk2/blob/kern/TexasInstrumentsPkg/BeagleBoneBl
ackPkg/Bds/BdsEntry.c#L110

Thanks,

Varad

 

 

On Tue, Oct 28, 2014 at 11:58 PM, Olivier Martin  wrote:

I have not really checked the history and your recent changes in details.
But until recently Intel BDS was requiring SMBios support.
I sent a patch to fix this dependency:
https://github.com/tianocore/edk2/commit/6d5b88f372180dc3a8622fda19ae0ac1fb0 

 
76ae8

I also added support for Intel BDS to ArmVirtualizationPkg (enabled by the
build flag INTEL_BDS).
You can easily see the Intel BDS requirements by looking for 'INTEL_BDS' in
the DSC and FDF files of this platform:
https://github.com/tianocore/edk2/blob/master/ArmPlatformPkg/ArmVirtualizati 

 
onPkg/ArmVirtualizationQemu.dsc

If you already have ArmPlatformPkg/Bds working on your platform, I would
recommend you to start with this implementation of PlatformBdsLib:
PlatformBdsLib|ArmPlatformPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLi
b.inf



> -Original Message-
> From: Varad Gautam [mailto:varadgau...@gmail.com]
> Sent: 28 October 2014 17:57
> To: edk2-devel@lists.sourceforge.net
> Subject: [edk2] BeagleBoneBlackPkg: Moving to Intel BDS
>
> Hi,
>
> I'm configuring BeagleBoneBlackPkg [1] to use
> IntelFrameworkModulePkg/Universal/BdsDxe. The build, after adding the
> dependencies hangs at [2]. What does 291:`InstallProtocolInterface:
> 348C4D62-BFBD-4882-9ECE-C80BB1C4783B 0` mean? Is HiiDatabaseDxe
> expecting
> a VFR form to load? Or does this indicate a missing module dependency?
>
> [1]
> https://github.com/varadgautam/edk2/tree/kern/TexasInstrumentsPkg/Beagl
> eBoneBlackPkg
> [2] http://fpaste.org/145882/14517581/
>
> Thanks,
> Varad
>

> ---

> ---
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel





--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

 
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] [BaseTools] Put all include search paths of a module into a file

2014-11-06 Thread Scott Duplichan 
Liu, Yingke D [mailto:yingke.d@intel.com]  wrote:

]Dear All,
]
]This patch is going to put all -I or /I options followed by include search 
path into a
]file (inc.lst) just as object files and static library files. There are cases 
that too
]many /I options on the command line, and NMAKE fails due to command-line 
length limitation.
]
]Please let me know any impact of this patch to you.
]
]Thanks,
]Dennis

Hello Dennis,

This patch is not working with Windows hosted gcc tools. The cause is the 
single back slash
path separator. I believe a single back slash in a gcc response file is 
interpreted as a
continuation character. The solution is to use either '/' or '\\' as the path 
separator.
When the include files are on the command line, I believe the mingw library 
code for path
processing fixes the back slash problem. But when a response file is used, the 
file
continuation character processing runs before the path processing code has a 
chance to
reverse the back slashes.

A question, why is the change not applied to [C-Code-File]? Isn't the $(CC) 
command it
generates the worst case for command line length?

Thanks,
Scott



--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] FE flag in IA32_MTRR_DEF_TYPE MSR

2014-11-06 Thread Brian J. Johnson 
On 11/05/2014 09:14 PM, tiger...@via-alliance.com wrote:
> Hi, experts:
>
> I am studying IA32/X64 Programmer manual.
>
> There is a sentence(Volume-3A, 10.11.5 Section):
>
> On a hardware reset, the P6 and more recent processors clear the valid
> flags in variable-range MTRRs and
>
> clear the E flag in the IA32_MTRR_DEF_TYPE MSR to disable
>
> all MTRRs. All other bits in the MTRRs are undefined.
>
> So, how about FE bit in IA32_MTRR_DEF_TYPE MSR?
>
> Is it also be cleared on a hardware reset?

I believe so.
-- 

 Brian



   Q: Why'd the guy get fired from his job at the orange juice factory?
   A: He couldn't concentrate!
-- Andy's Garage Sale

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH v2 3/6] OvmfPkg XenBusDxe: Convert Ia32/TestAndClearBit.asm to NASM

2014-11-06 Thread Anthony PERARD 
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert
Ia32/TestAndClearBit.asm to Ia32/TestAndClearBit.nasm

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD 
---
 OvmfPkg/XenBusDxe/Ia32/TestAndClearBit.S| 13 -
 .../Ia32/{TestAndClearBit.asm => TestAndClearBit.nasm}  |  7 +++
 OvmfPkg/XenBusDxe/XenBusDxe.inf |  3 +--
 3 files changed, 4 insertions(+), 19 deletions(-)
 delete mode 100644 OvmfPkg/XenBusDxe/Ia32/TestAndClearBit.S
 rename OvmfPkg/XenBusDxe/Ia32/{TestAndClearBit.asm => TestAndClearBit.nasm} 
(67%)

diff --git a/OvmfPkg/XenBusDxe/Ia32/TestAndClearBit.S 
b/OvmfPkg/XenBusDxe/Ia32/TestAndClearBit.S
deleted file mode 100644
index 58dfa8b..000
--- a/OvmfPkg/XenBusDxe/Ia32/TestAndClearBit.S
+++ /dev/null
@@ -1,13 +0,0 @@
-# INT32
-# EFIAPI
-# TestAndClearBit (
-#   IN  INT32 Bit,
-#   IN  volatile VOID* Address
-#   );
-ASM_GLOBAL ASM_PFX(TestAndClearBit)
-ASM_PFX(TestAndClearBit):
-  mov 4(%esp), %ecx
-  mov 8(%esp), %edx
-  lock btrl %ecx, (%edx)
-  sbbl %eax, %eax
-  ret
diff --git a/OvmfPkg/XenBusDxe/Ia32/TestAndClearBit.asm 
b/OvmfPkg/XenBusDxe/Ia32/TestAndClearBit.nasm
similarity index 67%
rename from OvmfPkg/XenBusDxe/Ia32/TestAndClearBit.asm
rename to OvmfPkg/XenBusDxe/Ia32/TestAndClearBit.nasm
index ac80902..d77f74e 100644
--- a/OvmfPkg/XenBusDxe/Ia32/TestAndClearBit.asm
+++ b/OvmfPkg/XenBusDxe/Ia32/TestAndClearBit.nasm
@@ -1,4 +1,4 @@
-.code
+SECTION .text
 
 ; INT32
 ; EFIAPI
@@ -6,12 +6,11 @@
 ;   IN  INT32 Bit,
 ;   IN  volatile VOID* Address
 ;   );
-TestAndClearBit PROC
+global ASM_PFX(TestAndClearBit)
+ASM_PFX(TestAndClearBit):
   mov ecx, [esp + 4]
   mov edx, [esp + 8]
   lock btr [edx], ecx
   sbb eax, eax
   ret
-TestAndClearBit ENDP
 
-END
diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.inf b/OvmfPkg/XenBusDxe/XenBusDxe.inf
index 292e488..b421b85 100644
--- a/OvmfPkg/XenBusDxe/XenBusDxe.inf
+++ b/OvmfPkg/XenBusDxe/XenBusDxe.inf
@@ -51,8 +51,7 @@
 [Sources.IA32]
   Ia32/hypercall.nasm
   Ia32/InterlockedCompareExchange16.nasm
-  Ia32/TestAndClearBit.S
-  Ia32/TestAndClearBit.asm
+  Ia32/TestAndClearBit.nasm
 
 [Sources.X64]
   X64/hypercall.S
-- 
Anthony PERARD


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH v2 6/6] OvmfPkg XenBusDxe: Convert X64/TestAndClearBit.asm to NASM

2014-11-06 Thread Anthony PERARD 
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert
X64/TestAndClearBit.asm to X64/TestAndClearBit.nasm

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD 
---
 OvmfPkg/XenBusDxe/X64/TestAndClearBit.S  | 12 
 .../X64/{TestAndClearBit.asm => TestAndClearBit.nasm}|  8 
 OvmfPkg/XenBusDxe/XenBusDxe.inf  |  3 +--
 3 files changed, 5 insertions(+), 18 deletions(-)
 delete mode 100644 OvmfPkg/XenBusDxe/X64/TestAndClearBit.S
 rename OvmfPkg/XenBusDxe/X64/{TestAndClearBit.asm => TestAndClearBit.nasm} 
(63%)

diff --git a/OvmfPkg/XenBusDxe/X64/TestAndClearBit.S 
b/OvmfPkg/XenBusDxe/X64/TestAndClearBit.S
deleted file mode 100644
index 0372e83..000
--- a/OvmfPkg/XenBusDxe/X64/TestAndClearBit.S
+++ /dev/null
@@ -1,12 +0,0 @@
-# INT32
-# EFIAPI
-# TestAndClearBit (
-#   IN  INT32 Bit,// rcx
-#   IN  volatile VOID* Address// rdx
-#   );
-ASM_GLOBAL ASM_PFX(TestAndClearBit)
-ASM_PFX(TestAndClearBit):
-  lock
-  btrl %ecx, (%rdx)
-  sbbl %eax, %eax
-  ret
diff --git a/OvmfPkg/XenBusDxe/X64/TestAndClearBit.asm 
b/OvmfPkg/XenBusDxe/X64/TestAndClearBit.nasm
similarity index 63%
rename from OvmfPkg/XenBusDxe/X64/TestAndClearBit.asm
rename to OvmfPkg/XenBusDxe/X64/TestAndClearBit.nasm
index 3a25879..38ac549 100644
--- a/OvmfPkg/XenBusDxe/X64/TestAndClearBit.asm
+++ b/OvmfPkg/XenBusDxe/X64/TestAndClearBit.nasm
@@ -1,4 +1,5 @@
-.code
+DEFAULT REL
+SECTION .text
 
 ; INT32
 ; EFIAPI
@@ -6,11 +7,10 @@
 ;   IN  INT32 Bit,// rcx
 ;   IN  volatile VOID* Address// rdx
 ;   );
-TestAndClearBit PROC
+global ASM_PFX(TestAndClearBit)
+ASM_PFX(TestAndClearBit):
   lock
   btr [rdx], ecx
   sbb eax, eax
   ret
-TestAndClearBit ENDP
 
-END
diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.inf b/OvmfPkg/XenBusDxe/XenBusDxe.inf
index 61f7568..4ce4743 100644
--- a/OvmfPkg/XenBusDxe/XenBusDxe.inf
+++ b/OvmfPkg/XenBusDxe/XenBusDxe.inf
@@ -56,8 +56,7 @@
 [Sources.X64]
   X64/hypercall.nasm
   X64/InterlockedCompareExchange16.nasm
-  X64/TestAndClearBit.S
-  X64/TestAndClearBit.asm
+  X64/TestAndClearBit.nasm
 
 [LibraryClasses]
   UefiDriverEntryPoint
-- 
Anthony PERARD


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH v2 5/6] OvmfPkg XenBusDxe: Convert X64/InterlockedCompareExchange16.asm to NASM

2014-11-06 Thread Anthony PERARD 
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert
X64/InterlockedCompareExchange16.asm to X64/InterlockedCompareExchange16.nasm

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD 
---
 OvmfPkg/XenBusDxe/X64/InterlockedCompareExchange16.S| 13 -
 ...pareExchange16.asm => InterlockedCompareExchange16.nasm} |  8 
 OvmfPkg/XenBusDxe/XenBusDxe.inf |  3 +--
 3 files changed, 5 insertions(+), 19 deletions(-)
 delete mode 100644 OvmfPkg/XenBusDxe/X64/InterlockedCompareExchange16.S
 rename OvmfPkg/XenBusDxe/X64/{InterlockedCompareExchange16.asm => 
InterlockedCompareExchange16.nasm} (88%)

diff --git a/OvmfPkg/XenBusDxe/X64/InterlockedCompareExchange16.S 
b/OvmfPkg/XenBusDxe/X64/InterlockedCompareExchange16.S
deleted file mode 100644
index 23e08f3..000
--- a/OvmfPkg/XenBusDxe/X64/InterlockedCompareExchange16.S
+++ /dev/null
@@ -1,13 +0,0 @@
-# UINT16
-# EFIAPI
-# InternalSyncCompareExchange16 (
-#   IN  volatile UINT16   *Value,
-#   IN  UINT16CompareValue,
-#   IN  UINT16ExchangeValue
-#   );
-ASM_GLOBAL ASM_PFX(InternalSyncCompareExchange16)
-ASM_PFX(InternalSyncCompareExchange16):
-  mov %edx, %eax
-  lock
-  cmpxchgw %r8w, (%rcx)
-  ret
diff --git a/OvmfPkg/XenBusDxe/X64/InterlockedCompareExchange16.asm 
b/OvmfPkg/XenBusDxe/X64/InterlockedCompareExchange16.nasm
similarity index 88%
rename from OvmfPkg/XenBusDxe/X64/InterlockedCompareExchange16.asm
rename to OvmfPkg/XenBusDxe/X64/InterlockedCompareExchange16.nasm
index b23e421..048d1f3 100644
--- a/OvmfPkg/XenBusDxe/X64/InterlockedCompareExchange16.asm
+++ b/OvmfPkg/XenBusDxe/X64/InterlockedCompareExchange16.nasm
@@ -21,7 +21,8 @@
 ;
 ;--
 
-.code
+DEFAULT REL
+SECTION .text
 
 ;--
 ; UINT16
@@ -32,10 +33,9 @@
 ;   IN  UINT16ExchangeValue
 ;   );
 ;--
-InternalSyncCompareExchange16   PROC
+global ASM_PFX(InternalSyncCompareExchange16)
+ASM_PFX(InternalSyncCompareExchange16):
 mov eax, edx
 lockcmpxchg [rcx], r8w
 ret
-InternalSyncCompareExchange16   ENDP
 
-END
diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.inf b/OvmfPkg/XenBusDxe/XenBusDxe.inf
index 3309f53..61f7568 100644
--- a/OvmfPkg/XenBusDxe/XenBusDxe.inf
+++ b/OvmfPkg/XenBusDxe/XenBusDxe.inf
@@ -55,8 +55,7 @@
 
 [Sources.X64]
   X64/hypercall.nasm
-  X64/InterlockedCompareExchange16.S
-  X64/InterlockedCompareExchange16.asm
+  X64/InterlockedCompareExchange16.nasm
   X64/TestAndClearBit.S
   X64/TestAndClearBit.asm
 
-- 
Anthony PERARD


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH v2 0/6] OvmfPkg/XenBusDxe: Convert *.asm to NASM.

2014-11-06 Thread Anthony PERARD 
Conversion done using the tools BaseTools/Scripts/ConvertMasmToNasm.py

Change in V2:
  - one commit per assembly source files.

Anthony PERARD (6):
  OvmfPkg XenBusDxe: Convert Ia32/hypercall.asm to NASM
  OvmfPkg XenBusDxe: Convert Ia32/InterlockedCompareExchange16.asm to
NASM
  OvmfPkg XenBusDxe: Convert Ia32/TestAndClearBit.asm to NASM
  OvmfPkg XenBusDxe: Convert X64/hypercall.asm to NASM
  OvmfPkg XenBusDxe: Convert X64/InterlockedCompareExchange16.asm to
NASM
  OvmfPkg XenBusDxe: Convert X64/TestAndClearBit.asm to NASM

 .../XenBusDxe/Ia32/InterlockedCompareExchange16.S  | 15 ---
 ...nge16.asm => InterlockedCompareExchange16.nasm} |  9 +++--
 OvmfPkg/XenBusDxe/Ia32/TestAndClearBit.S   | 13 -
 .../{TestAndClearBit.asm => TestAndClearBit.nasm}  |  7 +++
 OvmfPkg/XenBusDxe/Ia32/hypercall.S | 22 --
 .../Ia32/{hypercall.asm => hypercall.nasm} |  7 +++
 .../XenBusDxe/X64/InterlockedCompareExchange16.S   | 13 -
 ...nge16.asm => InterlockedCompareExchange16.nasm} |  8 
 OvmfPkg/XenBusDxe/X64/TestAndClearBit.S| 12 
 .../{TestAndClearBit.asm => TestAndClearBit.nasm}  |  8 
 OvmfPkg/XenBusDxe/X64/hypercall.S  | 22 --
 .../X64/{hypercall.asm => hypercall.nasm}  |  8 
 OvmfPkg/XenBusDxe/XenBusDxe.inf| 18 ++
 13 files changed, 27 insertions(+), 135 deletions(-)
 delete mode 100644 OvmfPkg/XenBusDxe/Ia32/InterlockedCompareExchange16.S
 rename OvmfPkg/XenBusDxe/Ia32/{InterlockedCompareExchange16.asm => 
InterlockedCompareExchange16.nasm} (88%)
 delete mode 100644 OvmfPkg/XenBusDxe/Ia32/TestAndClearBit.S
 rename OvmfPkg/XenBusDxe/Ia32/{TestAndClearBit.asm => TestAndClearBit.nasm} 
(67%)
 delete mode 100644 OvmfPkg/XenBusDxe/Ia32/hypercall.S
 rename OvmfPkg/XenBusDxe/Ia32/{hypercall.asm => hypercall.nasm} (83%)
 delete mode 100644 OvmfPkg/XenBusDxe/X64/InterlockedCompareExchange16.S
 rename OvmfPkg/XenBusDxe/X64/{InterlockedCompareExchange16.asm => 
InterlockedCompareExchange16.nasm} (88%)
 delete mode 100644 OvmfPkg/XenBusDxe/X64/TestAndClearBit.S
 rename OvmfPkg/XenBusDxe/X64/{TestAndClearBit.asm => TestAndClearBit.nasm} 
(63%)
 delete mode 100644 OvmfPkg/XenBusDxe/X64/hypercall.S
 rename OvmfPkg/XenBusDxe/X64/{hypercall.asm => hypercall.nasm} (77%)

-- 
Anthony PERARD


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH v2 2/6] OvmfPkg XenBusDxe: Convert Ia32/InterlockedCompareExchange16.asm to NASM

2014-11-06 Thread Anthony PERARD 
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert
Ia32/InterlockedCompareExchange16.asm to Ia32/InterlockedCompareExchange16.nasm

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD 
---
 OvmfPkg/XenBusDxe/Ia32/InterlockedCompareExchange16.S | 15 ---
 ...reExchange16.asm => InterlockedCompareExchange16.nasm} |  9 +++--
 OvmfPkg/XenBusDxe/XenBusDxe.inf   |  3 +--
 3 files changed, 4 insertions(+), 23 deletions(-)
 delete mode 100644 OvmfPkg/XenBusDxe/Ia32/InterlockedCompareExchange16.S
 rename OvmfPkg/XenBusDxe/Ia32/{InterlockedCompareExchange16.asm => 
InterlockedCompareExchange16.nasm} (88%)

diff --git a/OvmfPkg/XenBusDxe/Ia32/InterlockedCompareExchange16.S 
b/OvmfPkg/XenBusDxe/Ia32/InterlockedCompareExchange16.S
deleted file mode 100644
index 5306448..000
--- a/OvmfPkg/XenBusDxe/Ia32/InterlockedCompareExchange16.S
+++ /dev/null
@@ -1,15 +0,0 @@
-# UINT16
-# EFIAPI
-# InternalSyncCompareExchange16 (
-#   IN  volatile UINT16   *Value,
-#   IN  UINT16CompareValue,
-#   IN  UINT16ExchangeValue
-#   );
-ASM_GLOBAL ASM_PFX(InternalSyncCompareExchange16)
-ASM_PFX(InternalSyncCompareExchange16):
-  mov 4(%esp), %ecx
-  mov 8(%esp), %eax
-  mov 12(%esp), %edx
-  lock
-  cmpxchgw %dx, (%ecx)
-  ret
diff --git a/OvmfPkg/XenBusDxe/Ia32/InterlockedCompareExchange16.asm 
b/OvmfPkg/XenBusDxe/Ia32/InterlockedCompareExchange16.nasm
similarity index 88%
rename from OvmfPkg/XenBusDxe/Ia32/InterlockedCompareExchange16.asm
rename to OvmfPkg/XenBusDxe/Ia32/InterlockedCompareExchange16.nasm
index adcfbd0..d45582d 100644
--- a/OvmfPkg/XenBusDxe/Ia32/InterlockedCompareExchange16.asm
+++ b/OvmfPkg/XenBusDxe/Ia32/InterlockedCompareExchange16.nasm
@@ -21,9 +21,7 @@
 ;
 ;--
 
-.486
-.model  flat,C
-.code
+SECTION .text
 
 ;--
 ; UINT32
@@ -34,12 +32,11 @@
 ;   IN  UINT16ExchangeValue
 ;   );
 ;--
-InternalSyncCompareExchange16   PROC
+global ASM_PFX(InternalSyncCompareExchange16)
+ASM_PFX(InternalSyncCompareExchange16):
 mov ecx, [esp + 4]
 mov eax, [esp + 8]
 mov edx, [esp + 12]
 lockcmpxchg [ecx], dx
 ret
-InternalSyncCompareExchange16   ENDP
 
-END
diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.inf b/OvmfPkg/XenBusDxe/XenBusDxe.inf
index 2478e35..292e488 100644
--- a/OvmfPkg/XenBusDxe/XenBusDxe.inf
+++ b/OvmfPkg/XenBusDxe/XenBusDxe.inf
@@ -50,8 +50,7 @@
 
 [Sources.IA32]
   Ia32/hypercall.nasm
-  Ia32/InterlockedCompareExchange16.S
-  Ia32/InterlockedCompareExchange16.asm
+  Ia32/InterlockedCompareExchange16.nasm
   Ia32/TestAndClearBit.S
   Ia32/TestAndClearBit.asm
 
-- 
Anthony PERARD


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH v2 1/6] OvmfPkg XenBusDxe: Convert Ia32/hypercall.asm to NASM

2014-11-06 Thread Anthony PERARD 
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert
Ia32/hypercall.asm to Ia32/hypercall.nasm

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD 
---
 OvmfPkg/XenBusDxe/Ia32/hypercall.S | 22 --
 .../Ia32/{hypercall.asm => hypercall.nasm} |  7 +++
 OvmfPkg/XenBusDxe/XenBusDxe.inf|  3 +--
 3 files changed, 4 insertions(+), 28 deletions(-)
 delete mode 100644 OvmfPkg/XenBusDxe/Ia32/hypercall.S
 rename OvmfPkg/XenBusDxe/Ia32/{hypercall.asm => hypercall.nasm} (83%)

diff --git a/OvmfPkg/XenBusDxe/Ia32/hypercall.S 
b/OvmfPkg/XenBusDxe/Ia32/hypercall.S
deleted file mode 100644
index 77d3478..000
--- a/OvmfPkg/XenBusDxe/Ia32/hypercall.S
+++ /dev/null
@@ -1,22 +0,0 @@
-# INTN
-# EFIAPI
-# XenHypercall2 (
-#   IN VOID *HypercallAddr,
-#   IN OUT INTN Arg1,
-#   IN OUT INTN Arg2
-#   );
-ASM_GLOBAL ASM_PFX(XenHypercall2)
-ASM_PFX(XenHypercall2):
-  # Save only ebx, ecx is supposed to be a scratch register and needs to be
-  # saved by the caller
-  push %ebx
-  # Copy HypercallAddr to eax
-  mov 8(%esp), %eax
-  # Copy Arg1 to the register expected by Xen
-  mov 12(%esp), %ebx
-  # Copy Arg2 to the register expected by Xen
-  mov 16(%esp), %ecx
-  # Call HypercallAddr
-  call *%eax
-  pop %ebx
-  ret
diff --git a/OvmfPkg/XenBusDxe/Ia32/hypercall.asm 
b/OvmfPkg/XenBusDxe/Ia32/hypercall.nasm
similarity index 83%
rename from OvmfPkg/XenBusDxe/Ia32/hypercall.asm
rename to OvmfPkg/XenBusDxe/Ia32/hypercall.nasm
index 9ead740..8547c30 100644
--- a/OvmfPkg/XenBusDxe/Ia32/hypercall.asm
+++ b/OvmfPkg/XenBusDxe/Ia32/hypercall.nasm
@@ -1,4 +1,4 @@
-.code
+SECTION .text
 
 ; INTN
 ; EFIAPI
@@ -7,7 +7,8 @@
 ;   IN OUT INTN Arg1,
 ;   IN OUT INTN Arg2
 ;   );
-XenHypercall2 PROC
+global ASM_PFX(XenHypercall2)
+ASM_PFX(XenHypercall2):
   ; Save only ebx, ecx is supposed to be a scratch register and needs to be
   ; saved by the caller
   push ebx
@@ -21,6 +22,4 @@ XenHypercall2 PROC
   call eax
   pop ebx
   ret
-XenHypercall2 ENDP
 
-END
diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.inf b/OvmfPkg/XenBusDxe/XenBusDxe.inf
index 17a5a90..2478e35 100644
--- a/OvmfPkg/XenBusDxe/XenBusDxe.inf
+++ b/OvmfPkg/XenBusDxe/XenBusDxe.inf
@@ -49,8 +49,7 @@
   Helpers.c
 
 [Sources.IA32]
-  Ia32/hypercall.S
-  Ia32/hypercall.asm
+  Ia32/hypercall.nasm
   Ia32/InterlockedCompareExchange16.S
   Ia32/InterlockedCompareExchange16.asm
   Ia32/TestAndClearBit.S
-- 
Anthony PERARD


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH v2 4/6] OvmfPkg XenBusDxe: Convert X64/hypercall.asm to NASM

2014-11-06 Thread Anthony PERARD 
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert
X64/hypercall.asm to X64/hypercall.nasm

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD 
---
 OvmfPkg/XenBusDxe/X64/hypercall.S  | 22 --
 .../X64/{hypercall.asm => hypercall.nasm}  |  8 
 OvmfPkg/XenBusDxe/XenBusDxe.inf|  3 +--
 3 files changed, 5 insertions(+), 28 deletions(-)
 delete mode 100644 OvmfPkg/XenBusDxe/X64/hypercall.S
 rename OvmfPkg/XenBusDxe/X64/{hypercall.asm => hypercall.nasm} (77%)

diff --git a/OvmfPkg/XenBusDxe/X64/hypercall.S 
b/OvmfPkg/XenBusDxe/X64/hypercall.S
deleted file mode 100644
index 83cf466..000
--- a/OvmfPkg/XenBusDxe/X64/hypercall.S
+++ /dev/null
@@ -1,22 +0,0 @@
-# INTN
-# EFIAPI
-# XenHypercall2 (
-#   IN VOID *HypercallAddr,
-#   IN OUT INTN Arg1,
-#   IN OUT INTN Arg2
-#   );
-ASM_GLOBAL ASM_PFX(XenHypercall2)
-ASM_PFX(XenHypercall2):
-  push %rdi
-  push %rsi
-  # Copy HypercallAddr to rax
-  movq %rcx, %rax
-  # Copy Arg1 to the register expected by Xen
-  movq %rdx, %rdi
-  # Copy Arg2 to the register expected by Xen
-  movq %r8, %rsi
-  # Call HypercallAddr
-  call *%rax
-  pop %rsi
-  pop %rdi
-  ret
diff --git a/OvmfPkg/XenBusDxe/X64/hypercall.asm 
b/OvmfPkg/XenBusDxe/X64/hypercall.nasm
similarity index 77%
rename from OvmfPkg/XenBusDxe/X64/hypercall.asm
rename to OvmfPkg/XenBusDxe/X64/hypercall.nasm
index 5b34514..177f271 100644
--- a/OvmfPkg/XenBusDxe/X64/hypercall.asm
+++ b/OvmfPkg/XenBusDxe/X64/hypercall.nasm
@@ -1,4 +1,5 @@
-.code
+DEFAULT REL
+SECTION .text
 
 ; INTN
 ; EFIAPI
@@ -7,7 +8,8 @@
 ;   IN OUT INTN Arg1,
 ;   IN OUT INTN Arg2
 ;   );
-XenHypercall2 PROC
+global ASM_PFX(XenHypercall2)
+ASM_PFX(XenHypercall2):
   push rdi
   push rsi
   ; Copy HypercallAddr to rax
@@ -21,6 +23,4 @@ XenHypercall2 PROC
   pop rsi
   pop rdi
   ret
-XenHypercall2 ENDP
 
-END
diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.inf b/OvmfPkg/XenBusDxe/XenBusDxe.inf
index b421b85..3309f53 100644
--- a/OvmfPkg/XenBusDxe/XenBusDxe.inf
+++ b/OvmfPkg/XenBusDxe/XenBusDxe.inf
@@ -54,8 +54,7 @@
   Ia32/TestAndClearBit.nasm
 
 [Sources.X64]
-  X64/hypercall.S
-  X64/hypercall.asm
+  X64/hypercall.nasm
   X64/InterlockedCompareExchange16.S
   X64/InterlockedCompareExchange16.asm
   X64/TestAndClearBit.S
-- 
Anthony PERARD


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 000/345] Convert EDK II core packages to NASM for IA32/X64

2014-11-06 Thread Andrew Fish 

> On Nov 6, 2014, at 1:42 AM, Andrew Fish  wrote:
> 
>> 
>> On Nov 6, 2014, at 12:26 AM, Jordan Justen > > wrote:
>> 
>> On 2014-11-05 20:29:46, Andrew Fish wrote:
>>> 
>>>On Nov 5, 2014, at 7:51 PM, Jordan Justen >> >
>>>wrote:
>>> 
>>>On 2014-11-05 19:19:26, Andrew Fish wrote:
>>>On Nov 5, 2014, at 6:47 PM, Gao, Liming >> >
>>>wrote:
>>> 
>>>Jordan:
>>>This patch updates module INF with .nasm only, and remove the
>>>original .asm and .S. Right?
>>> 
>>>After apply this patch, all developers are required to install 
>>> nasm
>>>compiler.
>>> 
>>>We require the option of NOT using nasm with the XCODE target.
>>> 
>>>MdePkg has required NASM for Thunk16 IA32 and X64 (except MSFT/INTEL
>>>based toolchains) for 2 months now. (Since Sept 1st.)
>>> 
>>>That hasn't been an issue?
>>> 
>>> Because it is is easy to change a single file in an INF file to make it work
>>> without NASM.
>> 
>> Does that mean that these trees are separate from EDK II, or UDK? So,
>> maybe one solution would be a patch file or git branch that contains
>> the .S files?
>> 
>> Which packages would that be required for?
>> 
> 
> I think you have it backwards. Adding NASM to UDK is breaking it for us. So 
> the UDK release need to support .S files. 
> 
>>> Folks are probably not doing production builds on the edk2 TOT, the
>>> production builds are being done on the UDK2014.
>> 
>> Ah, so UDK2014 releases are more important? Meaning maybe the patch
>> file could be produced only for those releases?
>> 
> 
> The UDK2014 should NOT move to NASM and still support .S files. 
> 
> When is the Intel reference code going to be coded in NASM? I’d be willing to 
> discuss dropping .S files from the UDK when all the Intel reference code is 
> coded in NASM and not MASM. 
> 
>>> In our world we don’t control the build servers, we don’t install
>>> the tools on the build server, and if we try to check in a binary it
>>> gets rejected. Not to mention I would rather walk down the hall and
>>> talk to the tools developers than fly to Europe if I have an issue.
>> 
>> Is NASM just plain incompatible with XCODE?
>> 
> 
> We prefer to use the tools we make and Xcode contains an assembler, so we 
> would like to use that. I can walk into the office and talk to the tools team 
> face to face, I’d need to fly to Europe to talk the NASM guys.
> It is safer to use a complete tools set than mix and match tools. For example 
> with NASM we now have 2 different code bases that generate Mach-O objects 
> that need to get linked together. 
> 
>> If not, I guess one other possible solution would be to pull NASM into
>> BaseTools. It is an idea that's been mentioned, but is (obviously) not
>> a first choice.
>> 
>>> So the change to NASM buys us nothing, introduces risk, causes a lot
>>> of extra work.
>>> 
>>> I picked a random edk2/MdePkg .S file and the code has not been
>>> updated since 2009, and the file not modified since 2010. What
>>> problem are we solving again?
>> 
>> Some benefits of NASM:
>> 
>> * A single cross platform assembly file for either IA32 or X64
>> 
> 
> Changing every assembly file is some what risky. 
> 
>> * Often both MASM and GNU assembly end up requiring 'db' gymnastics
>>  that produces unreadable/unmaintainable code. (Did you see the
>>  Thunk16.asm/.S freak show?)
>> 
> 
> Yes that was bad, but that code will likely not change for the next 10 years. 
> 
>> * Many developers only work on Windows, and therefore never bother to
>>  code a .S file. Most commonly, this results in code modules that
>>  only builds on Windows.
>> 
> 
> Yes and a lot of them work for Intel. Why don’t you fix that problem 1st.
> 
>> * In some rare cases an effort is made to port to a .S file. This
>>  often results in code that is really ugly, non-functional,
>>  not-functional for all toolchains, or functional somewhat by luck.
>>  See again: Thunk16
>> 
> 
> We have been using .S files for a while and we don’t generally have issues. 
> 
>> * One sore spot for MASM vs. GNU assembly has been the 'VTF' file,
>>  which for many platforms has source code that looks like
>>  IntelFspPkg/FspSecCore/Ia32/ResetVec.asm16. We finally have a cross
>>  platform version at UefiCpuPkg/ResetVector/FixupVtf/Vtf.nasmb
>> 
> 
> We don’t have any issue generating this code today with Xcode. It is mostly a 
> copy paste from project to project. 
> 
> There is not a lot of “New” 16-bit code getting written these days. It is all 
> the same code sequences forced on us by Intel. 
> 
>> * Related to .asm16, it depends on getting a 16-bit version of MASM
>>  that seems increasingly difficult to obtain, and seemingly is not
>>  actively developed. (Or, is it the 16-bit linker... ??)
>> 
> 
> Not an issue for us, we support .S16 with Xcode. 
> 
>> * NASM is also:
>>  * active

Re: [edk2] [PATCH 000/345] Convert EDK II core packages to NASM for IA32/X64

2014-11-06 Thread Sergey Isakov 

On 06.11.2014, at 11:26, Jordan Justen wrote:

> Is NASM just plain incompatible with XCODE?

I see no problems. It is compatible with key
*_XCODE5_X64_NASM_FLAGS = -f macho64--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [RFC PATCH V7 00/27] Introduce Mp Service protocol to UefiCpuPkg

2014-11-06 Thread Chen, Fan 
On Thu, 2014-11-06 at 06:11 +, Fan, Jeff wrote: 
> Chen,
> 
> Thanks your updating. I attached one addition updating based on you're the 
> latest patches. Please evaluate and sync it into your patches.
> 
> BTW, please delete ApStartup.asm from CpuDxe, it seems to be one dummy file.
Thanks for you review.
I had merged the changes to my patches as you attachment said. see at:
  https://github.com/ChenFanFnst/edk2/tree/cpu-mp-service

and as for file ApStartup.asm, I moved the asm code to ApStartup.c as
comments for guiding to create startup code, then deleted ApStartup.asm.


Thanks,
Chen


> 
> Thanks!
> Jeff
> -Original Message-
> From: Chen Fan [mailto:chen.fan.f...@cn.fujitsu.com] 
> Sent: Tuesday, November 04, 2014 5:59 PM
> To: edk2-devel@lists.sourceforge.net
> Cc: Jordan Justen; Fan, Jeff; izumi.t...@jp.fujitsu.com
> Subject: [RFC PATCH V7 00/27] Introduce Mp Service protocol to UefiCpuPkg
> 
> This series patchsets try to implement Mp Service protocol in UefiCpuPkg, 
> Jordan had implemented the startup APs code, and I try to add more 
> initialization code to let all APs work up, this Mp Service protocol's 
> implementation used EmulatorPkg/MpService for reference.
> this patches works on my github:
>   https://github.com/ChenFanFnst/edk2/tree/cpu-mp-service
> 
> and made StartCorePkg app for testing Mp Service Protocol on:
>   https://github.com/ChenFanFnst/edk2/tree/startcore
> 
> I had tested the Mp protocol with the test code, and all cases passed.
> 
>   v6-v7:
>   1. fix some trivial bugs pointed out by Jeff.
>   2. free unused cpu buffer data.
> 
>   v5-v6:
>   1. using only one timer to check all APs status instead of timers for each 
> AP.
>   2. cancel timer each time avoid timer handler reentrancy.
>   3. some bug fix.
> 
>   v4-v5:
>   1. introduce PcdCpuMaxLogicalProcessorNumber to pre-allocate
>  stack buffer before starting the APs.
>   2. implement the function that if procedure routine timeout,
>  reset AP by sending init ipi.
>   3. some bug fix.
> 
>   v3-v4:
>   1. change the order of the patches.
>   2. update some minor format suggested by Jeff.
>   3. add a PCD value to configure StackSize.
>   4. the last patch add assembly code for MSFT, but didn't
>  test.
> 
>   V3-V3.1:
>   1. use AcquireSpinLockOrFail() intead of AcquireSpinLock()
>  to avoid ASSERT sugguested by Jeff.
> 
>   V2-V3:
>   1. rebase codes due to Jordan'tree updated:
>  https://github.com/jljusten/edk2/tree/ap-startup-example
>   2. add supported on Ia32 arch
>   3. add a new Lock to replace present SpinLock mechanisms in mutilple
>  processors, maybe the SpinLock mechanisms is not MP safe.
>   4. add function header
>   5. add StartupAllAPs() supported
>   6. add SwitchBSP() function, which is unsupported.
> 
>   V1-V2:
>   1. do not call anything EFI API from APs.
>   2. add AP busy-wait for task assignment from BSP and get rid of
>  IPI sent mechanism.
> 
> Chen Fan (22):
>   UefiCpuPkg/CpuDxe: introduce two PCD value
>   UefiCpuPkg/CpuDxe: Switch Ap Stack to NewStack
>   UefiCpuPkg/CpuDxe: introduce EFI_MP_SERVICES_PROTOCOL
>   UefiCpuPkg/CpuDxe: introduce MP_SYSTEM_DATA for Mp Service Protocol
>   UefiCpuPkg/CpuDxe: implement Mp Protocol: WhoAmI()
>   UefiCpuPkg/CpuDxe: implement Mp Protocol:GetNumberOfProcessors()
>   UefiCpuPkg/CpuDxe: implement Mp Services:GetProcessorInfo()
>   UefiCpuPkg/CpuDxe: implement Mp Protocol:EnableDisableAP()
>   UefiCpuPkg/CpuDxe: implement Mp Protocol:StartupThisAP()
>   UefiCpuPkg/CpuDxe: implement Mp Services:StartupAllAPs()
>   UefiCpuPkg/CpuDxe: implement Mp Services:SwitchBSP()
>   UefiCpuPkg/CpuDxe: Ap do loop routine to execute procedure
>   UefiCpuPkg/MpService: move settimer out to InitMpSystemData
>   UefiCpuPkg/MpService: Simply Lock usage
>   UefiCpuPkg/MpService: avoid next timer getting into
> CheckAllAPsStatus()
>   UefiCpuPkg/CpuDxe: split out StartupCode from StartApsStackless()
>   UefiCpuPkg/CpuDxe: introduce ResetApStackless()
>   UefiCpuPkg/MpService: free the unused cpu data buffer
>   UefiCpuPkg/MpService: avoid reset AP still hold a lock
>   UefiCpuPkg/MpService: avoid dead lock caused by CheckAllAPsStatus
>   UefiCpuPkg/CpuDxe: Startup APs
>   UefiCpuPkg/CpuDxe: install Mp Service protocol
> 
> Jordan Justen (5):
>   UefiCpuPkg/CpuDxe: Add no-op InitializeMpSupport
>   UefiCpuPkg/CpuDxe: Add ApEntryPointInC
>   UefiCpuPkg/CpuDxe: Add stackless assembly AP entry points
>   UefiCpuPkg/CpuDxe: Move GDT structures into CpuGdt.h
>   UefiCpuPkg/CpuDxe: Add StartApsStackless routine
> 
>  UefiCpuPkg/CpuDxe/ApStartup.asm   |  111 +++
>  UefiCpuPkg/CpuDxe/ApStartup.c |  252 ++
>  UefiCpuPkg/CpuDxe/CpuDxe.c|3 +
>  UefiCpuPkg/CpuDxe/CpuDxe.h|1 +
>  UefiCpuPkg/CpuDxe/CpuDxe.inf  |   17 +
>  UefiCpuPkg/CpuDxe/CpuGdt.c|   52 +-
>  UefiCpuPkg/CpuDxe/CpuGdt.h|   72 ++
>  UefiCpuPkg/CpuDxe/CpuMp.c | 1534 
> +
>  UefiCpuPkg

Re: [edk2] [PATCH v2 2/9] IntelFrameworkModulePkg: BdsDxe: poll keyboard at front page with zero timeout

2014-11-06 Thread Dong, Eric 
Laszlo,

I have checked in my code at r16304.

Thanks,
Eric

-Original Message-
From: Jordan Justen [mailto:jordan.l.jus...@intel.com] 
Sent: Thursday, November 06, 2014 2:16 AM
To: Laszlo Ersek; edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH v2 2/9] IntelFrameworkModulePkg: BdsDxe: poll 
keyboard at front page with zero timeout

On 2014-11-04 11:41:50, Laszlo Ersek wrote:
> Jordan, if you drop the first two patches form this series, then the 
> rest (patches v2 3/9 to 9/9) apply just as fine, and work as intended 
> (on top of Eric's patch). If you're OK with the series in that form 
> (as in, R-b), then I'll await Eric's commit, and then push patches 3 
> to 9 on top.

Yeah. You can add Reviewed-by: Jordan Justen  for 
patches 3-9.

-Jordan

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH v3 5/5] MdeModulePkg; IdeMode select master/slave before diagnostics command

2014-11-06 Thread Tian, Feng 
Hi, Reza

I did a bigger scope test on your proposed patch. it will bring issue when a 
HDD is in primary master and a cdrom is in primary slave at Intel DQ57 
platform.. The cdrom may be identified as HDD and will get a ABORT error for 
IDENTIFY cmd.

To solve this issue,  I modified your code like attachment (set device select 
before and after DIAG cmd rather than only before this cmd). This way works at 
my test platform. Please review and help test it at Qemu.

Thanks
Feng
-Original Message-
From: reza.jel...@tuhh.de [mailto:reza.jel...@tuhh.de] 
Sent: Thursday, October 23, 2014 07:02
To: edk2-devel@lists.sourceforge.net
Cc: Zeng, Star; Tian, Feng; ler...@redhat.com; asava@gmail.com; Reza Jelveh
Subject: [PATCH v3 5/5] MdeModulePkg; IdeMode select master/slave before 
diagnostics command

From: Reza Jelveh 

Some Ide controllers only update ID fields such as sector information on 
specific commands such as the DIAG command.

The master/slave device is therefore selected before sending the DIAG command 
otherwise reading the IDE registers yields the masters ID fields.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Reza Jelveh 
---
 MdeModulePkg/Bus/Ata/AtaAtapiPassThru/IdeMode.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/IdeMode.c 
b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/IdeMode.c
index e5beea6..35330e2 100644
--- a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/IdeMode.c
+++ b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/IdeMode.c
@@ -2593,6 +2593,11 @@ DetectAndConfigIdeDevice (
 
   for (IdeDevice = 0; IdeDevice < EfiIdeMaxDevice; IdeDevice++) {
 //
+// Select Master or Slave device to get the return signature for ATA 
DEVICE DIAGNOSTIC cmd.
+//
+IdeWritePortB (PciIo, IdeRegisters->Head, (UINT8)((IdeDevice << 4) 
+ | 0xe0));
+
+//
 // Send ATA Device Execut Diagnostic command.
 // This command should work no matter DRDY is ready or not
 //
@@ -2605,10 +2610,6 @@ DetectAndConfigIdeDevice (
 }
 
 //
-// Select Master or Slave device to get the return signature for ATA 
DEVICE DIAGNOSTIC cmd.
-//
-IdeWritePortB (PciIo, IdeRegisters->Head, (UINT8)((IdeDevice << 4) | 
0xe0));
-//
 // Stall for 1 milliseconds.
 //
 MicroSecondDelay (1000);
--
2.1.1



IdeMode.c.patch
Description: IdeMode.c.patch
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel