date:20140619

Re: [edk2] Building on OS X

2014-06-19 Thread egon

Hi Jeff,

After applying the patch the `lret` assembles fine, but I get the same error 
for the relocation:

Building ... /Users/x/code/ext/edk2/MdeModulePkg/Core/Dxe/DxeMain.inf [X64]
"ld" -arch x86_64 -u __ModuleEntryPoint -e __ModuleEntryPoint -preload 
-segalign 0x20 -pie -all_load -dead_strip -seg1addr 0x240 -map 
/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.map
 -read_only_relocs suppress -o 
/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
  -filelist 
/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/MdeModulePkg/Core/Dxe/DxeMain/OUTPUT/static_library_files.lst
ld: warning: -read_only_relocs cannot be used with x86_64
ld: illegal text-relocation to '_CommonInterruptEntry' in 
/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/DxeCpuExceptionHandlerLib.lib(ExceptionHandlerAsm.obj)
 from 'Exception0Handle' in 
/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/DxeCpuExceptionHandlerLib.lib(ExceptionHandlerAsm.obj)
 for architecture x86_64
make: *** 
[/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll]
 Error 1

Egon

On 20 Jun 2014, at 3:59 pm, Fan, Jeff  wrote:

> Hi Andrew,
> LRET should be used to pass more GCC compilers build.
> I also agree with using relative address instead of absolute address in 
> assembly code.
>  
> Hi, Egon
> Could you try this attached patch to check if it could pass your compiler 
> build?
>  
> Thanks!
> Jeff
> From: Andrew Fish [mailto:af...@apple.com] 
> Sent: Friday, June 20, 2014 6:50 AM
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] Building on OS X
>  
>  
> On Jun 19, 2014, at 2:51 PM, Andrew Fish  wrote:
> 
> 
>  
> On Jun 19, 2014, at 2:39 PM, Reza Jelveh  wrote:
> 
> 
> On 19/06/14 13:59, Andrew Fish wrote:
> 
> 
> On Jun 19, 2014, at 11:58 AM, e...@ragequ.it wrote:
> 
> 
> I changed the `retf` to a `ret` to get it to assemble for now.
> 
> 
> That looks right. I think it should be ret.
> i'm pretty certain this should be lret. Basically either the osx assembler
> should support retf(which I have a patch for, but probably won't happen ever)
> or it should use lret, which is exactly the same instruction.
> 
>  
> Well the code looked like this? So I assumed they did not mean iret
> .byte   0x48  # prefix to composite "retq" with next "retf"
> retf  # far return
> DoIret:
> iretq
>  
>  
> I think the code is trying to generate this.
>  
> 48 cb   rex.W retf
>  It looks like this is used for SMM. 
>  
> 
> 
>  
> 
> 
> 
> 
> Issue #2
> 
> Next issue is with the ACPI tables:
> 
> Issue #3
> Try changing your *_*_*_ASLDLINK_FLAGS in Conf/tools_def.txt to look like:  
> -e _ReferenceAcpiTable -preload -segalign 0x20  -pie -seg1addr 0x240 
> -read_only_relocs suppress -map $(DEST_DIR_DEBUG)/$(BASE_NAME).map
> the link_flags look fine, but it's like that you have a newer iasl therefore
> the cc and pp flags might need adjustment as well.
> 
> *_ASLCC_FLAGS  = -x c -save-temps -g -O0 -fshort-wchar 
> -fno-strict-aliasing -Wall -Werror -Wno-missing-braces -c -include AutoGen.h
> *_ASLPP_FLAGS  = -x c -E -P
> 
> 
> 
> 
> No. The library has non PC relative addressing in it and this is not 
> supported by the linker. When building the UefiCpuPkg.dsc this library is 
> built, but not linked so you don’t hit this error building the package. Just 
> linking the library. 
> 
> So things like:
> movabsq ASM_PFX(mDoFarReturnFlag), %ax
> 
> Need to be:
> movzblASM_PFX(mDoFarReturnFlag)(%rip), %eax
> 
> You need to convert any assembly code using absolute addresses to to relative 
> addressing.
> I gave up at this point. This is a major PITA. At this point my recommendation
> is to make a gcc 48 efi cross compiler. Andrew gave me some help for these
> too, but I don't think it's worth exploring.
> 
> Even if you manage to this to compile somehow the emulator will crash. At
> least it did for me.
> 
>  
> Sounds like a bug some place in the assembly. 
> 
> 
> Basically the osx linker does not support PIE(amongst other things).
> 
>  
> So why do we care? It supports a flavor of PIC, so PIE is just an 
> optimization, and clang is very good at optimization. For the 99% of the code 
> that is C it is a don’t care. 
>  
> The issue is the lack of relocation support, so folks keep writing 
> non-PIC/non-PIE assembly code that maps into PE/COFF relocations. This is 
> what causes the linker failures. 
> The clang assembler is also pickier about syntax. 
>  
> Thanks,
>  
> Andrew Fish
> 
> 
> You can build an efi cross compiler with the code available here:
> 
> https://github.com/STLVNUB/CloverGrower
> 
> personally I modified the script for easier and stripped down use. If you want
> I'

Re: [edk2] Building on OS X

2014-06-19 Thread egon

Hey guys,

Thanks for the tips.

On 20 Jun 2014, at 8:49 am, Andrew Fish  wrote:

> 
> On Jun 19, 2014, at 2:51 PM, Andrew Fish  wrote:
> 
>> 
>> On Jun 19, 2014, at 2:39 PM, Reza Jelveh  wrote:
>> 
>>> On 19/06/14 13:59, Andrew Fish wrote:
 
 On Jun 19, 2014, at 11:58 AM, e...@ragequ.it wrote:
 
> I changed the `retf` to a `ret` to get it to assemble for now.
> 
 
 That looks right. I think it should be ret.
>>> i'm pretty certain this should be lret. Basically either the osx assembler
>>> should support retf(which I have a patch for, but probably won't happen 
>>> ever)
>>> or it should use lret, which is exactly the same instruction.
>>> 
>> 
>> Well the code looked like this? So I assumed they did not mean iret
>> .byte   0x48  # prefix to composite "retq" with next "retf"
>> retf  # far return
>> DoIret:
>> iretq
>> 
> 
> I think the code is trying to generate this.
> 
> 48 cb   rex.W retf
>  It looks like this is used for SMM. 

So I ended up just changing the retf to ".byte 0xcb” since that’s what it’s 
expected to generate.

> 
> 
>> 
>> 
 
> Issue #2
> 
> Next issue is with the ACPI tables:
> 
> Issue #3
 Try changing your *_*_*_ASLDLINK_FLAGS in Conf/tools_def.txt to look like: 
  -e _ReferenceAcpiTable -preload -segalign 0x20  -pie -seg1addr 0x240 
 -read_only_relocs suppress -map $(DEST_DIR_DEBUG)/$(BASE_NAME).map
>>> the link_flags look fine, but it's like that you have a newer iasl therefore
>>> the cc and pp flags might need adjustment as well.
>>> 
>>> *_ASLCC_FLAGS  = -x c -save-temps -g -O0 -fshort-wchar 
>>> -fno-strict-aliasing -Wall -Werror -Wno-missing-braces -c -include AutoGen.h
>>> *_ASLPP_FLAGS  = -x c -E -P

Andrew suggested to add a new XCODE target, I’m actually using XCLANG but I 
tried the same thing - no dice.

Once I’d added all these flags suggested, I was able to compile the final 
intermediate file manually like this:

$ iasl 
/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/OvmfPkg/AcpiTables/AcpiTables/OUTPUT/./Ssdt.

Intel ACPI Component Architecture
ASL Optimizing Compiler version 20130823-64 [Jun 20 2014]
Copyright (c) 2000 - 2013 Intel Corporation

ASL Input: 
/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/OvmfPkg/AcpiTables/AcpiTables/OUTPUT/./Ssdt.
 - 4 lines, 69 bytes, 0 keywords
AML Output:
/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/OvmfPkg/AcpiTables/AcpiTables/OUTPUT/./Ssdt.aml
 - 36 bytes, 0 named objects, 0 executable opcodes

Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 0 Optimizations

Where previously this had errored out (so I thought I was Doing It Wrong), so 
for future reference it seems that the solution is to remove the output file 
from the `iasl` invocation. This:

"$(ASL)" $(ASL_FLAGS) $(ASL_OUTFLAGS)${dst} 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.

Changes to this:

"$(ASL)" $(ASL_FLAGS) $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.

> Try changing your *_*_*_ASLDLINK_FLAGS in Conf/tools_def.txt to look like:  
> -e _ReferenceAcpiTable -preload -segalign 0x20  -pie -seg1addr 0x240 
> -read_only_relocs suppress -map $(DEST_DIR_DEBUG)/$(BASE_NAME).map
> 
> So no -e _main

Yep, fixed.

Cheers,
Egon--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Is it just me or is tianocore.org completely missing the useful front page?

2014-06-19 Thread Jordan Justen

It seems like the sourceforge mediawiki service is not working right now.

It looks like it is affecting other projects too, including some of
sourceforge's own web pages.

-Jordan

On Thu, Jun 19, 2014 at 6:26 PM, Tim Lewis  wrote:
>
>
>
> --
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Building on OS X

2014-06-19 Thread Fan, Jeff

Hi Andrew,
LRET should be used to pass more GCC compilers build.
I also agree with using relative address instead of absolute address in 
assembly code.

Hi, Egon
Could you try this attached patch to check if it could pass your compiler build?

Thanks!
Jeff
From: Andrew Fish [mailto:af...@apple.com]
Sent: Friday, June 20, 2014 6:50 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Building on OS X


On Jun 19, 2014, at 2:51 PM, Andrew Fish 
mailto:af...@apple.com>> wrote:



On Jun 19, 2014, at 2:39 PM, Reza Jelveh 
mailto:reza.jel...@tuhh.de>> wrote:


On 19/06/14 13:59, Andrew Fish wrote:


On Jun 19, 2014, at 11:58 AM, e...@ragequ.it wrote:


I changed the `retf` to a `ret` to get it to assemble for now.

That looks right. I think it should be ret.
i'm pretty certain this should be lret. Basically either the osx assembler
should support retf(which I have a patch for, but probably won't happen ever)
or it should use lret, which is exactly the same instruction.

Well the code looked like this? So I assumed they did not mean iret

.byte   0x48  # prefix to composite "retq" with next "retf"

retf  # far return

DoIret:

iretq


I think the code is trying to generate this.

48 cb   rex.W retf
 It looks like this is used for SMM.








Issue #2

Next issue is with the ACPI tables:

Issue #3
Try changing your *_*_*_ASLDLINK_FLAGS in Conf/tools_def.txt to look like:  -e 
_ReferenceAcpiTable -preload -segalign 0x20  -pie -seg1addr 0x240 
-read_only_relocs suppress -map $(DEST_DIR_DEBUG)/$(BASE_NAME).map
the link_flags look fine, but it's like that you have a newer iasl therefore
the cc and pp flags might need adjustment as well.

*_ASLCC_FLAGS  = -x c -save-temps -g -O0 -fshort-wchar -fno-strict-aliasing 
-Wall -Werror -Wno-missing-braces -c -include AutoGen.h
*_ASLPP_FLAGS  = -x c -E -P




No. The library has non PC relative addressing in it and this is not supported 
by the linker. When building the UefiCpuPkg.dsc this library is built, but not 
linked so you don't hit this error building the package. Just linking the 
library.

So things like:
movabsq ASM_PFX(mDoFarReturnFlag), %ax

Need to be:
movzblASM_PFX(mDoFarReturnFlag)(%rip), %eax

You need to convert any assembly code using absolute addresses to to relative 
addressing.
I gave up at this point. This is a major PITA. At this point my recommendation
is to make a gcc 48 efi cross compiler. Andrew gave me some help for these
too, but I don't think it's worth exploring.

Even if you manage to this to compile somehow the emulator will crash. At
least it did for me.

Sounds like a bug some place in the assembly.


Basically the osx linker does not support PIE(amongst other things).

So why do we care? It supports a flavor of PIC, so PIE is just an optimization, 
and clang is very good at optimization. For the 99% of the code that is C it is 
a don't care.

The issue is the lack of relocation support, so folks keep writing 
non-PIC/non-PIE assembly code that maps into PE/COFF relocations. This is what 
causes the linker failures.
The clang assembler is also pickier about syntax.

Thanks,

Andrew Fish


You can build an efi cross compiler with the code available here:

https://github.com/STLVNUB/CloverGrower

personally I modified the script for easier and stripped down use. If you want
I'll up the fork when I have time, (which won't be until next thursday)

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel



ExceptionHandlerAsm.S.patch
Description: ExceptionHandlerAsm.S.patch
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] PcAtChipsetPkg: Enable timer interrupt through I/O APIC

2014-06-19 Thread Li, Elvin

Hi Tycho,
IoApicEnableInterrupt (mTimerIrq, TRUE) was wrongly removed at revision 
12778, which caused HPET timer could not work when PcdHpetMsiEnable is set to 
FALSE.

Thanks for finding this bug. I have verified the fix which worked well. 
I am going to check in the fix.

Reviewed-by: Elvin Li 

Thanks
Elvin
-Original Message-
From: Tycho Nightingale [mailto:tycho.nighting...@pluribusnetworks.com] 
Sent: Friday, June 20, 2014 4:13 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [PATCH] PcAtChipsetPkg: Enable timer interrupt through I/O APIC


Hi,

Please review the following patch which brings the code inline with the 
preceding comment and actually performs the enable of the HPET timer interrupt 
through the I/O APIC.

Thanks.

Tycho

PcAtChipsetPkg: Enable timer interrupt through I/O APIC

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Tycho Nightingale 

diff --git a/PcAtChipsetPkg/HpetTimerDxe/HpetTimer.c b/PcAtChipsetPkg/HpetTimerD
index b9bf080..142308c 100644
--- a/PcAtChipsetPkg/HpetTimerDxe/HpetTimer.c
+++ b/PcAtChipsetPkg/HpetTimerDxe/HpetTimer.c
@@ -594,6 +594,7 @@ TimerDriverSetTimerPeriod (
   // Program IOAPIC register with APIC ID of current BSP in case BSP has be
   //
   IoApicConfigureInterrupt (mTimerIrq, PcdGet8 (PcdHpetLocalApicVector), IO
+  IoApicEnableInterrupt (mTimerIrq, TRUE);
 }
 
 //

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] cannot load smm drivers symbol when enable source level debug through com port

2014-06-19 Thread owen

Dear all,

 

I enable source level debug through com port with UDK codebase, It can load
DXE and BDS drivers symbol, but cannot load SMM drivers symbol.

But it can report SMM drivers status code, and it can stop with
cpubreakpoint() under SMM drivers.

Does it need some special setting with  SMM drivers or debug agent?

 

 

Thanks,

Owen

 

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] Is it just me or is tianocore.org completely missing the useful front page?

2014-06-19 Thread Tim Lewis


--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Sync BaseTools Trunk (version r2669) to EDKII main trunk

2014-06-19 Thread Gao, Liming

Jordan:
 Now, we have a request to do this sync. We need to do it soon. So, I don't 
expect it depend on BaseTools merge. 

Thanks
Liming
-Original Message-
From: Jordan Justen [mailto:jljus...@gmail.com] 
Sent: Thursday, June 19, 2014 6:19 AM
To: Gao, Liming
Cc: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Sync BaseTools Trunk (version r2669) to EDKII main trunk

On Tue, Jun 17, 2014 at 8:08 PM, Gao, Liming  wrote:
> Hi, all
>
> I will sync BaseTool trunk (version r2669) into EDKII BaseTools. The 
> version used by EDK2 is 2649. The changes include:
>
> 1.   Fix GCC build rules for ASL sources that contain PCD.
> 2.   Enhanced VfrCompiler.
> 3.   Some fix in BaseTools.
>
>   BaseTool Trunk:
>   https://svn.code.sf.net/p/edk2-buildtools/code/trunk/BaseTools
>
>   EDKII BaseTools:
>   https://svn.code.sf.net/p/edk2/code/trunk/edk2/BaseTools
>
> If you have any comments, please let me know.

Do we plan to move the BaseTools binaries out of EDK II into the new 
edk2-toolbinaries repo at the same time as this sync?

If not, can we delay the sync until we are ready for that?

-Jordan

> Besides, Jordan proposes to merge those two BaseTools. After it is 
> done, such sync will not be required.
>
> Thanks
>
> Liming
>
>
> --
>  HPCC Systems Open Source Big Data Platform from LexisNexis 
> Risk Solutions Find What Matters Most in Your Big Data with HPCC 
> Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration 
> http://p.sf.net/sfu/hpccsystems 
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Building on OS X

2014-06-19 Thread Andrew Fish


On Jun 19, 2014, at 2:51 PM, Andrew Fish  wrote:

> 
> On Jun 19, 2014, at 2:39 PM, Reza Jelveh  wrote:
> 
>> On 19/06/14 13:59, Andrew Fish wrote:
>>> 
>>> On Jun 19, 2014, at 11:58 AM, e...@ragequ.it wrote:
>>> 
 I changed the `retf` to a `ret` to get it to assemble for now.
 
>>> 
>>> That looks right. I think it should be ret.
>> i'm pretty certain this should be lret. Basically either the osx assembler
>> should support retf(which I have a patch for, but probably won't happen ever)
>> or it should use lret, which is exactly the same instruction.
>> 
> 
> Well the code looked like this? So I assumed they did not mean iret
> .byte   0x48  # prefix to composite "retq" with next "retf"
> retf  # far return
> DoIret:
> iretq
> 

I think the code is trying to generate this.

48 cb   rex.W retf
 It looks like this is used for SMM. 


> 
> 
>>> 
 Issue #2
 
 Next issue is with the ACPI tables:
 
 Issue #3
>>> Try changing your *_*_*_ASLDLINK_FLAGS in Conf/tools_def.txt to look like:  
>>> -e _ReferenceAcpiTable -preload -segalign 0x20  -pie -seg1addr 0x240 
>>> -read_only_relocs suppress -map $(DEST_DIR_DEBUG)/$(BASE_NAME).map
>> the link_flags look fine, but it's like that you have a newer iasl therefore
>> the cc and pp flags might need adjustment as well.
>> 
>> *_ASLCC_FLAGS  = -x c -save-temps -g -O0 -fshort-wchar 
>> -fno-strict-aliasing -Wall -Werror -Wno-missing-braces -c -include AutoGen.h
>> *_ASLPP_FLAGS  = -x c -E -P
>> 
>> 
>> 
>>> No. The library has non PC relative addressing in it and this is not 
>>> supported by the linker. When building the UefiCpuPkg.dsc this library is 
>>> built, but not linked so you don’t hit this error building the package. 
>>> Just linking the library. 
>>> 
>>> So things like:
>>> movabsq ASM_PFX(mDoFarReturnFlag), %ax
>>> 
>>> Need to be:
>>> movzblASM_PFX(mDoFarReturnFlag)(%rip), %eax
>>> 
>>> You need to convert any assembly code using absolute addresses to to 
>>> relative addressing. 
>> I gave up at this point. This is a major PITA. At this point my 
>> recommendation
>> is to make a gcc 48 efi cross compiler. Andrew gave me some help for these
>> too, but I don't think it's worth exploring.
>> 
>> Even if you manage to this to compile somehow the emulator will crash. At
>> least it did for me.
>> 
> 
> Sounds like a bug some place in the assembly. 
> 
>> Basically the osx linker does not support PIE(amongst other things).
>> 
> 
> So why do we care? It supports a flavor of PIC, so PIE is just an 
> optimization, and clang is very good at optimization. For the 99% of the code 
> that is C it is a don’t care. 
> 
> The issue is the lack of relocation support, so folks keep writing 
> non-PIC/non-PIE assembly code that maps into PE/COFF relocations. This is 
> what causes the linker failures. 
> The clang assembler is also pickier about syntax. 
> 
> Thanks,
> 
> Andrew Fish
> 
>> You can build an efi cross compiler with the code available here:
>> 
>> https://github.com/STLVNUB/CloverGrower
>> 
>> personally I modified the script for easier and stripped down use. If you 
>> want
>> I'll up the fork when I have time, (which won't be until next thursday)
>> 
> 
> --
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Building on OS X

2014-06-19 Thread Andrew Fish

On Jun 19, 2014, at 3:06 PM, Reza Jelveh  wrote:

> On 19/06/14 14:51, Andrew Fish wrote:
>> Well the code looked like this? So I assumed they did not mean iret
>>.byte   0x48  # prefix to composite "retq" with next "retf"
>>retf  # far return
>> DoIret:
>>iretq
> 
> i'm not sure what you mean ... 
> 
> retf is lret isn't it? return far, long return
> 

IRET pops PC and  EFLAGS. So a Hardware Interrupt handler (exception handler) 
uses IRET, and the hardware has spilled the EFLAGS on the stack in addition to 
the PC  (it is more complicated that this due to extra stuff that also gets 
spilled, but that does not matter for IRET, just the interrupt handler). 

RETF pops PC and CS, which means it allows you to change segments (must have 
something to do with why it is needed in SMM?).

So they are not the same, and the code above generates different instructions. 

48 cb   rex.W retf
vs. 
48 cf   rex.W iret

> here's the binutils patch:
> 
> http://sourceware.org/ml/binutils/2008-08/msg00270.html
> 
> and here's the apple cctools patch:
> 
> https://github.com/fishman/timebomb-gentoo-osx-overlay/blob/master/sys-devel/binutils-apple/files/cctools-839-intel-retf.patch
> 

This example is about LRET and RETF, not IRET? So it seems to be about 
assembler name aliases, not processor instructions? 
For example iretq is really assembler shorthand for:
48 cf   rex.W iret
So for the processor it is a prefix instruction and the old IRET instruction, 
the assembler is making up a short hand to hide the prefix byte. 

>> 
>> So why do we care? It supports a flavor of PIC, so PIE is just an 
>> optimization, and clang is very good at optimization. For the 99% of the 
>> code that is C it is a don’t care. 
>> 
>> The issue is the lack of relocation support, so folks keep writing 
>> non-PIC/non-PIE assembly code that maps into PE/COFF relocations. This is 
>> what causes the linker failures. 
>> The clang assembler is also pickier about syntax. 
> 
> sorry, i don't mean to be bitching, but after fiddling with it for a while i
> decided to go for the pragmatic route. considering this efi stuff is like a
> "DOS in the bios", I'm actually surprised efi crosscompilers are so badly
> documented.
> 

Building compilers != building firmware, but contributions are always welcome. 

We tried hard to avoid unneeded assembler in edk2, but things like exception 
handlers need to be written in assembler. 
I think AsmGetTemplateAddressMap and AsmVectorNumFixup could have probably been 
written in C, but the CommonInterruptEntry has to be written in assembly.

Thanks,

Andrew Fish

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Building on OS X

2014-06-19 Thread Reza Jelveh

On 19/06/14 14:51, Andrew Fish wrote:
> Well the code looked like this? So I assumed they did not mean iret
> .byte   0x48  # prefix to composite "retq" with next "retf"
> retf  # far return
> DoIret:
> iretq

i'm not sure what you mean ... 

retf is lret isn't it? return far, long return

here's the binutils patch:

http://sourceware.org/ml/binutils/2008-08/msg00270.html

and here's the apple cctools patch:

https://github.com/fishman/timebomb-gentoo-osx-overlay/blob/master/sys-devel/binutils-apple/files/cctools-839-intel-retf.patch

> 
> So why do we care? It supports a flavor of PIC, so PIE is just an 
> optimization, and clang is very good at optimization. For the 99% of the code 
> that is C it is a don’t care. 
> 
> The issue is the lack of relocation support, so folks keep writing 
> non-PIC/non-PIE assembly code that maps into PE/COFF relocations. This is 
> what causes the linker failures. 
> The clang assembler is also pickier about syntax. 

sorry, i don't mean to be bitching, but after fiddling with it for a while i
decided to go for the pragmatic route. considering this efi stuff is like a
"DOS in the bios", I'm actually surprised efi crosscompilers are so badly
documented.

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Building on OS X

2014-06-19 Thread Andrew Fish


On Jun 19, 2014, at 2:39 PM, Reza Jelveh  wrote:

> On 19/06/14 13:59, Andrew Fish wrote:
>> 
>> On Jun 19, 2014, at 11:58 AM, e...@ragequ.it wrote:
>> 
>>> I changed the `retf` to a `ret` to get it to assemble for now.
>>> 
>> 
>> That looks right. I think it should be ret.
> i'm pretty certain this should be lret. Basically either the osx assembler
> should support retf(which I have a patch for, but probably won't happen ever)
> or it should use lret, which is exactly the same instruction.
> 

Well the code looked like this? So I assumed they did not mean iret
.byte   0x48  # prefix to composite "retq" with next "retf"
retf  # far return
DoIret:
iretq



>> 
>>> Issue #2
>>> 
>>> Next issue is with the ACPI tables:
>>> 
>>> Issue #3
>> Try changing your *_*_*_ASLDLINK_FLAGS in Conf/tools_def.txt to look like:  
>> -e _ReferenceAcpiTable -preload -segalign 0x20  -pie -seg1addr 0x240 
>> -read_only_relocs suppress -map $(DEST_DIR_DEBUG)/$(BASE_NAME).map
> the link_flags look fine, but it's like that you have a newer iasl therefore
> the cc and pp flags might need adjustment as well.
> 
> *_ASLCC_FLAGS  = -x c -save-temps -g -O0 -fshort-wchar 
> -fno-strict-aliasing -Wall -Werror -Wno-missing-braces -c -include AutoGen.h
> *_ASLPP_FLAGS  = -x c -E -P
> 
> 
> 
>> No. The library has non PC relative addressing in it and this is not 
>> supported by the linker. When building the UefiCpuPkg.dsc this library is 
>> built, but not linked so you don’t hit this error building the package. Just 
>> linking the library. 
>> 
>> So things like:
>> movabsq ASM_PFX(mDoFarReturnFlag), %ax
>> 
>> Need to be:
>> movzblASM_PFX(mDoFarReturnFlag)(%rip), %eax
>> 
>> You need to convert any assembly code using absolute addresses to to 
>> relative addressing. 
> I gave up at this point. This is a major PITA. At this point my recommendation
> is to make a gcc 48 efi cross compiler. Andrew gave me some help for these
> too, but I don't think it's worth exploring.
> 
> Even if you manage to this to compile somehow the emulator will crash. At
> least it did for me.
> 

Sounds like a bug some place in the assembly. 

> Basically the osx linker does not support PIE(amongst other things).
> 

So why do we care? It supports a flavor of PIC, so PIE is just an optimization, 
and clang is very good at optimization. For the 99% of the code that is C it is 
a don’t care. 

The issue is the lack of relocation support, so folks keep writing 
non-PIC/non-PIE assembly code that maps into PE/COFF relocations. This is what 
causes the linker failures. 
The clang assembler is also pickier about syntax. 

Thanks,

Andrew Fish

> You can build an efi cross compiler with the code available here:
> 
> https://github.com/STLVNUB/CloverGrower
> 
> personally I modified the script for easier and stripped down use. If you want
> I'll up the fork when I have time, (which won't be until next thursday)
> 

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Building on OS X

2014-06-19 Thread Reza Jelveh

On 19/06/14 13:59, Andrew Fish wrote:
> 
> On Jun 19, 2014, at 11:58 AM, e...@ragequ.it wrote:
> 
> > I changed the `retf` to a `ret` to get it to assemble for now.
> > 
> 
> That looks right. I think it should be ret.
i'm pretty certain this should be lret. Basically either the osx assembler
should support retf(which I have a patch for, but probably won't happen ever)
or it should use lret, which is exactly the same instruction.

> 
> > Issue #2
> > 
> > Next issue is with the ACPI tables:
> > 
> > Issue #3
> Try changing your *_*_*_ASLDLINK_FLAGS in Conf/tools_def.txt to look like:  
> -e _ReferenceAcpiTable -preload -segalign 0x20  -pie -seg1addr 0x240 
> -read_only_relocs suppress -map $(DEST_DIR_DEBUG)/$(BASE_NAME).map
the link_flags look fine, but it's like that you have a newer iasl therefore
the cc and pp flags might need adjustment as well.

*_ASLCC_FLAGS  = -x c -save-temps -g -O0 -fshort-wchar -fno-strict-aliasing 
-Wall -Werror -Wno-missing-braces -c -include AutoGen.h
*_ASLPP_FLAGS  = -x c -E -P



> No. The library has non PC relative addressing in it and this is not 
> supported by the linker. When building the UefiCpuPkg.dsc this library is 
> built, but not linked so you don’t hit this error building the package. Just 
> linking the library. 
> 
> So things like:
> movabsq ASM_PFX(mDoFarReturnFlag), %ax
> 
> Need to be:
> movzblASM_PFX(mDoFarReturnFlag)(%rip), %eax
> 
> You need to convert any assembly code using absolute addresses to to relative 
> addressing. 
I gave up at this point. This is a major PITA. At this point my recommendation
is to make a gcc 48 efi cross compiler. Andrew gave me some help for these
too, but I don't think it's worth exploring.

Even if you manage to this to compile somehow the emulator will crash. At
least it did for me.

Basically the osx linker does not support PIE(amongst other things).

You can build an efi cross compiler with the code available here:

https://github.com/STLVNUB/CloverGrower

personally I modified the script for easier and stripped down use. If you want
I'll up the fork when I have time, (which won't be until next thursday)


--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH] PcAtChipsetPkg: Enable timer interrupt through I/O APIC

2014-06-19 Thread Tycho Nightingale


Hi,

Please review the following patch which brings the code inline with the 
preceding comment and actually performs the enable of the HPET timer interrupt 
through the I/O APIC.

Thanks.

Tycho

PcAtChipsetPkg: Enable timer interrupt through I/O APIC

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Tycho Nightingale 

diff --git a/PcAtChipsetPkg/HpetTimerDxe/HpetTimer.c b/PcAtChipsetPkg/HpetTimerD
index b9bf080..142308c 100644
--- a/PcAtChipsetPkg/HpetTimerDxe/HpetTimer.c
+++ b/PcAtChipsetPkg/HpetTimerDxe/HpetTimer.c
@@ -594,6 +594,7 @@ TimerDriverSetTimerPeriod (
   // Program IOAPIC register with APIC ID of current BSP in case BSP has be
   //
   IoApicConfigureInterrupt (mTimerIrq, PcdGet8 (PcdHpetLocalApicVector), IO
+  IoApicEnableInterrupt (mTimerIrq, TRUE);
 }
 
 //

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Building on OS X

2014-06-19 Thread Andrew Fish


On Jun 19, 2014, at 11:58 AM, e...@ragequ.it wrote:

> Hey guys,
> 
> I’m having some issues building OVMF on OS X 10.9 with the latest dev tools. 
> I’m running Xcode 5.1.1, with the “Late June” Command Line Tools.
> 
> $ clang --version
> Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
> Target: x86_64-apple-darwin13.0.0
> Thread model: posix
> 
> Issue #1
> 
> $ build -p OvmfPkg/OvmfPkgX64.dsc
> 
> Building ... 
> /Users/x/code/ext/edk2/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
>  [X64]
> "clang" -E -x assembler-with-cpp -include 
> /Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/DEBUG/AutoGen.h
>  -I/Users/x/code/ext/edk2/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64 
> -I/Users/x/code/ext/edk2/UefiCpuPkg/Library/CpuExceptionHandlerLib 
> -I/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/DEBUG
>  -I/Users/x/code/ext/edk2/MdePkg -I/Users/x/code/ext/edk2/MdePkg/Include 
> -I/Users/x/code/ext/edk2/MdePkg/Include/X64 
> -I/Users/x/code/ext/edk2/MdeModulePkg 
> -I/Users/x/code/ext/edk2/MdeModulePkg/Include 
> -I/Users/x/code/ext/edk2/UefiCpuPkg 
> -I/Users/x/code/ext/edk2/UefiCpuPkg/Include 
> /Users/x/code/ext/edk2/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.S
>  > 
> /Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.i
> Trim --trim-long --source-code -o 
> /Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii
>  
> /Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.i
> "as" -arch x86_64 -g -o 
> /Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.obj
>  -I/Users/x/code/ext/edk2/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64 
> -I/Users/x/code/ext/edk2/UefiCpuPkg/Library/CpuExceptionHandlerLib 
> -I/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/DEBUG
>  -I/Users/x/code/ext/edk2/MdePkg -I/Users/x/code/ext/edk2/MdePkg/Include 
> -I/Users/x/code/ext/edk2/MdePkg/Include/X64 
> -I/Users/x/code/ext/edk2/MdeModulePkg 
> -I/Users/x/code/ext/edk2/MdeModulePkg/Include 
> -I/Users/x/code/ext/edk2/UefiCpuPkg 
> -I/Users/x/code/ext/edk2/UefiCpuPkg/Include 
> /Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii
> /Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:569:no
>  such instruction: `retf'
> make: *** 
> [/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.obj]
>  Error 1
> 
> This is the code in question:
> 
> DoReturn:
> pushq   %rax
> movabsq ASM_PFX(mDoFarReturnFlag), %rax
> cmpq$0, %rax  # Check if need to do far return instead of IRET
> popq%rax
> jz  DoIret
> pushq   %rax
> movq%rsp, %rax# save old RSP to rax
> movq0x20(%rsp), %rsp
> pushq   0x10(%rax)# save CS in new location
> pushq   0x8(%rax) # save EIP in new location
> pushq   0x18(%rax)# save EFLAGS in new location
> movq(%rax), %rax  # restore rax
> popfq # restore EFLAGS
> .byte   0x48  # prefix to composite "retq" with next "retf"
> retf  # far return
> 
> I changed the `retf` to a `ret` to get it to assemble for now.
> 

That looks right. I think it should be ret.

> Issue #2
> 
> Next issue is with the ACPI tables:
> 
> Building ... /Users/x/code/ext/edk2/OvmfPkg/AcpiTables/AcpiTables.inf [X64]
> Trim --asl-file -o 
> /Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/OvmfPkg/AcpiTables/AcpiTables/OUTPUT/./Ssdt.i
>  -i 
> /Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/OvmfPkg/AcpiTables/AcpiTables/OUTPUT/inc.lst
>  /Users/x/code/ext/edk2/OvmfPkg/AcpiTables/Ssdt.asl
> "clang" -x c -E -I/Users/x/code/ext/edk2/OvmfPkg/AcpiTables 
> -I/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/OvmfPkg/AcpiTables/AcpiTables/DEBUG
>  -I/Users/x/code/ext/edk2/MdePkg -I/Users/x/code/ext/edk2/MdePkg/Include 
> -I/Users/x/code/ext/edk2/MdePkg/Include/X64 
> -I/Users/x/code/ext/edk2/OvmfPkg/AcpiTables 
> /Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/OvmfPkg/AcpiTables/AcpiTables/OUTPUT/./Ssdt.i
>  > 
> /Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/OvmfPkg/AcpiTables/A

[edk2] Building on OS X

2014-06-19 Thread egon

Hey guys,

I’m having some issues building OVMF on OS X 10.9 with the latest dev tools. 
I’m running Xcode 5.1.1, with the “Late June” Command Line Tools.

$ clang --version
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix

Issue #1

$ build -p OvmfPkg/OvmfPkgX64.dsc

Building ... 
/Users/x/code/ext/edk2/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
 [X64]
"clang" -E -x assembler-with-cpp -include 
/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/DEBUG/AutoGen.h
 -I/Users/x/code/ext/edk2/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64 
-I/Users/x/code/ext/edk2/UefiCpuPkg/Library/CpuExceptionHandlerLib 
-I/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/DEBUG
 -I/Users/x/code/ext/edk2/MdePkg -I/Users/x/code/ext/edk2/MdePkg/Include 
-I/Users/x/code/ext/edk2/MdePkg/Include/X64 
-I/Users/x/code/ext/edk2/MdeModulePkg 
-I/Users/x/code/ext/edk2/MdeModulePkg/Include 
-I/Users/x/code/ext/edk2/UefiCpuPkg -I/Users/x/code/ext/edk2/UefiCpuPkg/Include 
/Users/x/code/ext/edk2/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.S
 > 
/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.i
Trim --trim-long --source-code -o 
/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii
 
/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.i
"as" -arch x86_64 -g -o 
/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.obj
 -I/Users/x/code/ext/edk2/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64 
-I/Users/x/code/ext/edk2/UefiCpuPkg/Library/CpuExceptionHandlerLib 
-I/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/DEBUG
 -I/Users/x/code/ext/edk2/MdePkg -I/Users/x/code/ext/edk2/MdePkg/Include 
-I/Users/x/code/ext/edk2/MdePkg/Include/X64 
-I/Users/x/code/ext/edk2/MdeModulePkg 
-I/Users/x/code/ext/edk2/MdeModulePkg/Include 
-I/Users/x/code/ext/edk2/UefiCpuPkg -I/Users/x/code/ext/edk2/UefiCpuPkg/Include 
/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii
/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:569:no
 such instruction: `retf'
make: *** 
[/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.obj]
 Error 1

This is the code in question:

DoReturn:
pushq   %rax
movabsq ASM_PFX(mDoFarReturnFlag), %rax
cmpq$0, %rax  # Check if need to do far return instead of IRET
popq%rax
jz  DoIret
pushq   %rax
movq%rsp, %rax# save old RSP to rax
movq0x20(%rsp), %rsp
pushq   0x10(%rax)# save CS in new location
pushq   0x8(%rax) # save EIP in new location
pushq   0x18(%rax)# save EFLAGS in new location
movq(%rax), %rax  # restore rax
popfq # restore EFLAGS
.byte   0x48  # prefix to composite "retq" with next "retf"
retf  # far return

I changed the `retf` to a `ret` to get it to assemble for now.

Issue #2

Next issue is with the ACPI tables:

Building ... /Users/x/code/ext/edk2/OvmfPkg/AcpiTables/AcpiTables.inf [X64]
Trim --asl-file -o 
/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/OvmfPkg/AcpiTables/AcpiTables/OUTPUT/./Ssdt.i
 -i 
/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/OvmfPkg/AcpiTables/AcpiTables/OUTPUT/inc.lst
 /Users/x/code/ext/edk2/OvmfPkg/AcpiTables/Ssdt.asl
"clang" -x c -E -I/Users/x/code/ext/edk2/OvmfPkg/AcpiTables 
-I/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/OvmfPkg/AcpiTables/AcpiTables/DEBUG
 -I/Users/x/code/ext/edk2/MdePkg -I/Users/x/code/ext/edk2/MdePkg/Include 
-I/Users/x/code/ext/edk2/MdePkg/Include/X64 
-I/Users/x/code/ext/edk2/OvmfPkg/AcpiTables 
/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/OvmfPkg/AcpiTables/AcpiTables/OUTPUT/./Ssdt.i
 > 
/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/OvmfPkg/AcpiTables/AcpiTables/OUTPUT/./Ssdt.iii
"iasl"  
/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/OvmfPkg/AcpiTables/AcpiTables/OUTPUT/./Ssdt.aml
 
/Users/x/code/ext/edk2/Build/OvmfX64/DEBUG_XCLANG/X64/OvmfPkg/AcpiTables/AcpiTables/OUTPUT/./Ssdt.iii
Error6092 - Could not open file 
"/User

Re: [edk2] Sync BaseTools Trunk (version r2669) to EDKII main trunk

2014-06-19 Thread Gao, Liming

Laszlo:
  Yes. This patch fixes it. To let it work, you also need to configure 
GCC:*_*_*_ASLPP_FLAGS to include AutoGen.h in Platform DSC file. 

  The default GCC ASLPP Flags in tools_def.txt is the below, which has no 
'-include AutoGen.h'. But, PCD definition is generated in AutoGen.h.
  DEFINE GCC_ASLPP_FLAGS = -x c -E -P

  Another solution is to change GCC_ASLPP_FLAGS definition in tools_def.txt. It 
will impact every platform. To minimize its impact, this patch only updates 
build_rule.txt. 

Thanks
Liming
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Wednesday, June 18, 2014 9:41 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Sync BaseTools Trunk (version r2669) to EDKII main trunk

On 06/18/14 05:08, Gao, Liming wrote:
> Hi, all
> 
> I will sync BaseTool trunk (version r2669) into EDKII BaseTools. The 
> version used by EDK2 is 2649. The changes include:
> 
> 1.   Fix GCC build rules for ASL sources that contain PCD.

What does this cover in more detail?

For example, in "OvmfPkg/AcpiTables/Dsdt.asl", we have

IO (Decode16, 0x402, 0x402, 0x00, 0x01)// QEMU debug 
console, should use FixedPcdGet16 (PcdDebugIoPort)

Does the change mean that we can replace 0x402 with FixedPcdGet16 
(PcdDebugIoPort)?

> 
> 2.   Enhanced VfrCompiler.
> 
> 3.   Some fix in BaseTools.
> 
>  
> 
>   BaseTool Trunk:
> 
>   https://svn.code.sf.net/p/edk2-buildtools/code/trunk/BaseTools
> 
>   EDKII BaseTools:
> 
>   https://svn.code.sf.net/p/edk2/code/trunk/edk2/BaseTools
> 
>  
> 
> If you have any comments, please let me know.
> 
>  
> 
> Besides, Jordan proposes to merge those two BaseTools. After it is 
> done, such sync will not be required.

Probably a good idea.

Thanks,
Laszlo


--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find 
What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. 
Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration 
http://p.sf.net/sfu/hpccsystems ___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Building on OS X

Re: [edk2] Building on OS X

Re: [edk2] Is it just me or is tianocore.org completely missing the useful front page?

Re: [edk2] Building on OS X

Re: [edk2] [PATCH] PcAtChipsetPkg: Enable timer interrupt through I/O APIC

[edk2] cannot load smm drivers symbol when enable source level debug through com port

[edk2] Is it just me or is tianocore.org completely missing the useful front page?

Re: [edk2] Sync BaseTools Trunk (version r2669) to EDKII main trunk

Re: [edk2] Building on OS X

Re: [edk2] Building on OS X

Re: [edk2] Building on OS X

Re: [edk2] Building on OS X

Re: [edk2] Building on OS X

[edk2] [PATCH] PcAtChipsetPkg: Enable timer interrupt through I/O APIC

Re: [edk2] Building on OS X

[edk2] Building on OS X

Re: [edk2] Sync BaseTools Trunk (version r2669) to EDKII main trunk

17 matches

Site Navigation

Mail list logo

Footer information