Re: [edk2] Compiling EDK1 driver in EDK2
Thank you Olivier and Andrew, I am able to compile and testing is in progress. On Tue, Nov 26, 2013 at 4:09 PM, Olivier Martin olivier.mar...@arm.comwrote: The exercise of porting Undi EDK Intel(R) PRO/1000 Network Driver to ARM EDK2 was looking interesting. I had a quick try to get an idea of the effort. What I did: 1) Unpacked the archive under ArmPlatformPkg\Drivers\GigUndi 2) Create ArmPlatformPkg\Drivers\GigUndi\GigUndi.inf (see attachment) 3) Add ArmPlatformPkg\Drivers\GigUndi\GigUndi.inf to ArmPlatformPkg\ArmPlatformPkg.dsc 4) Try to build 5) Fix the build by: a. Commenting the old #include b. Adding the EDK2 #include instead c. Others... 6) Go back to step 4) until I had a link error 7) Add the missing libraries I stopped at the step 6 after few iterations. At some point I had to add Base.h and I was not able to duplicate your error. My suggestions are: - Clean your build and retry to make sure there is no old files - Start again your porting process following my steps *From:* Shivamurthy Shastri [mailto:shiva.linuxwo...@gmail.comshiva.linuxwo...@gmail.com] *Sent:* 20 November 2013 10:14 *To:* Andrew Fish *Cc:* edk2-devel@lists.sourceforge.net *Subject:* Re: [edk2] Compiling EDK1 driver in EDK2 Hi Andrew, On Tue, Nov 19, 2013 at 8:23 PM, Andrew Fish af...@apple.com wrote: On Nov 19, 2013, at 6:15 AM, Shivamurthy Shastri shiva.linuxwo...@gmail.com wrote: Hi, I downloaded UEFI network driver for Intel PCIE card from http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=EDK file is gig_pcie_src_4109.zip I tried to compile this for ARM platform. It appears that this code only compile with EDK1. I tried to compile this with EDK2 by changing INF file (gig_82575_edk1.inf). But, I got many compilation issues. This project is an example of compiling the old EDK Shell, with GCC for ARM. http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Gcc-shell This project is obsolete, since the EDK II shell supports ARM, and GCC now, but it is an example for you to look at. Thank you for sharing this example. I tried in same way but, my problem is not solved. INF file I have changed is as follows: You need to Modify the .DSC file to support the compatibility package, not the INF file. If you modify the INF file you need to port the driver to EDKII. I modified DSC file to support compatibility package. My DSC file is now looks like below: [Defines] ... [LibraryClasses.common] It has other ARM and platform related libraries. [Libraries] # # Libraries common to PEI and DXE # EdkCompatibilityPkg/Foundation/Efi/Guid/EfiGuidLib.inf EdkCompatibilityPkg/Foundation/Framework/Guid/EdkFrameworkGuidLib.inf EdkCompatibilityPkg/Foundation/Guid/EdkGuidLib.inf EdkCompatibilityPkg/Foundation/Library/EfiCommonLib/EfiCommonLib_Edk2.inf EdkCompatibilityPkg/Foundation/Library/CustomizedDecompress/CustomizedDecompress.inf EdkCompatibilityPkg/Foundation/Library/Dxe/Hob/HobLib.inf # # PEI libraries # EdkCompatibilityPkg/Foundation/Framework/Ppi/EdkFrameworkPpiLib.inf EdkCompatibilityPkg/Foundation/Ppi/EdkPpiLib.inf EdkCompatibilityPkg/Foundation/Library/Pei/PeiLib/PeiLib.inf EdkCompatibilityPkg/Foundation/Library/Pei/Hob/PeiHobLib.inf # # DXE libraries # EdkCompatibilityPkg/Foundation/Core/Dxe/ArchProtocol/ArchProtocolLib.inf EdkCompatibilityPkg/Foundation/Efi/Protocol/EfiProtocolLib.inf EdkCompatibilityPkg/Foundation/Framework/Protocol/EdkFrameworkProtocolLib.inf EdkCompatibilityPkg/Foundation/Protocol/EdkProtocolLib.inf EdkCompatibilityPkg/Foundation/Library/Dxe/EfiDriverLib/EfiDriverLib.inf EdkCompatibilityPkg/Foundation/Library/RuntimeDxe/EfiRuntimeLib/EfiRuntimeLib.inf EdkCompatibilityPkg/Foundation/Library/Dxe/Graphics/Graphics.inf EdkCompatibilityPkg/Foundation/Library/Dxe/EfiIfrSupportLib/EfiIfrSupportLib.inf EdkCompatibilityPkg/Foundation/Library/Dxe/UefiEfiIfrSupportLib/UefiEfiIfrSupportLib.inf EdkCompatibilityPkg/Foundation/Library/Dxe/Print/PrintLib.inf EdkCompatibilityPkg/Foundation/Library/Dxe/EfiScriptLib/EfiScriptLib.inf EdkCompatibilityPkg/Foundation/Library/Dxe/EfiUiLib/EfiUiLib.inf # # Print/Graphics Library consume SetupBrowser Print Protocol # EdkCompatibilityPkg/Foundation/Library/Dxe/PrintLite/PrintLib.inf EdkCompatibilityPkg/Foundation/Library/Dxe/GraphicsLite/Graphics.inf [LibraryClasses.ARM] NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf [BuildOptions] GCC:*_*_ARM_ARCHCC_FLAGS== -march=armv7-a -mno-unaligned-access -mthumb -mthumb-interwork -fno-stack-protector -I$(PLATFORM_SOURCE)/Include -DEFIARM -DEFI_SPECIFICATION_VERSION=0x0002 GCC:*_*_ARM_ARCHASM_FLAGS == -march=armv7-a
Re: [edk2] [Xen-devel] [PATCH v4 0/7] Make OVMF fully working with Xen
On Sat, Nov 30, 2013 at 03:58:18PM -0800, Jordan Justen wrote: Series Reviewed-by: Jordan Justen jordan.l.jus...@intel.com Some minor issues mentioned in a reply to patch 1. Hi Jordan Is there any more concerns regarding this series? All patches have reviewed-by tag now. I was quite clear about Ray's question. Anything else I need to do to get this series merged? Wei. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] Issue in UNDI driver for INTEL GIGABIT CT DESKTOP ADAPTER
You should probably try to build for X64 (and EDK2) and see if the driver works to make sure you have not broken anything in your port. From: Shivamurthy Shastri [mailto:shiva.linuxwo...@gmail.com] Sent: 05 December 2013 13:37 To: edk2-devel@lists.sourceforge.net Subject: [edk2] Issue in UNDI driver for INTEL GIGABIT CT DESKTOP ADAPTER Hi, I have downloaded UNDI driver for Intel PCIE card from the link http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=EDK file is gig_pcie_src_4109.zip. I compiled this for ARM platform and EDK2. My board is Intel Gigabit CT Desktop Adapter, which has 8082574L ethernet controller. Any build flag do I need to enable? Because, ethernet controller PHY init is failing. -- Thanks and Regards, Shiva. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] ARM UEFI BIOS Trusted firmware
Changing topic.. Hi Oliver, Thanks. I also I have few separate questions wrt to Trusted firmware UEFI ARM code and hope you/others can help answer * It seems there are two direction for SecureMonitor implementation. In one implementation the SEC code (ArmPlatformPkg\Sec\Sec.c) install the secure monitor ( when SEC start in El3) ; In other implementation the Trusted firmware start first install secure monitor (bl31) and launch SEC in El1/2 mode. My question is what is the preferred direction when both are possible? Should secure monitor (bl31) be launched before or during SEC phase? * Historically in x86 implementation the SMM mode hosts various runtime platform BIOS driver for feature such as authentication variable (for secure boot), platform runtime handing handling etc. EDKII has a good framework for SMM kernel and loading various independent SMM driver and interaction among those driver via protocol etc. In ARM based UEFI/Trusted firmware implementation what may be preferred way to deal with such need. Should all those UEFI SMM driver be ported to Trusted firmware which today is in primitive framework compare to SMM EDKII foundation code, or some form of SMM foundation can gel with trusted firmware design to allow independent platform el3 code be developed at independent driver. Curious how others have attempted to solve this problem and if there can be standard way for all of us to adopt here. Before creating yet another method I was hoping to hear from experts on any common ground for such feature implementation Thanks again for all your help and comments -Alok -Original Message- From: Olivier Martin [mailto:olivier.mar...@arm.com] Sent: Wednesday, December 04, 2013 7:40 AM To: tiger...@viatech.com.cn; edk2-devel@lists.sourceforge.net Subject: Re: [edk2] SEC code support big.LITTLE tech? Hi Tiger, The ARM recommendation to manage secondary CPUs (the primary CPU is the CPU that runs UEFI and starts your OS kernel) is to use PSCI (Power State Coordination Interface - http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0022b/index.h tml). PSCI uses SMCs (Secure Memory Calls) to bring up secondary CPUs (CPU_UP / CPU_DOWN). This code runs in Secure World while UEFI runs in Non-Secure World. For the story... I started to implement PSCI support in Tianocore source code (in ArmPlatformPkg/Sec). But the EDK2 framework (PCD/Library/INF/FDF etc) had made the code quite hard to maintain. So, I wrote a new secure firmware framework project to handle this support. This firmware is not Open Source (available in binary format for TC2 only). A new project has been started by ARM Ltd last month. It is an Open Source implementation of the Trusted/Secure Firmware: https://github.com/ARM-software/arm-trusted-firmware Unfortunately at this stage, 32bit is not supported (only AArch64 is supported). And as far as I know there is no plan to add 32bit support by ARM Ltd in the short term. The current ArmPlatformPkg/Sec has support to hold the secondary cores in WFI. But it does not support PSCI. The current support might be sufficient enough for you at this stage. Thanks, Olivier -Original Message- From: tiger...@viatech.com.cnmailto:tiger...@viatech.com.cn [mailto:tiger...@viatech.com.cn] Sent: 04 December 2013 01:51 To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net Cc: Olivier Martin Subject: [edk2] SEC code support big.LITTLE tech? Hi, Oliver: Does current ArmPlatformPackage's sec code support big.LITTLE tech? Such as : An ARM SOC --- with 4 Cores Cortex-A15, 4 Cores Cortex-A7 So, if sec code support big.LITTLE tech, how does it let one core as boot strap cpu, others go into wfe(or other sleeping state)? Best wishes, -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ edk2-devel mailing list edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] apparent KVM problem with LRET in TianoCore S3 resume trampoline
Hi, I'm working on S3 suspend/resume in OVMF. The problem is that I'm getting an unexpected guest reboot for code (LRET) that works on physical hardware. I tried to trace the problem with ftrace, but I didn't get any mentions of em_ret_far(). (Maybe I was looking in the wrong place.) Please find the the assembly-language trampoline that is invoked (in 64-bit mode) with the 16-bit real mode resume vector placed in rcx (EFIAPI calling convention). The excerpt is from the edk2 tree, MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S. I'm annotating the source code to the right -- please excuse my audacity as I know you all eat assembly for breakfast, but maybe it will speed up your processing. (Or perhaps I'll sneakily confuse you with my errors :)) ASM_GLOBAL ASM_PFX(AsmTransferControl) # ASM_PFX(AsmTransferControl): # # rcx S3WakingVector:DWORD # ecx: # rdx AcpiLowMemoryBase :DWORD # lea _AsmTransferControl_al_(%rip), %eax # pushing $0x28 for CS movq $0x28, %r8 # and address of orq %r8, %rax# _AsmTransferControl_al_ pushq %rax # for RIP shrd $20, %ecx, %ebx # ebx: andl $0x0f, %ecx # ecx: movw %cx, %bx # ebx: movl %ebx, jmp_addr(%rip) # stores vector as 16-bit segment:offset pair : # -- my own loop jmp # -- for debugging lret # (*) TRIGGERS REBOOT _AsmTransferControl_al_: # .byte0x0b8, 0x30, 0 # mov ax, 30h as selector # movl %eax, %ds# movl %eax, %es# movl %eax, %fs# movl %eax, %gs# movl %eax, %ss# movq %cr0, %rax # movq %cr4, %rbx # .byte0x66 # (**) andl $0x7ffe, %eax# preps for turning off Paging and Protection Enable andb $0xdf, %bl # preps for turning off PAE movq %rax, %cr0 # Paging and PE off .byte0x66 # (**) movl $0x0c080, %ecx # rdmsr # andb $0xfe, %ah # wrmsr # IA-32e Mode Enable off movq %rbx, %cr4 # PAE off .byte0x0ea # jmp far jmp_addr # jmp_addr: # .long0 # : The small loop at is my debug loop. The lret instruction right after (marked with (*)) triggers a reboot in KVM. In the loop, this is the register dump (taken with the info registers qemu monitor command): RAX=00289c75be2b RBX=9a1d RCX= RDX= RSI= RDI= RBP=9f7bafd0 RSP=9f7bae30 R8 =0028 R9 = R10=008454cd R11= R12= R13= R14=008454c6 R15= RIP=9c75be28 RFL=0046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0018 00c09300 DPL=0 DS [-WA] CS =0018 00a09b00 DPL=0 CS64 [-RA] SS =0018 00c09300 DPL=0 DS [-WA] DS =0018 00c09300 DPL=0 DS [-WA] FS =0018 00c09300 DPL=0 DS [-WA] GS =0018 00c09300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS64-busy GDT= 00844c80 0047 IDT= 9c01fd60 021f CR0=8033 CR2= CR3=0008 CR4=0660 DR0= DR1= DR2= DR3= DR6=0ff0
Re: [edk2] Issue in UNDI driver for INTEL GIGABIT CT DESKTOP ADAPTER
Is it true that Intel Gigabit CT Desktop Adapter exists on ARM-based gadget? On 05.12.2013, at 18:42, Olivier Martin wrote: You should probably try to build for X64 (and EDK2) and see if the driver works to make sure you have not broken anything in your port. From: Shivamurthy Shastri [mailto:shiva.linuxwo...@gmail.com] Sent: 05 December 2013 13:37 To: edk2-devel@lists.sourceforge.net Subject: [edk2] Issue in UNDI driver for INTEL GIGABIT CT DESKTOP ADAPTER Hi, I have downloaded UNDI driver for Intel PCIE card from the link http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=EDK file is gig_pcie_src_4109.zip. I compiled this for ARM platform and EDK2. My board is Intel Gigabit CT Desktop Adapter, which has 8082574L ethernet controller. Any build flag do I need to enable? Because, ethernet controller PHY init is failing. -- Thanks and Regards, Shiva. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] apparent KVM problem with LRET in TianoCore S3 resume trampoline
Small addition -- apologies for the self-followup: On 12/05/13 17:12, Laszlo Ersek wrote: I tried to trace the problem with ftrace, but I didn't get any mentions of em_ret_far(). (Maybe I was looking in the wrong place.) I applied the following small patch (to the original code): diff --git a/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S b/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S index e59fd04..daa4f7e 100644 --- a/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S +++ b/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S @@ -18,8 +18,8 @@ ASM_GLOBAL ASM_PFX(AsmTransferControl) ASM_PFX(AsmTransferControl): # rcx S3WakingVector:DWORD # rdx AcpiLowMemoryBase :DWORD -lea _AsmTransferControl_al_(%rip), %eax -movq $0x28, %r8 +lea AsmTransferControl(%rip), %eax +movq $0x38, %r8 orq %r8, %rax pushq %rax shrd $20, %ecx, %ebx This turns the code right under AsmTransferControl into a working, 64-bit mode loop. (Recall that 0x38 selects a descriptor that has the L (64-bitC) bit set: 0x0038: 0x00AF9B00: Base=0x Limit=0xF Type=0xB (C ER A ) S=0x1 (code/data) DPL=0x0 Present=1 Avail=0 64-bitC=1 D/B=0 LimitGran=0x1 (4KB) ) While this was spinning (I checked the RIP several times with the qemu monitor and it was alternating between a few close values -- ie. not stuck), I ran trace-cmd. The report seems to confirm that the lret is not emulated, because the only lines I'm seeing are: qemu-system-x86-3901 [001] 38939.599663: kvm_exit: reason EXTERNAL_INTERRUPT rip 0x9c75be0a info 0 80ef qemu-system-x86-3901 [001] 38939.599684: kvm_entry:vcpu 0 repeated infinitely. The rip varies between a few close values, 458 rip 0x9c75be04 313 rip 0x9c75be0a 5 rip 0x9c75be17 4 rip 0x9c75be18 3 rip 0x9c75be22 8 rip 0x9c75be28 Thanks again and sorry for the noise. Laszlo -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] ARM UEFI BIOS Trusted firmware
Alok, I agree -- there is value in the modular nature of the PI component approach extending to the ARM trusted firmware environment. For SMM this is supported in the PI spec's SMM core interface specification and in edk2 by the PiSmmCore module and accompanying libraries. Unlike DXE and PEI, the SMM core, at least in name, is IA-specific as it refers to SMM, SMIs, SMRAM, etc. When you look past the names though you can see that the functions it is providing is really architecture independent -- IO protocols, secure memory allocation, protocol management, and handler registration. Given the current IA-specific naming, it would be difficult to recommend that ARM should simply adopt the SMM core architecture for the TZ/EL3/SecureMonitor implementation. Perhaps this should be raised in the PI working group, specifically is the SMM core interface spec really an IA-specific concept or something that should become architecture agnostic? Eugene From: Pant, Alok [mailto:alok.p...@amd.com] Sent: Thursday, December 05, 2013 8:42 AM To: edk2-devel@lists.sourceforge.net; olivier.mar...@arm.com Subject: [edk2] ARM UEFI BIOS Trusted firmware Changing topic.. Hi Oliver, Thanks. I also I have few separate questions wrt to Trusted firmware UEFI ARM code and hope you/others can help answer * It seems there are two direction for SecureMonitor implementation. In one implementation the SEC code (ArmPlatformPkg\Sec\Sec.c) install the secure monitor ( when SEC start in El3) ; In other implementation the Trusted firmware start first install secure monitor (bl31) and launch SEC in El1/2 mode. My question is what is the preferred direction when both are possible? Should secure monitor (bl31) be launched before or during SEC phase? * Historically in x86 implementation the SMM mode hosts various runtime platform BIOS driver for feature such as authentication variable (for secure boot), platform runtime handing handling etc. EDKII has a good framework for SMM kernel and loading various independent SMM driver and interaction among those driver via protocol etc. In ARM based UEFI/Trusted firmware implementation what may be preferred way to deal with such need. Should all those UEFI SMM driver be ported to Trusted firmware which today is in primitive framework compare to SMM EDKII foundation code, or some form of SMM foundation can gel with trusted firmware design to allow independent platform el3 code be developed at independent driver. Curious how others have attempted to solve this problem and if there can be standard way for all of us to adopt here. Before creating yet another method I was hoping to hear from experts on any common ground for such feature implementation Thanks again for all your help and comments -Alok -Original Message- From: Olivier Martin [mailto:olivier.mar...@arm.com] Sent: Wednesday, December 04, 2013 7:40 AM To: tiger...@viatech.com.cnmailto:tiger...@viatech.com.cn; edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net Subject: Re: [edk2] SEC code support big.LITTLE tech? Hi Tiger, The ARM recommendation to manage secondary CPUs (the primary CPU is the CPU that runs UEFI and starts your OS kernel) is to use PSCI (Power State Coordination Interface - http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0022b/index.h tml). PSCI uses SMCs (Secure Memory Calls) to bring up secondary CPUs (CPU_UP / CPU_DOWN). This code runs in Secure World while UEFI runs in Non-Secure World. For the story... I started to implement PSCI support in Tianocore source code (in ArmPlatformPkg/Sec). But the EDK2 framework (PCD/Library/INF/FDF etc) had made the code quite hard to maintain. So, I wrote a new secure firmware framework project to handle this support. This firmware is not Open Source (available in binary format for TC2 only). A new project has been started by ARM Ltd last month. It is an Open Source implementation of the Trusted/Secure Firmware: https://github.com/ARM-software/arm-trusted-firmware Unfortunately at this stage, 32bit is not supported (only AArch64 is supported). And as far as I know there is no plan to add 32bit support by ARM Ltd in the short term. The current ArmPlatformPkg/Sec has support to hold the secondary cores in WFI. But it does not support PSCI. The current support might be sufficient enough for you at this stage. Thanks, Olivier -Original Message- From: tiger...@viatech.com.cnmailto:tiger...@viatech.com.cn [mailto:tiger...@viatech.com.cn] Sent: 04 December 2013 01:51 To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net Cc: Olivier Martin Subject: [edk2] SEC code support big.LITTLE tech? Hi, Oliver: Does current ArmPlatformPackage's sec code support big.LITTLE tech? Such as : An ARM SOC --- with 4 Cores Cortex-A15, 4 Cores Cortex-A7 So, if sec code support big.LITTLE tech, how does it let one core as boot strap cpu, others go into wfe(or
Re: [edk2] ARM UEFI BIOS Trusted firmware
Eugene - One of the issues for the SMM specification and TZ is the single-threaded nature. While most of ARM's TrustZone infrastructure can be mapped easily to SMM, the possibility of having cores in TZ and out of TZ simultaneously, or more than one core in TZ at the same time raises some interesting issues (resource contention, etc.) Tim From: Cohen, Eugene [mailto:eug...@hp.com] Sent: Thursday, December 05, 2013 9:29 AM To: edk2-devel@lists.sourceforge.net; olivier.mar...@arm.com Subject: Re: [edk2] ARM UEFI BIOS Trusted firmware Alok, I agree -- there is value in the modular nature of the PI component approach extending to the ARM trusted firmware environment. For SMM this is supported in the PI spec's SMM core interface specification and in edk2 by the PiSmmCore module and accompanying libraries. Unlike DXE and PEI, the SMM core, at least in name, is IA-specific as it refers to SMM, SMIs, SMRAM, etc. When you look past the names though you can see that the functions it is providing is really architecture independent -- IO protocols, secure memory allocation, protocol management, and handler registration. Given the current IA-specific naming, it would be difficult to recommend that ARM should simply adopt the SMM core architecture for the TZ/EL3/SecureMonitor implementation. Perhaps this should be raised in the PI working group, specifically is the SMM core interface spec really an IA-specific concept or something that should become architecture agnostic? Eugene From: Pant, Alok [mailto:alok.p...@amd.com] Sent: Thursday, December 05, 2013 8:42 AM To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net; olivier.mar...@arm.commailto:olivier.mar...@arm.com Subject: [edk2] ARM UEFI BIOS Trusted firmware Changing topic.. Hi Oliver, Thanks. I also I have few separate questions wrt to Trusted firmware UEFI ARM code and hope you/others can help answer * It seems there are two direction for SecureMonitor implementation. In one implementation the SEC code (ArmPlatformPkg\Sec\Sec.c) install the secure monitor ( when SEC start in El3) ; In other implementation the Trusted firmware start first install secure monitor (bl31) and launch SEC in El1/2 mode. My question is what is the preferred direction when both are possible? Should secure monitor (bl31) be launched before or during SEC phase? * Historically in x86 implementation the SMM mode hosts various runtime platform BIOS driver for feature such as authentication variable (for secure boot), platform runtime handing handling etc. EDKII has a good framework for SMM kernel and loading various independent SMM driver and interaction among those driver via protocol etc. In ARM based UEFI/Trusted firmware implementation what may be preferred way to deal with such need. Should all those UEFI SMM driver be ported to Trusted firmware which today is in primitive framework compare to SMM EDKII foundation code, or some form of SMM foundation can gel with trusted firmware design to allow independent platform el3 code be developed at independent driver. Curious how others have attempted to solve this problem and if there can be standard way for all of us to adopt here. Before creating yet another method I was hoping to hear from experts on any common ground for such feature implementation Thanks again for all your help and comments -Alok -Original Message- From: Olivier Martin [mailto:olivier.mar...@arm.com] Sent: Wednesday, December 04, 2013 7:40 AM To: tiger...@viatech.com.cnmailto:tiger...@viatech.com.cn; edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net Subject: Re: [edk2] SEC code support big.LITTLE tech? Hi Tiger, The ARM recommendation to manage secondary CPUs (the primary CPU is the CPU that runs UEFI and starts your OS kernel) is to use PSCI (Power State Coordination Interface - http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0022b/index.h tml). PSCI uses SMCs (Secure Memory Calls) to bring up secondary CPUs (CPU_UP / CPU_DOWN). This code runs in Secure World while UEFI runs in Non-Secure World. For the story... I started to implement PSCI support in Tianocore source code (in ArmPlatformPkg/Sec). But the EDK2 framework (PCD/Library/INF/FDF etc) had made the code quite hard to maintain. So, I wrote a new secure firmware framework project to handle this support. This firmware is not Open Source (available in binary format for TC2 only). A new project has been started by ARM Ltd last month. It is an Open Source implementation of the Trusted/Secure Firmware: https://github.com/ARM-software/arm-trusted-firmware Unfortunately at this stage, 32bit is not supported (only AArch64 is supported). And as far as I know there is no plan to add 32bit support by ARM Ltd in the short term. The current ArmPlatformPkg/Sec has support to hold the secondary cores in WFI. But it does not support PSCI. The current support might be sufficient
Re: [edk2] apparent KVM problem with LRET in TianoCore S3 resume trampoline
Il 05/12/2013 17:12, Laszlo Ersek ha scritto: Hi, I'm working on S3 suspend/resume in OVMF. The problem is that I'm getting an unexpected guest reboot for code (LRET) that works on physical hardware. I tried to trace the problem with ftrace, but I didn't get any mentions of em_ret_far(). (Maybe I was looking in the wrong place.) What does ftrace say anyway? Please find the the assembly-language trampoline that is invoked (in 64-bit mode) with the 16-bit real mode resume vector placed in rcx (EFIAPI calling convention). The excerpt is from the edk2 tree, MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S. Can you send me a pointer to a git tree or, even better, an OVMF.fd file + instructions on how to trigger the problem? - shared properties: Base=0x Limit=0xF Type=0xB (C ER A ) S=0x1 (code/data) DPL=0x0 Present=1 Avail=0 LimitGran=0x1 (4KB) - different properties: 0x0010: 0x00CF9B00: 64-bitC=0 D/B=1 works 0x0028: 0x008F9B00: 64-bitC=0 D/B=0 reboots 0x0038: 0x00AF9B00: 64-bitC=1 D/B=0 works That is: - if I let 64-bit mode execution enabled (64-bitC=1, desc 0x38), the lret works. - If I switch to compat mode execution (64-bitC=0, desc 0x10), *and* keep the default addr/op size 32 bits, the lret still works. Perhaps you could try switching to 32-bit mode first, then disable paging, then jump to 16-bit mode. Like this (untested): diff --git a/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S b/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S index e59fd04..d1cac9d 100644 --- a/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S +++ b/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S @@ -19,7 +19,7 @@ ASM_PFX(AsmTransferControl): # rcx S3WakingVector:DWORD # rdx AcpiLowMemoryBase :DWORD lea _AsmTransferControl_al_(%rip), %eax -movq $0x28, %r8 +movq $0x10, %r8 orq %r8, %rax pushq %rax shrd $20, %ecx, %ebx @@ -28,24 +28,32 @@ ASM_PFX(AsmTransferControl): movl %ebx, jmp_addr(%rip) lret _AsmTransferControl_al_: +# Old SS should still be okay? +addl _AsmTransferControl_al_0001-_AsmTransferControl_al_, %eax +pushl $0x28 +pushl %eax +movq %cr0, %rax +movq %cr4, %rbx +andl $0x7fff, %eax +andb $0xdf, %bl +movq %rax, %cr0 # sets EFER.LMA=0 too, so says Intel +movl $0x0c080, %ecx +rdmsr +andb $0xfe, %ah # set EFER.LME=0 +wrmsr +movq %rbx, %cr4 # only now set CR4.PAE=0 +lret +_AsmTransferControl_al_0001: .byte0x0b8, 0x30, 0 # mov ax, 30h as selector movl %eax, %ds movl %eax, %es movl %eax, %fs movl %eax, %gs movl %eax, %ss -movq %cr0, %rax -movq %cr4, %rbx -.byte0x66 -andl $0x7ffe, %eax -andb $0xdf, %bl -movq %rax, %cr0 -.byte0x66 -movl $0x0c080, %ecx -rdmsr -andb $0xfe, %ah -wrmsr -movq %rbx, %cr4 +movl %cr0, %rax# Get control register 0 +.byte 0x66 +.byte 0x83,0xe0,0xfe# andeax, 0fffeh ; Clear PE bit (bit #0) +.byte 0xf,0x22,0xc0 # movcr0, eax ; Activate real mode - If I switch to compat mode execution (64-bitC=0, desc 0x28), but also change the default addr/op size to 16-bits, then the lret reboots the guest in KVM (but works on physical hardware). Did you try this on physical hardware, or just assumed that? :) Paolo -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] ARM UEFI BIOS Trusted firmware
Tim- Not sure if this helps, but recall that in PI1.2.1 we introduced concept of # of CPU's in SMM can be # of CPU's in platform w/ M731 NumberOfCpus clarification, so PI1.2.1+ can support models of some inside/some outside of this alternate CPU mode. So I think your point on 'in TZ and out of TZ simultaneously' can be supported by the PI DXE SMM software model (replace TZ w SMM in that quote). Vincent From: Tim Lewis [mailto:tim.le...@insyde.com] Sent: Thursday, December 05, 2013 9:39 AM To: edk2-devel@lists.sourceforge.net; olivier.mar...@arm.com Subject: Re: [edk2] ARM UEFI BIOS Trusted firmware Eugene - One of the issues for the SMM specification and TZ is the single-threaded nature. While most of ARM's TrustZone infrastructure can be mapped easily to SMM, the possibility of having cores in TZ and out of TZ simultaneously, or more than one core in TZ at the same time raises some interesting issues (resource contention, etc.) Tim From: Cohen, Eugene [mailto:eug...@hp.com] Sent: Thursday, December 05, 2013 9:29 AM To: edk2-devel@lists.sourceforge.net; olivier.mar...@arm.com Subject: Re: [edk2] ARM UEFI BIOS Trusted firmware Alok, I agree -- there is value in the modular nature of the PI component approach extending to the ARM trusted firmware environment. For SMM this is supported in the PI spec's SMM core interface specification and in edk2 by the PiSmmCore module and accompanying libraries. Unlike DXE and PEI, the SMM core, at least in name, is IA-specific as it refers to SMM, SMIs, SMRAM, etc. When you look past the names though you can see that the functions it is providing is really architecture independent -- IO protocols, secure memory allocation, protocol management, and handler registration. Given the current IA-specific naming, it would be difficult to recommend that ARM should simply adopt the SMM core architecture for the TZ/EL3/SecureMonitor implementation. Perhaps this should be raised in the PI working group, specifically is the SMM core interface spec really an IA-specific concept or something that should become architecture agnostic? Eugene From: Pant, Alok [mailto:alok.p...@amd.com] Sent: Thursday, December 05, 2013 8:42 AM To: edk2-devel@lists.sourceforge.net; olivier.mar...@arm.com Subject: [edk2] ARM UEFI BIOS Trusted firmware Changing topic.. Hi Oliver, Thanks. I also I have few separate questions wrt to Trusted firmware UEFI ARM code and hope you/others can help answer . It seems there are two direction for SecureMonitor implementation. In one implementation the SEC code (ArmPlatformPkg\Sec\Sec.c) install the secure monitor ( when SEC start in El3) ; In other implementation the Trusted firmware start first install secure monitor (bl31) and launch SEC in El1/2 mode. My question is what is the preferred direction when both are possible? Should secure monitor (bl31) be launched before or during SEC phase? . Historically in x86 implementation the SMM mode hosts various runtime platform BIOS driver for feature such as authentication variable (for secure boot), platform runtime handing handling etc. EDKII has a good framework for SMM kernel and loading various independent SMM driver and interaction among those driver via protocol etc. In ARM based UEFI/Trusted firmware implementation what may be preferred way to deal with such need. Should all those UEFI SMM driver be ported to Trusted firmware which today is in primitive framework compare to SMM EDKII foundation code, or some form of SMM foundation can gel with trusted firmware design to allow independent platform el3 code be developed at independent driver. Curious how others have attempted to solve this problem and if there can be standard way for all of us to adopt here. Before creating yet another method I was hoping to hear from experts on any common ground for such feature implementation Thanks again for all your help and comments -Alok -Original Message- From: Olivier Martin [mailto:olivier.mar...@arm.com] Sent: Wednesday, December 04, 2013 7:40 AM To: tiger...@viatech.com.cn; edk2-devel@lists.sourceforge.net Subject: Re: [edk2] SEC code support big.LITTLE tech? Hi Tiger, The ARM recommendation to manage secondary CPUs (the primary CPU is the CPU that runs UEFI and starts your OS kernel) is to use PSCI (Power State Coordination Interface - http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0022b/index.h tml). PSCI uses SMCs (Secure Memory Calls) to bring up secondary CPUs (CPU_UP / CPU_DOWN). This code runs in Secure World while UEFI runs in Non-Secure World. For the story... I started to implement PSCI support in Tianocore source code (in ArmPlatformPkg/Sec). But the EDK2 framework (PCD/Library/INF/FDF etc) had made the code quite hard to maintain. So, I wrote a new secure firmware framework project to handle this support. This firmware is not Open Source (available in binary format for
Re: [edk2] ARM UEFI BIOS Trusted firmware
Vincent - But the multiple in-TZ cores is problematic currently. There is no concept of multiple stacks, or multiple copies of SMST (consider the CurrentCpu field). Also, there is no concept of mutexes, or yielding for these cores, a problem in high reliability systems. Many ARM configurations also allow a separate, lower-privileged, 3rd party OS to be running on the secure side The in and out of TZ problem occurs if there are hardware resources which must be shared between TZ and non-TZ. This is a common case on PC (CMOS, EC or SMBus). In the ARM world it happens when a TZ OS is performing some sort of secure task. An analogous case would be a S3 bug fix workarounds. What happens when the secure OS is performing a secure task, but the other OS asks for a shutdown? Back to ACPI Global Lock? Tim From: Zimmer, Vincent [mailto:vincent.zim...@intel.com] Sent: Thursday, December 05, 2013 10:01 AM To: edk2-devel@lists.sourceforge.net; olivier.mar...@arm.com Subject: Re: [edk2] ARM UEFI BIOS Trusted firmware Tim- Not sure if this helps, but recall that in PI1.2.1 we introduced concept of # of CPU's in SMM can be # of CPU's in platform w/ M731 NumberOfCpus clarification, so PI1.2.1+ can support models of some inside/some outside of this alternate CPU mode. So I think your point on 'in TZ and out of TZ simultaneously' can be supported by the PI DXE SMM software model (replace TZ w SMM in that quote). Vincent From: Tim Lewis [mailto:tim.le...@insyde.com] Sent: Thursday, December 05, 2013 9:39 AM To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net; olivier.mar...@arm.commailto:olivier.mar...@arm.com Subject: Re: [edk2] ARM UEFI BIOS Trusted firmware Eugene - One of the issues for the SMM specification and TZ is the single-threaded nature. While most of ARM's TrustZone infrastructure can be mapped easily to SMM, the possibility of having cores in TZ and out of TZ simultaneously, or more than one core in TZ at the same time raises some interesting issues (resource contention, etc.) Tim From: Cohen, Eugene [mailto:eug...@hp.com] Sent: Thursday, December 05, 2013 9:29 AM To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net; olivier.mar...@arm.commailto:olivier.mar...@arm.com Subject: Re: [edk2] ARM UEFI BIOS Trusted firmware Alok, I agree -- there is value in the modular nature of the PI component approach extending to the ARM trusted firmware environment. For SMM this is supported in the PI spec's SMM core interface specification and in edk2 by the PiSmmCore module and accompanying libraries. Unlike DXE and PEI, the SMM core, at least in name, is IA-specific as it refers to SMM, SMIs, SMRAM, etc. When you look past the names though you can see that the functions it is providing is really architecture independent -- IO protocols, secure memory allocation, protocol management, and handler registration. Given the current IA-specific naming, it would be difficult to recommend that ARM should simply adopt the SMM core architecture for the TZ/EL3/SecureMonitor implementation. Perhaps this should be raised in the PI working group, specifically is the SMM core interface spec really an IA-specific concept or something that should become architecture agnostic? Eugene From: Pant, Alok [mailto:alok.p...@amd.com] Sent: Thursday, December 05, 2013 8:42 AM To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net; olivier.mar...@arm.commailto:olivier.mar...@arm.com Subject: [edk2] ARM UEFI BIOS Trusted firmware Changing topic.. Hi Oliver, Thanks. I also I have few separate questions wrt to Trusted firmware UEFI ARM code and hope you/others can help answer * It seems there are two direction for SecureMonitor implementation. In one implementation the SEC code (ArmPlatformPkg\Sec\Sec.c) install the secure monitor ( when SEC start in El3) ; In other implementation the Trusted firmware start first install secure monitor (bl31) and launch SEC in El1/2 mode. My question is what is the preferred direction when both are possible? Should secure monitor (bl31) be launched before or during SEC phase? * Historically in x86 implementation the SMM mode hosts various runtime platform BIOS driver for feature such as authentication variable (for secure boot), platform runtime handing handling etc. EDKII has a good framework for SMM kernel and loading various independent SMM driver and interaction among those driver via protocol etc. In ARM based UEFI/Trusted firmware implementation what may be preferred way to deal with such need. Should all those UEFI SMM driver be ported to Trusted firmware which today is in primitive framework compare to SMM EDKII foundation code, or some form of SMM foundation can gel with trusted firmware design to allow independent platform el3 code be developed at independent driver. Curious how others have attempted to solve this problem and if there can be standard
Re: [edk2] [Xen-devel] [PATCH v4 0/7] Make OVMF fully working with Xen
On Thu, 2013-12-05 at 11:52 +, Wei Liu wrote: On Sat, Nov 30, 2013 at 03:58:18PM -0800, Jordan Justen wrote: Series Reviewed-by: Jordan Justen jordan.l.jus...@intel.com Some minor issues mentioned in a reply to patch 1. Is there any more concerns regarding this series? All patches have reviewed-by tag now. I was quite clear about Ray's question. Anything else I need to do to get this series merged? It is basically ready to be committed. I just need to find the time to test it building on Visual Studio. -Jordan -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] ARM UEFI BIOS Trusted firmware
Tim: Good point. Yielding and other infrastructure has to be built on top of the basic PI-conformant code. No integral PI spec primitives, I agree. And I am definitely not advocating things that precipitate back-to-the-future usages like ACPI Global Lock which hasn't, err, proven to be most useful in practice. Vincent From: Tim Lewis [mailto:tim.le...@insyde.com] Sent: Thursday, December 05, 2013 10:12 AM To: edk2-devel@lists.sourceforge.net; olivier.mar...@arm.com Subject: Re: [edk2] ARM UEFI BIOS Trusted firmware Vincent - But the multiple in-TZ cores is problematic currently. There is no concept of multiple stacks, or multiple copies of SMST (consider the CurrentCpu field). Also, there is no concept of mutexes, or yielding for these cores, a problem in high reliability systems. Many ARM configurations also allow a separate, lower-privileged, 3rd party OS to be running on the secure side The in and out of TZ problem occurs if there are hardware resources which must be shared between TZ and non-TZ. This is a common case on PC (CMOS, EC or SMBus). In the ARM world it happens when a TZ OS is performing some sort of secure task. An analogous case would be a S3 bug fix workarounds. What happens when the secure OS is performing a secure task, but the other OS asks for a shutdown? Back to ACPI Global Lock? Tim From: Zimmer, Vincent [mailto:vincent.zim...@intel.com] Sent: Thursday, December 05, 2013 10:01 AM To: edk2-devel@lists.sourceforge.net; olivier.mar...@arm.com Subject: Re: [edk2] ARM UEFI BIOS Trusted firmware Tim- Not sure if this helps, but recall that in PI1.2.1 we introduced concept of # of CPU's in SMM can be # of CPU's in platform w/ M731 NumberOfCpus clarification, so PI1.2.1+ can support models of some inside/some outside of this alternate CPU mode. So I think your point on 'in TZ and out of TZ simultaneously' can be supported by the PI DXE SMM software model (replace TZ w SMM in that quote). Vincent From: Tim Lewis [mailto:tim.le...@insyde.com] Sent: Thursday, December 05, 2013 9:39 AM To: edk2-devel@lists.sourceforge.net; olivier.mar...@arm.com Subject: Re: [edk2] ARM UEFI BIOS Trusted firmware Eugene - One of the issues for the SMM specification and TZ is the single-threaded nature. While most of ARM's TrustZone infrastructure can be mapped easily to SMM, the possibility of having cores in TZ and out of TZ simultaneously, or more than one core in TZ at the same time raises some interesting issues (resource contention, etc.) Tim From: Cohen, Eugene [mailto:eug...@hp.com] Sent: Thursday, December 05, 2013 9:29 AM To: edk2-devel@lists.sourceforge.net; olivier.mar...@arm.com Subject: Re: [edk2] ARM UEFI BIOS Trusted firmware Alok, I agree -- there is value in the modular nature of the PI component approach extending to the ARM trusted firmware environment. For SMM this is supported in the PI spec's SMM core interface specification and in edk2 by the PiSmmCore module and accompanying libraries. Unlike DXE and PEI, the SMM core, at least in name, is IA-specific as it refers to SMM, SMIs, SMRAM, etc. When you look past the names though you can see that the functions it is providing is really architecture independent -- IO protocols, secure memory allocation, protocol management, and handler registration. Given the current IA-specific naming, it would be difficult to recommend that ARM should simply adopt the SMM core architecture for the TZ/EL3/SecureMonitor implementation. Perhaps this should be raised in the PI working group, specifically is the SMM core interface spec really an IA-specific concept or something that should become architecture agnostic? Eugene From: Pant, Alok [mailto:alok.p...@amd.com] Sent: Thursday, December 05, 2013 8:42 AM To: edk2-devel@lists.sourceforge.net; olivier.mar...@arm.com Subject: [edk2] ARM UEFI BIOS Trusted firmware Changing topic.. Hi Oliver, Thanks. I also I have few separate questions wrt to Trusted firmware UEFI ARM code and hope you/others can help answer . It seems there are two direction for SecureMonitor implementation. In one implementation the SEC code (ArmPlatformPkg\Sec\Sec.c) install the secure monitor ( when SEC start in El3) ; In other implementation the Trusted firmware start first install secure monitor (bl31) and launch SEC in El1/2 mode. My question is what is the preferred direction when both are possible? Should secure monitor (bl31) be launched before or during SEC phase? . Historically in x86 implementation the SMM mode hosts various runtime platform BIOS driver for feature such as authentication variable (for secure boot), platform runtime handing handling etc. EDKII has a good framework for SMM kernel and loading various independent SMM driver and interaction among those driver via protocol etc. In ARM based UEFI/Trusted firmware implementation what may be preferred way to deal with such need. Should all
Re: [edk2] ARM UEFI BIOS Trusted firmware
Hi Tim Eugene, Thanks for the response. I agree current SMM foundation code gas some IA specific and there are various gotchas around SMM entry/exit (sync core , save restore etc, base protocol), however most of SMM foundation is generic and it provides a nice framework of independent driver and interaction via protocol and use common services; granted the DXE SMMipl role of launching and building initial SMM environment does not mesh well on ARM. In parallel there is separate work on ARM trusted firmware and seems there is no common ground between two. I am very must interested to hear how others are attempting to address such feature porting issue and the direction from industry toward runtime EL3 support (single monolithic TF binary+some proprietary form of RTOS vs. attempt to integrate UEFI SMM with trusted fw core). I am sure I am not the first one stumbling on this question and seeking how others attempted to solve the above and if this a broader issue that need to be further discussed in this forum. Thanks -Alok From: Tim Lewis [mailto:tim.le...@insyde.com] Sent: Thursday, December 05, 2013 11:39 AM To: edk2-devel@lists.sourceforge.net; olivier.mar...@arm.com Subject: Re: [edk2] ARM UEFI BIOS Trusted firmware Eugene - One of the issues for the SMM specification and TZ is the single-threaded nature. While most of ARM's TrustZone infrastructure can be mapped easily to SMM, the possibility of having cores in TZ and out of TZ simultaneously, or more than one core in TZ at the same time raises some interesting issues (resource contention, etc.) Tim From: Cohen, Eugene [mailto:eug...@hp.com] Sent: Thursday, December 05, 2013 9:29 AM To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net; olivier.mar...@arm.commailto:olivier.mar...@arm.com Subject: Re: [edk2] ARM UEFI BIOS Trusted firmware Alok, I agree -- there is value in the modular nature of the PI component approach extending to the ARM trusted firmware environment. For SMM this is supported in the PI spec's SMM core interface specification and in edk2 by the PiSmmCore module and accompanying libraries. Unlike DXE and PEI, the SMM core, at least in name, is IA-specific as it refers to SMM, SMIs, SMRAM, etc. When you look past the names though you can see that the functions it is providing is really architecture independent -- IO protocols, secure memory allocation, protocol management, and handler registration. Given the current IA-specific naming, it would be difficult to recommend that ARM should simply adopt the SMM core architecture for the TZ/EL3/SecureMonitor implementation. Perhaps this should be raised in the PI working group, specifically is the SMM core interface spec really an IA-specific concept or something that should become architecture agnostic? Eugene From: Pant, Alok [mailto:alok.p...@amd.com] Sent: Thursday, December 05, 2013 8:42 AM To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net; olivier.mar...@arm.commailto:olivier.mar...@arm.com Subject: [edk2] ARM UEFI BIOS Trusted firmware Changing topic.. Hi Oliver, Thanks. I also I have few separate questions wrt to Trusted firmware UEFI ARM code and hope you/others can help answer * It seems there are two direction for SecureMonitor implementation. In one implementation the SEC code (ArmPlatformPkg\Sec\Sec.c) install the secure monitor ( when SEC start in El3) ; In other implementation the Trusted firmware start first install secure monitor (bl31) and launch SEC in El1/2 mode. My question is what is the preferred direction when both are possible? Should secure monitor (bl31) be launched before or during SEC phase? * Historically in x86 implementation the SMM mode hosts various runtime platform BIOS driver for feature such as authentication variable (for secure boot), platform runtime handing handling etc. EDKII has a good framework for SMM kernel and loading various independent SMM driver and interaction among those driver via protocol etc. In ARM based UEFI/Trusted firmware implementation what may be preferred way to deal with such need. Should all those UEFI SMM driver be ported to Trusted firmware which today is in primitive framework compare to SMM EDKII foundation code, or some form of SMM foundation can gel with trusted firmware design to allow independent platform el3 code be developed at independent driver. Curious how others have attempted to solve this problem and if there can be standard way for all of us to adopt here. Before creating yet another method I was hoping to hear from experts on any common ground for such feature implementation Thanks again for all your help and comments -Alok -Original Message- From: Olivier Martin [mailto:olivier.mar...@arm.com] Sent: Wednesday, December 04, 2013 7:40 AM To: tiger...@viatech.com.cnmailto:tiger...@viatech.com.cn;
Re: [edk2] apparent KVM problem with LRET in TianoCore S3 resume trampoline
On 12/05/13 18:42, Paolo Bonzini wrote: Il 05/12/2013 17:12, Laszlo Ersek ha scritto: Hi, I'm working on S3 suspend/resume in OVMF. The problem is that I'm getting an unexpected guest reboot for code (LRET) that works on physical hardware. I tried to trace the problem with ftrace, but I didn't get any mentions of em_ret_far(). (Maybe I was looking in the wrong place.) What does ftrace say anyway? (pls. see in the next msg I sent) Please find the the assembly-language trampoline that is invoked (in 64-bit mode) with the 16-bit real mode resume vector placed in rcx (EFIAPI calling convention). The excerpt is from the edk2 tree, MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S. Can you send me a pointer to a git tree or, even better, an OVMF.fd file + instructions on how to trigger the problem? http://people.redhat.com/~lersek/ovmf_s3_lret/ I use a stock F19 guest, with the default systemd target set to multi-user. Then I login as root at the console, and issue pm-suspend. Once the guest is suspended, I type virsh qemu-monitor-command ovmf.f19 --hmp system_wakeup on the host. At this point the guest starts spinning (visible eg. in the virt-manager CPU usage chart), and the OVMF debug log (written to the qemu debug console) is continuously growing. It always takes the same path: selects the S3 boot path due to the 0xFE byte at 0xF in CMOS, progresses to the trampoline, and resets. - shared properties: Base=0x Limit=0xF Type=0xB (C ER A ) S=0x1 (code/data) DPL=0x0 Present=1 Avail=0 LimitGran=0x1 (4KB) - different properties: 0x0010: 0x00CF9B00: 64-bitC=0 D/B=1 works 0x0028: 0x008F9B00: 64-bitC=0 D/B=0 reboots 0x0038: 0x00AF9B00: 64-bitC=1 D/B=0 works That is: - if I let 64-bit mode execution enabled (64-bitC=1, desc 0x38), the lret works. - If I switch to compat mode execution (64-bitC=0, desc 0x10), *and* keep the default addr/op size 32 bits, the lret still works. Perhaps you could try switching to 32-bit mode first, then disable paging, then jump to 16-bit mode. Like this (untested): I had something like this in mind (I even mentioned it on edk2-devel http://thread.gmane.org/gmane.comp.bios.tianocore.devel/5297/focus=5331), but didn't know how to implement it. There are at least 6 factors in play here: - the L bit in the segment descriptor, - the D/B bit in the segment descriptor, - Paging, - Protection Enable, - IA-32e Mode Enable, - PAE. That's (almost) 6! orderings to test :) So thanks a lot for suggesting a patch, I'll try to play with it. diff --git a/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S b/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S index e59fd04..d1cac9d 100644 --- a/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S +++ b/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S @@ -19,7 +19,7 @@ ASM_PFX(AsmTransferControl): # rcx S3WakingVector:DWORD # rdx AcpiLowMemoryBase :DWORD lea _AsmTransferControl_al_(%rip), %eax -movq $0x28, %r8 +movq $0x10, %r8 orq %r8, %rax pushq %rax shrd $20, %ecx, %ebx @@ -28,24 +28,32 @@ ASM_PFX(AsmTransferControl): movl %ebx, jmp_addr(%rip) lret _AsmTransferControl_al_: +# Old SS should still be okay? +addl _AsmTransferControl_al_0001-_AsmTransferControl_al_, %eax +pushl $0x28 +pushl %eax +movq %cr0, %rax +movq %cr4, %rbx +andl $0x7fff, %eax +andb $0xdf, %bl +movq %rax, %cr0 # sets EFER.LMA=0 too, so says Intel +movl $0x0c080, %ecx +rdmsr +andb $0xfe, %ah # set EFER.LME=0 +wrmsr +movq %rbx, %cr4 # only now set CR4.PAE=0 +lret +_AsmTransferControl_al_0001: .byte0x0b8, 0x30, 0 # mov ax, 30h as selector movl %eax, %ds movl %eax, %es movl %eax, %fs movl %eax, %gs movl %eax, %ss -movq %cr0, %rax -movq %cr4, %rbx -.byte0x66 -andl $0x7ffe, %eax -andb $0xdf, %bl -movq %rax, %cr0 -.byte0x66 -movl $0x0c080, %ecx -rdmsr -andb $0xfe, %ah -wrmsr -movq %rbx, %cr4 +movl %cr0, %rax# Get control register 0 +.byte 0x66 +.byte 0x83,0xe0,0xfe# andeax, 0fffeh ; Clear PE bit (bit #0) +.byte 0xf,0x22,0xc0 # movcr0, eax ; Activate real mode - If I switch to compat mode execution (64-bitC=0, desc 0x28), but also change the default addr/op size to 16-bits, then the lret reboots the guest in KVM (but works on physical hardware). Did you try this on physical hardware, or just assumed that? :) I was told on edk2-devel O:) http://thread.gmane.org/gmane.comp.bios.tianocore.devel/5297/focus=5333 Thanks! Laszlo
Re: [edk2] please clarify PcdDxeIplSwitchToLongMode
On 12/05/13 23:09, Jordan Justen wrote: On Wed, Dec 4, 2013 at 10:29 PM, Laszlo Ersek ler...@redhat.com wrote: On 12/05/13 00:21, Yao, Jiewen wrote: Hi Laszlo Thanks for the investigation. Maybe I am wrong, but I would like to point out this piece of code works fine on IA real platform. Thanks for confirming that! I was wondering if it was in active use. MdePkg/Library/BaseLib/X64/Thunk16.S seems to work with OVMF. (And what a lovely piece of assembly code that is! :) Yes, I had found it. Upon seeing it I went to the corner of my room to cry for ten minutes. And I've been hoping people wouldn't mention it on the list as an example :) Maybe it can help uncover a way to make the S3 thunk work too? Maybe :) I found this pearl too: http://wiki.osdev.org/Real_Mode#Switching_from_Protected_Mode_to_Real_Mode Hopefully the latter will help me understand the former... Thanks! Laszlo -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] apparent KVM problem with LRET in TianoCore S3 resume trampoline
On 12/05/13 18:42, Paolo Bonzini wrote: diff --git a/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S b/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S index e59fd04..d1cac9d 100644 --- a/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S +++ b/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S @@ -19,7 +19,7 @@ ASM_PFX(AsmTransferControl): # rcx S3WakingVector:DWORD # rdx AcpiLowMemoryBase :DWORD lea _AsmTransferControl_al_(%rip), %eax -movq $0x28, %r8 +movq $0x10, %r8 orq %r8, %rax pushq %rax shrd $20, %ecx, %ebx @@ -28,24 +28,32 @@ ASM_PFX(AsmTransferControl): movl %ebx, jmp_addr(%rip) lret _AsmTransferControl_al_: +# Old SS should still be okay? +addl _AsmTransferControl_al_0001-_AsmTransferControl_al_, %eax +pushl $0x28 +pushl %eax +movq %cr0, %rax +movq %cr4, %rbx +andl $0x7fff, %eax +andb $0xdf, %bl +movq %rax, %cr0 # sets EFER.LMA=0 too, so says Intel +movl $0x0c080, %ecx +rdmsr +andb $0xfe, %ah # set EFER.LME=0 +wrmsr +movq %rbx, %cr4 # only now set CR4.PAE=0 +lret +_AsmTransferControl_al_0001: .byte0x0b8, 0x30, 0 # mov ax, 30h as selector movl %eax, %ds movl %eax, %es movl %eax, %fs movl %eax, %gs movl %eax, %ss -movq %cr0, %rax -movq %cr4, %rbx -.byte0x66 -andl $0x7ffe, %eax -andb $0xdf, %bl -movq %rax, %cr0 -.byte0x66 -movl $0x0c080, %ecx -rdmsr -andb $0xfe, %ah -wrmsr -movq %rbx, %cr4 +movl %cr0, %rax# Get control register 0 +.byte 0x66 +.byte 0x83,0xe0,0xfe# andeax, 0fffeh ; Clear PE bit (bit #0) +.byte 0xf,0x22,0xc0 # movcr0, eax ; Activate real mode I had to add this incremental patch to get it to compile: diff --git a/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S b/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S index c28df3f..85d2a36 100644 --- a/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S +++ b/MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S @@ -30,8 +30,8 @@ ASM_PFX(AsmTransferControl): _AsmTransferControl_al_: # Old SS should still be okay? addl _AsmTransferControl_al_0001-_AsmTransferControl_al_, %eax -pushl $0x28 -pushl %eax +.byte 0x6a,0x28 # pushl $0x28 ; opnd sz = 32bits in seg 0x10 +.byte 0x50 # pushl %eax movq %cr0, %rax movq %cr4, %rbx andl $0x7fff, %eax @@ -50,7 +50,7 @@ _AsmTransferControl_al_0001: movl %eax, %fs movl %eax, %gs movl %eax, %ss -movl %cr0, %rax# Get control register 0 +.byte 0x0f,0x20,0xc0# movl %cr0, %eax; Get control register 0 .byte 0x66 .byte 0x83,0xe0,0xfe# andeax, 0fffeh ; Clear PE bit (bit #0) .byte 0xf,0x22,0xc0 # movcr0, eax ; Activate real mode The 2nd lret is reached (just before _AsmTransferControl_al_0001), but then the CPU goes off in the woods. For a while it seems to be spinning who knows where, and in 15-20 seconds or so the guest reboots. Does gas support mode switches in one file? I found examples on the net (for nasm I think) where people were thunking to real mode and back to protected mode in a single assembly file, and they could use native mnemonics for each part. (They just switched the assembler's mode in sync with execution modes.) Thanks Laszlo Thanks, Laszlo -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] apparent KVM problem with LRET in TianoCore S3 resume trampoline
On Dec 5, 2013, at 2:38 PM, Laszlo Ersek ler...@redhat.com wrote: Does gas support mode switches in one file? I found examples on the net (for nasm I think) where people were thunking to real mode and back to protected mode in a single assembly file, and they could use native mnemonics for each part. (They just switched the assembler's mode in sync with execution modes.) Unfortunately the llvm assembler does not support 16-bit mode :(, and we try to keep the .S assembly common…. So it is possible, but then we have to add a big #ifdef for llvm/clang to use the .byte hackery to make that work. Given the thrash on these 2 files, maybe it worth doing the GNU native mnemonics version to get things working and then porting that back to llvm after it is stable? I can help with llvm/clang/Xcode related issues and porting. Thanks, Andrew Fish -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] Regading EDK2 as a 2nd stage Boot Loader
Hello. I'm trying to make UEFI image without SEC phase for AArch64. So, Referencing the below link, I modified current ArmVExpress-RTSM-AEMv8Ax4-foundation.dsc file in ArmPlatformPkg/ArmVExpressPkg. http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=ArmPlatformPkg#Case_2:_EDK2_as_a_2nd_stage_Boot_Loader; And when I build, I used -DEDK2_SKIP_PEICORE option. But I encountered some build issues as below. /home/youngmin/edk2_arm/Build/ArmVExpress-RTSM-AEMv8Ax4-foundation/DEBUG_GCC47/AARCH64/ArmPlatformPkg/Library/ArmPlatformStackLib/ArmPlatformStackLib/OUTPUT/ArmPlatformStackLib.lib(ArmPlatformStackLib.obj): In function `ArmPlatformStackSetSecondary': (.text+0x70): undefined reference to `ArmPlatformGetPrimaryCoreMpId' .. make: *** [/home/youngmin/edk2_arm/Build/ArmVExpress-RTSM-AEMv8Ax4-foundation/DEBUG_GCC47/AARCH64/ArmPlatformPkg/PrePi/PeiMPCore/DEBUG/ArmPlatformPrePiMPCore.dll] Error 1 build.py... : error 7000: Failed to execute command make tbuild [/home/youngmin/edk2_arm/Build/ArmVExpress-RTSM-AEMv8Ax4-foundation/DEBUG_GCC47/AARCH64/ArmPlatformPkg/PrePi/PeiMPCore] build.py... : error F002: Failed to build module /home/youngmin/edk2_arm/ArmPlatformPkg/PrePi/PeiMPCore.inf [AARCH64, GCC47, DEBUG] - Failed - Build end time: 09:48:41, Dec.04 2013 Build total time: 00:00:13 In my opinion, this build issue seems to come from ArmPlatformGetPrimaryCoreMpId. There is no ArmPlatformGetPrimaryCoreMpId' function in current ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/AArch64/RTSMHelper.S While there is a ArmPlatformGetPrimaryCoreMpId function in ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/Arm/RTSMHelper.S Do I need to implement ArmPlatformGetPrimaryCoreMpId' into ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/AArch64/RTSMHelper.S ? Please have a look. Thank you all in advanced to. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/HiiDataBaseDxe: Fixed build error 'Statement is unreachable'
Hi Olivier, The patch looks good. Reviewed-by: Eric Dong eric.d...@intel.com Thanks, Eric From: Olivier Martin [mailto:olivier.mar...@arm.com] Sent: Thursday, December 05, 2013 1:54 AM To: Tian, Feng Cc: edk2-devel@lists.sourceforge.net Subject: [edk2] [PATCH] MdeModulePkg/HiiDataBaseDxe: Fixed build error 'Statement is unreachable' Dear MdeModulePkg maintainer, Please find the attached patch that fixes a build issue (build error 'Statement is unreachable'). Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin olivier.mar...@arm.commailto:olivier.mar...@arm.com Regards, Olivier -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/HiiDataBaseDxe: Fixed build error 'Statement is unreachable'
Hi Olivier, Check in patch v14935. Thanks, Eric From: Dong, Eric [mailto:eric.d...@intel.com] Sent: Friday, December 06, 2013 9:55 AM To: edk2-devel@lists.sourceforge.net; Tian, Feng Subject: Re: [edk2] [PATCH] MdeModulePkg/HiiDataBaseDxe: Fixed build error 'Statement is unreachable' Hi Olivier, The patch looks good. Reviewed-by: Eric Dong eric.d...@intel.commailto:eric.d...@intel.com Thanks, Eric From: Olivier Martin [mailto:olivier.mar...@arm.com] Sent: Thursday, December 05, 2013 1:54 AM To: Tian, Feng Cc: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net Subject: [edk2] [PATCH] MdeModulePkg/HiiDataBaseDxe: Fixed build error 'Statement is unreachable' Dear MdeModulePkg maintainer, Please find the attached patch that fixes a build issue (build error 'Statement is unreachable'). Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin olivier.mar...@arm.commailto:olivier.mar...@arm.com Regards, Olivier -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] apparent KVM problem with LRET in TianoCore S3 resume trampoline
On 12/05/13 23:53, Andrew Fish wrote:
On Dec 5, 2013, at 2:38 PM, Laszlo Ersek ler...@redhat.com
mailto:ler...@redhat.com wrote:
Does gas support mode switches in one file? I found examples on the
net (for nasm I think) where people were thunking to real mode and
back to protected mode in a single assembly file, and they could use
native mnemonics for each part. (They just switched the assembler's
mode in sync with execution modes.)
Unfortunately the llvm assembler does not support 16-bit mode :(, and we
try to keep the .S assembly common….
So it is possible, but then we have to add a big #ifdef for llvm/clang
to use the .byte hackery to make that work.
Given the thrash on these 2 files, maybe it worth doing the GNU native
mnemonics version to get things working and then porting that back to
llvm after it is stable? I can help with llvm/clang/Xcode related issues
and porting.
Progress! :)
Please see the attached patches. They are just proof of concept, but I'm
getting aaabbbccc.
And it's not a KVM problem, so I'm removing the KVM list from the
address list. If it would be polite I can send a thread-closer to that
list separately. (Paolo?)
Thanks!
Laszlo
From 9da03de536b0d809c8567a62da89565ddbb570b0 Mon Sep 17 00:00:00 2001
From: Laszlo Ersek ler...@redhat.com
Date: Thu, 5 Dec 2013 17:51:18 +0100
Subject: [PATCH 1/3] S3ResumeBootOs(): debug dump GDT before calling
AsmTransferControl()
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c | 74 +++
1 file changed, 74 insertions(+)
diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
index 6aa3bbc..494592e 100644
--- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
+++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
@@ -546,10 +546,84 @@ S3ResumeBootOs (
);
}
} else {
+IA32_DESCRIPTORDesc;
+IA32_GDT *Entry;
+STATIC CONST CHAR8 * CONST Types[] = {
+ D RO,
+ D RO A,
+ D RW,
+ D RW A,
+ D RO down,
+ D RO down A,
+ D RW down,
+ D RW down A,
+ C EO,
+ C EO A,
+ C ER,
+ C ER A,
+ C EO conf,
+ C EO conf A,
+ C ER conf,
+ C ER conf A
+};
+STATIC CONST CHAR8 * CONST System[] = {
+ system,
+ code/data,
+};
+STATIC CONST CHAR8 * CONST Gran[] = {
+ 1B,
+ 4KB
+};
+
+ZeroMem (Desc, sizeof Desc);
+
//
// 16bit Realmode waking vector
//
DEBUG (( EFI_D_ERROR, Transfer to 16bit OS waking vector - %x\r\n,
(UINTN)Facs-FirmwareWakingVector));
+DEBUG ((DEBUG_VERBOSE, %a: CS=0x%04x DS=0x%04x ES=0x%04x FS=0x%04x
+ GS=0x%04x SS=0x%04x, interrupts %a\n,
+ __FUNCTION__,
+ AsmReadCs(),
+ AsmReadDs(),
+ AsmReadEs(),
+ AsmReadFs(),
+ AsmReadGs(),
+ AsmReadSs(),
+ GetInterruptState () ? enabled : disabled));
+
+AsmReadGdtr (Desc);
+DEBUG ((DEBUG_VERBOSE, %a: Desc.Limit=0x%04x\n, __FUNCTION__,
+ Desc.Limit));
+Entry = (IA32_GDT *) Desc.Base;
+while ((UINTN) Entry Desc.Base + (Desc.Limit + 1)) {
+ DEBUG ((DEBUG_VERBOSE,
+0x%04Lx: 0x%016Lx:
+Base=0x%08x
+Limit=0x%05x
+Type=0x%x (%-11a)
+S=0x%x (%-9a)
+DPL=0x%x
+Present=%d
+Avail=%d
+64-bitC=%d
+D/B=%d
+LimitGran=0x%x (%-3a)\n,
+(UINT64) Entry - Desc.Base, Entry-Uint64,
+Entry-Bits.BaseLow | (Entry-Bits.BaseMid 16) | ((UINT32)
Entry-Bits.BaseHigh 24),
+Entry-Bits.LimitLow | (Entry-Bits.LimitHigh 16),
+Entry-Bits.Type, Types[Entry-Bits.Type],
+Entry-Bits.System, System[Entry-Bits.System],
+Entry-Bits.Dpl,
+Entry-Bits.Present,
+Entry-Bits.Software,
+Entry-Bits.Reserved,
+Entry-Bits.DefaultSize,
+Entry-Bits.Granularity, Gran[Entry-Bits.Granularity]
+));
+ ++Entry;
+}
+
AsmTransferControl (Facs-FirmwareWakingVector, 0x0);
}
--
1.8.3.1
From bf9b478244c3786b044c03b062e0337d0342bebf Mon Sep 17 00:00:00 2001
From: Laszlo Ersek ler...@redhat.com
Date: Thu, 5 Dec 2013 19:45:06 +0100
Subject: [PATCH 2/3] annotate segments and rewrite trampoline naively
Also, 16-bit segments must have a limit granularity of 1 byte, rather than
4 KB. Change those two GDT entries accordingly.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c | 23 -
.../Acpi/BootScriptExecutorDxe/X64/S3Asm.S | 102 +
2 files changed, 106 insertions(+), 19 deletions(-)
diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
index 494592e..97cbb1c 100644
---
Re: [edk2] Issue in UNDI driver for INTEL GIGABIT CT DESKTOP ADAPTER
Yes, the board is PCIe based. I don't have any X64 platform to test it. ARM board has PCIe slot. I want know the build configuration, if any, for the board. The board has 8082574L ethernet chip. The code supports 8082574L chip, but I am not sure if anything I need to disable or enable while compiling. On Thu, Dec 5, 2013 at 11:25 PM, Andrew Fish af...@apple.com wrote: On Dec 5, 2013, at 8:26 AM, Sergey Isakov isakov...@bk.ru wrote: Is it true that Intel Gigabit CT Desktop Adapter exists on ARM-based gadget? PCIe slot? On 05.12.2013, at 18:42, Olivier Martin wrote: You should probably try to build for X64 (and EDK2) and see if the driver works to make sure you have not broken anything in your port. *From:* Shivamurthy Shastri [mailto:shiva.linuxwo...@gmail.comshiva.linuxwo...@gmail.com ] *Sent:* 05 December 2013 13:37 *To:* edk2-devel@lists.sourceforge.net *Subject:* [edk2] Issue in UNDI driver for INTEL GIGABIT CT DESKTOP ADAPTER Hi, I have downloaded UNDI driver for Intel PCIE card from the link http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=EDK file is gig_pcie_src_4109.zip. I compiled this for ARM platform and EDK2. My board is Intel Gigabit CT Desktop Adapter, which has 8082574L ethernet controller. Any build flag do I need to enable? Because, ethernet controller PHY init is failing. -- Thanks and Regards, Shiva. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel -- Thanks and Regards, Shiva. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] Issue in UNDI driver for INTEL GIGABIT CT DESKTOP ADAPTER
HI Shiva, IMHO, typically PHY init functions depends on the firmware running on adapter card and the Option Rom running from adapter card drives the firmware. Since you are running on ARM platform, adapter option rom might not be supported ( check EBC). it might be a reason for your PHY init failing in preboot environment. Thanks Neeraj On Fri, Dec 6, 2013 at 10:12 AM, Shivamurthy Shastri shiva.linuxwo...@gmail.com wrote: Yes, the board is PCIe based. I don't have any X64 platform to test it. ARM board has PCIe slot. I want know the build configuration, if any, for the board. The board has 8082574L ethernet chip. The code supports 8082574L chip, but I am not sure if anything I need to disable or enable while compiling. On Thu, Dec 5, 2013 at 11:25 PM, Andrew Fish af...@apple.com wrote: On Dec 5, 2013, at 8:26 AM, Sergey Isakov isakov...@bk.ru wrote: Is it true that Intel Gigabit CT Desktop Adapter exists on ARM-based gadget? PCIe slot? On 05.12.2013, at 18:42, Olivier Martin wrote: You should probably try to build for X64 (and EDK2) and see if the driver works to make sure you have not broken anything in your port. *From:* Shivamurthy Shastri [mailto:shiva.linuxwo...@gmail.comshiva.linuxwo...@gmail.com ] *Sent:* 05 December 2013 13:37 *To:* edk2-devel@lists.sourceforge.net *Subject:* [edk2] Issue in UNDI driver for INTEL GIGABIT CT DESKTOP ADAPTER Hi, I have downloaded UNDI driver for Intel PCIE card from the link http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=EDK file is gig_pcie_src_4109.zip. I compiled this for ARM platform and EDK2. My board is Intel Gigabit CT Desktop Adapter, which has 8082574L ethernet controller. Any build flag do I need to enable? Because, ethernet controller PHY init is failing. -- Thanks and Regards, Shiva. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel -- Thanks and Regards, Shiva. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel -- Thanks Neeraj -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] Query on SCSI controller
Hi All, Can you please clarify my doubts as below. 1) My SCSI controller has Four physical scsi Ports,my assumption was those ports called as SCSI channel.Is it correct? 2) If the above assumption is correct,Can we say my SCSI adapter is multi-channel adapter? 3) If my SCSI controller support multi-channel ,my SCSI controller driver performs the following : • Scan for SCSI targets on the SCSI channel and create child handles. • Install Device Path Protocol to each child handle. • Install SCSI I/O Protocol to each child handle. • Install I/O abstraction such as the Block I/O Protocol to each child handle. 4) In our EDK2 source code (OptionRomPkg/AtapiPassThruDxe/AtapiPassThru.c) we have sample code [ RegisterAtapiScsiPassThru() ] to install EFI_EXT_SCSI_PASS_THRU_PROTOCOL to IDE channel. Do we have similar code for SCSI channel in our EDK2 source? Thanks Murali.S The contents of this e-mail and any attachment(s) may contain confidential or privileged information for the intended recipient(s). Unintended recipients are prohibited from taking action on the basis of information in this e-mail and using or disseminating the information, and must notify the sender and delete it from their system. LT Infotech will not accept responsibility or liability for the accuracy or completeness of, or the presence of any virus or disabling code in this e-mail * This email and attachments have been scanned for potential proprietary or sensitive information leakage. Websense Data Security, Protecting Your Information from the Inside Out. www.websense.com * -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2-buildtools] ld: duplicate symbol _zzsyn in: antlr.o err.o
Michael,
These changes seem to work for me. Note gcc is just a wrapper for clang at this
point. This TOT as of today in the edk2 repo.
A UINT64 can not be 0, and I suppressed some warnings. There was also some
bogus C++ code that needed a little help.
~/work/edk2/BaseToolssvn diff
Index: Source/C/GenVtf/GenVtf.c
===
--- Source/C/GenVtf/GenVtf.c(revision 14932)
+++ Source/C/GenVtf/GenVtf.c(working copy)
@@ -1722,7 +1722,7 @@
--*/
{
- if ((BaseAddress = 0) (FwVolSize 0x40) ((BaseAddress + FwVolSize) %
8 == 0)) {
+ if ((FwVolSize 0x40) ((BaseAddress + FwVolSize) % 8 == 0)) {
return EFI_SUCCESS;
}
Index: Source/C/Makefiles/header.makefile
===
--- Source/C/Makefiles/header.makefile (revision 14932)
+++ Source/C/Makefiles/header.makefile (working copy)
@@ -41,7 +41,7 @@
INCLUDE = $(TOOL_INCLUDE) -I $(MAKEROOT) -I $(MAKEROOT)/Include/Common -I
$(MAKEROOT)/Include/ -I $(MAKEROOT)/Include/IndustryStandard -I
$(MAKEROOT)/Common/ -I .. -I . $(ARCH_INCLUDE)
CPPFLAGS = $(INCLUDE)
-CFLAGS = -MD -fshort-wchar -fno-strict-aliasing -fno-merge-constants -nostdlib
-Wall -Werror -c -g
+CFLAGS = -MD -fshort-wchar -fno-strict-aliasing -nostdlib -Wall -Werror
-Wno-self-assign -Wno-deprecated-declarations -c -g
LFLAGS =
ifeq ($(ARCH), IA32)
Index: Source/C/VfrCompile/VfrFormPkg.cpp
===
--- Source/C/VfrCompile/VfrFormPkg.cpp (revision 14932)
+++ Source/C/VfrCompile/VfrFormPkg.cpp (working copy)
@@ -95,7 +95,7 @@
}
CFormPkg::CFormPkg (
- IN UINT32 BufferSize = 4096
+ IN UINT32 BufferSize
)
{
CHAR8 *BufferStart;
Index: Source/C/VfrCompile/VfrFormPkg.h
===
--- Source/C/VfrCompile/VfrFormPkg.h(revision 14932)
+++ Source/C/VfrCompile/VfrFormPkg.h(working copy)
@@ -124,7 +124,7 @@
SPendingAssign *PendingAssignList;
public:
- CFormPkg (IN UINT32 BufferSize);
+ CFormPkg (IN UINT32 BufferSize = 4096);
~CFormPkg ();
CHAR8 * IfrBinBufferGet (IN UINT32);
~/work/edk2/BaseToolsgcc -v
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.2
Thread model: posix
On Dec 5, 2013, at 10:33 AM, Andrew Fish af...@apple.com wrote:
On Dec 5, 2013, at 9:51 AM, Michael Berman michael.ber...@tidalscale.com
wrote:
Hello,
I am trying to build the base tools on OSX Mavericks with Xcode version
5.0.2.
The cc —version is:
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix
I got passed a few initial issues by invoking the build with:
C_INCLUDE_PATH=../h:../support/set make -C edk2/BaseTools
CFLAGS=-Qunused-arguments
Unfortunately, I now bump into an ld error: duplicate symbol _zzsyn in:
antlr.o err.o
Before I jump into antlr.c and err.c, I was hoping someone could perhaps
point me at the recipe for building on current OSX.
I’ll take a look when I get a chance.
I had to add -Wno-self-assign -Wno-deprecated-declarations to turn off some
warnings. And I also seem to remember there is a C++ bug in the code.
Thanks,
Andrew Fish
TIA,
Michael
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___
edk2-buildtools-devel mailing list
edk2-buildtools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-buildtools-devel
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___
edk2-buildtools-devel mailing list
edk2-buildtools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-buildtools-devel
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___
edk2-buildtools-devel mailing list
edk2-buildtools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-buildtools-devel
