This patch fixed this reported issue, also compatible with old format.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong mailto:eric.d...@intel.com>>
Thanks,
Eric
From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Tuesday, July 22, 2014 8:56 AM
To: edk2-devel@lists
Hi,
I don't know what is Hyper-V but if you have no SimplePointerProtocol then you
have to install it by loading additional Dxe driver like
edk2/MdeModulePkg/Bus/Usb/UsbMouseDxe
Hope it helps,
Sergey
On 24.07.2014, at 9:06, Thomas Rognon wrote:
> Does anyone know how to capture pointer input in
Il 24/06/2014 11:55, Paolo Bonzini ha scritto:
> As long as $EDK_TOOLS_PATH is properly set, the BaseTools/ directory
> is not necessary in the workspace. The BuildEnv file itself suggests
> setting the variable if BaseTools/ is not available.
>
> However, this only works if the user also sets $W
Does anyone know how to capture pointer input in Hyper-V? Is this feature
not possible yet? When I do a 'dh' from the shell, there are no simple or
absolute pointer protocols. I'm hoping the answer isn't 'Integration
Services for UEFI' which doesn't exist. Thanks for any insight.
Thomas Rognon
---
Il 04/07/2014 10:20, Paolo Bonzini ha scritto:
> Ok to apply the patches, since they work for all packaging scenarios?
Ping?
Paolo
> Paolo
--
Want fast and easy access to all the code in your enterprise? Index and
sea
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chen Fan
---
IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c | 2 ++
IntelFrameworkModulePkg/Library/GenericBdsLib/BdsMisc.c | 4
2 files changed, 6 insertions(+)
diff --git a/IntelFrameworkModulePkg/Library/Gene
Jordan:
I have three comments.
1) BuildRule step "cd $(OUTPUT_DIR)(+)${s_dir}" is required? Nasm may not have
the limitation on the execution path.
2) BuildRule "$(NASM)" -I${s_path}(+) $(NASMB_FLAGS) -o $dst
${d_path}(+)${s_base}.iii. I suggest to add "-l ${d_path}(+)${s_base}.lst" to
create
Hi Folks,
The following help content shows proposed changes to the edksetup.bat script in
the edk2 project. While these changes currently focus on the Windows build
environment, the *NIX edksetup.sh scripts can also be modified in the future to
provide similar functionality with most of the sam
Larry,
Looks good.
Reviewed-by: Michael Kinney
mailto:michael.d.kin...@intel.com>>
Mike
From: Hauch, Larry [mailto:larry.ha...@intel.com]
Sent: Wednesday, July 23, 2014 2:38 PM
To: edk2-buildtools-de...@lists.sourceforge.net;
edk2-devel@lists.sourceforge.net
Subject: Re: [edk2-buildtools] [Re
Hi Folks,
There is one other impact in this change.
The two Arm CompilerIntrinsicLib.lib files in the Win32/Arm/DEBUG_RVCT31 and
Win32/Arm/RELEASE_RVCT31 directories are not created by the build server, nor
by the standard Windows BaseTools build process.
These to libraries were committed in 2009
Jordan,
Yes. We can clean this up later.
Thanks,
Mike
-Original Message-
From: Jordan Justen [mailto:jljus...@gmail.com]
Sent: Wednesday, July 23, 2014 2:23 PM
To: Kinney, Michael D; edk2-devel@lists.sourceforge.net
Cc: edk2-buildtools-de...@lists.sourceforge.net
Subject: Re: [edk2-bu
On 2014-07-23 13:44:55, Kinney, Michael D wrote:
> Can we get the NASM related build rules to add the include paths,
> instead of having to use [BuildOptions] in INF?
Yes, I should look at if the build rule can add includes.
Unfortunately, this won't help this situation. Well, unless we think
it
Jordan,
Can we get the NASM related build rules to add the include paths, instead of
having to use [BuildOptions] in INF?
Thanks,
Mike
-Original Message-
From: Jordan Justen [mailto:jordan.l.jus...@intel.com]
Sent: Wednesday, July 23, 2014 1:18 PM
To: edk2-devel@lists.sourceforge.net
Hi Folks,
I have attached two patches for review that will complete task item 3 from the
"Proposal to retire edk2-buildtools subproject".
3) Delete Win32 binaries from EDK II BaseTools and replace with an SVN extern.
a. Default will continue to pull Win32 binaries
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen
---
OvmfPkg/OvmfPkgIa32.dsc| 2 ++
OvmfPkg/OvmfPkgIa32.fdf| 6 +++---
OvmfPkg/OvmfPkgIa32X64.dsc | 2 ++
OvmfPkg/OvmfPkgIa32X64.fdf | 6 +++---
OvmfPkg/OvmfPkgX64.dsc | 2 ++
OvmfPkg/OvmfPkgX64.fdf
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen
---
OvmfPkg/ResetVector/Bin/ResetVector.inf | 29
OvmfPkg/ResetVector/Bin/ResetVector.x64.raw | Bin 628 -> 0 bytes
OvmfPkg/ResetVector/Build.py| 58
v2:
* Use EDK II tool name of NASMB rather than NASMBIN
* Use EDK II extension of .nasmb rather than .nasmbin
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen
---
BaseTools/Conf/build_rule.template | 17 +
BaseTools/Conf/tools_def.template |
Using NASM we build OVMF's ResetVector as part of the EDK II build
process.
v2:
* Use EDK II extension of .nasmb rather than .nasmbin
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen
---
OvmfPkg/ResetVector/ResetVector.inf | 37
OvmfPk
Previously, we would build the page tables in
Tools/FixupForRawSection.py.
In order to let NASM build VTF0 from source during the EDK II build
process, we need to move this into the VTF0 NASM code.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen
---
.../Rese
This implements the older VTF ResetVector code often used on EDK II
IA32 & X64 platforms.
This VTF requires build time fixups in order to find the SEC entry
point. The BaseTools GenFv tool has code that patches the jump target
of the reset vector code to match the entry point of the SEC image in
t
Using NASM we build VTF0 as part of the EDK II build process.
v2:
* Use EDK II extension of .nasmb rather than .nasmbin
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen
---
UefiCpuPkg/ResetVector/Vtf0/Build.py| 2 +-
UefiCpuPkg/ResetVector/Vtf0/
These patches are available in the 'nasm-vtf-v2' branch of the git repo
at https://github.com/jljusten/edk2.
The web page for this branch also provides a .zip download (see link
on right hand side of page):
https://github.com/jljusten/edk2/tree/nasm-vtf-v2
Jordan Justen (7):
BaseTools: Add rule
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen
---
OvmfPkg/build.sh | 39 +++
1 file changed, 31 insertions(+), 8 deletions(-)
diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh
index c3cc72e..9207eae 100755
--- a/OvmfPkg/bu
On Jul 23, 2014, at 12:07 PM, Varad Gautam wrote:
> On Thu, Jul 24, 2014 at 12:20 AM, Andrew Fish wrote:
>
>> Sorry so I’m confused. What is the issue you are seeing? Why is PcdGet32()
>> returning 0 and not the fixed PCD value?
>>
>> Thanks,
>>
>> Andrew Fish
>
> The problem is that even
On Thu, Jul 24, 2014 at 12:20 AM, Andrew Fish wrote:
> Sorry so I’m confused. What is the issue you are seeing? Why is PcdGet32()
> returning 0 and not the fixed PCD value?
>
> Thanks,
>
> Andrew Fish
The problem is that even though the PCDs are set to right value in the
AutoGen.h files
and in
On Jul 23, 2014, at 11:44 AM, Varad Gautam wrote:
> On Wed, Jul 23, 2014 at 11:39 PM, Andrew Fish wrote:
>
>> The code is calling LibPcdGet32() for the FixedAtBuild PCD?
>
> The execution never comes to calling LibPcdGet32(), for either BasePcdLibNull
> or PcdLib.
>
Sorry so I’m confused. W
On Jul 23, 2014, at 1:40 AM, Long, Qin wrote:
> Hi, Andrew,
>
> You are right. The current IA32 assembly codes (SysCall/IA32/) in CryptoPkg
> is dead, and no real symbol link for final module. The original check-in is
> to resolve some link issues for mathematic operations in OpenSSL codes.
On Wed, Jul 23, 2014 at 11:39 PM, Andrew Fish wrote:
> The code is calling LibPcdGet32() for the FixedAtBuild PCD?
The execution never comes to calling LibPcdGet32(), for either BasePcdLibNull
or PcdLib.
Thanks,
Varad
---
On Jul 23, 2014, at 10:58 AM, Varad Gautam wrote:
> What is the AutoGen.* for the library?
>
> Thanks,
>
> Andrew Fish
>
>
> Do you mean the platform library? Library/Am335xLib/AutoGen.h shows
>
> #define _PCD_TOKEN_PcdFvBaseAddress 8U
> extern const UINT32 _gPcd_FixedAtBuild_PcdFvBaseAdd
>
> What is the AutoGen.* for the library?
>
> Thanks,
>
> Andrew Fish
>
>
Do you mean the platform library? Library/Am335xLib/AutoGen.h shows
#define _PCD_TOKEN_PcdFvBaseAddress 8U
extern const UINT32 _gPcd_FixedAtBuild_PcdFvBaseAddress;
#define _PCD_GET_MODE_32_PcdFvBaseAddress
_gPcd_FixedAtBui
On Jul 23, 2014, at 9:56 AM, Varad Gautam wrote:
>
> On Wed, Jul 23, 2014 at 9:43 PM, Andrew Fish wrote:
> > What form do get for _PCD_GET_MODE_*_PcdFvBaseAddress in the AutoGen.h? That
> > is the real issue.
> >
> > https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Include/Library/PcdLib.
UDK2010.SR1.UP1.P1 from July 2013 is the last UEFK 2.3.1 snapshot for UDK2010.
http://tianocore.sourceforge.net/wiki/Previous_UDK2010_Releases
There are a number of security patches between then and UDK2014, so a more
recent version is recommended.
Thanks ... br
---
Brian Richardson -- brian.ri
On Wed, Jul 23, 2014 at 9:43 PM, Andrew Fish wrote:
> What form do get for _PCD_GET_MODE_*_PcdFvBaseAddress in the AutoGen.h?
That
> is the real issue.
>
>
https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Include/Library/PcdLib.h
>
> #define PcdGet8(TokenName) _PCD_GET_MODE_8
On Jul 23, 2014, at 5:36 AM, Laszlo Ersek wrote:
> On 07/23/14 13:34, Varad Gautam wrote:
>> Hi, I am working on the BeagleBoneBlack port for EDK2 and am facing an
>> issue with
>> PcdGet(): it always returns `0` no matter what the PCD is set to. However,
>> FixedPcdGet() works fine (I've had to
Hi
Do anyone know if there is option to have a PCD write once variable ?
I want to initialize a platform policy using PCD variable, but I don't want
anyone to overwrite it for
Security reasons.
Thanks
Ram.
The information contained in this message may be confidential and proprietary
to Americ
On 07/23/14 13:34, Varad Gautam wrote:
> Hi, I am working on the BeagleBoneBlack port for EDK2 and am facing an
> issue with
> PcdGet(): it always returns `0` no matter what the PCD is set to. However,
> FixedPcdGet() works fine (I've had to patch edk2 to replace all PcdGet
> calls with
> FixedPcdG
(PS: Repository location:
https://github.com/varadgautam/edk2/tree/BeagleBoneBlack/TexasInstrumentsPkg/BeagleBoneBlackPkg)
On Wed, Jul 23, 2014 at 5:04 PM, Varad Gautam wrote:
> Hi, I am working on the BeagleBoneBlack port for EDK2 and am facing an
> issue with
> PcdGet(): it always returns `0` n
Hi, I am working on the BeagleBoneBlack port for EDK2 and am facing an
issue with
PcdGet(): it always returns `0` no matter what the PCD is set to. However,
FixedPcdGet() works fine (I've had to patch edk2 to replace all PcdGet
calls with
FixedPcdGet to get PrePi working which is a bad idea).
The
Hi, Andrew,
You are right. The current IA32 assembly codes (SysCall/IA32/) in CryptoPkg is
dead, and no real symbol link for final module. The original check-in is to
resolve some link issues for mathematic operations in OpenSSL codes. But these
linking issues was removed when we applied more O
Fixed one memory leak issue in BdsBoot.c
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong mailto:eric.d...@intel.com>>
Thanks,
Eric
BdsBoot.c.patch
Description: BdsBoot.c.patch
--
Want f
40 matches
Mail list logo
