The patch is good. Reviewed-by: Gao, Liming
-Original Message-
From: Olivier Martin [mailto:olivier.mar...@arm.com]
Sent: Thursday, October 30, 2014 10:29 PM
To: Kinney, Michael D
Cc: edk2-devel@lists.sourceforge.net
Subject: [edk2] [PATCH] MdePkg/ProcessorBind.h: Add ARM and AArch64 GCC
Scott:
I agree. And, I also verify this change with CYGGCC on IA32 arch. It could
pass build.
For the change in GenMake.py, it can always use '/' in the generated lst
file, because windows compiler also recognize it.
Last question, have you instruction on how to generate windows base
Hi All,
I am attempting to implement a non-volatile variable storage in an eMMC
device. After about a week of looking around, I have come to the
realization that there is no such feature in edk2.
Is this correct ?
Looking at 'variable' drivers, it seems that the variable storage for both
volatile
Larry:
The patch is good to me. Reviewed-by: Gao, Liming
From: Hauch, Larry [mailto:larry.ha...@intel.com]
Sent: Thursday, October 30, 2014 10:29 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [Patch] Update edksetup.bat to support VS2013
Here's a patch to update edksetup.bat to suppo
On 10/27/2014 1:40 PM, Bruce Cran wrote:
> I have code that uses UefiHandleParsingLib that builds using UDK2014
> but not using the latest UDK2014.SP1 code: it appears that
> UefiHandleParsingLib now depends on
> gEfiShellDynamicCommandProtocolGuid.
>
> Should it be listed as being consumed in Uefi
The following patch can be used
http://permalink.gmane.org/gmane.comp.bios.tianocore.devel/10343
Thanks,
Sandeep
On Thu, Oct 30, 2014 at 2:31 PM, Andrew Fish wrote:
>
> On Oct 30, 2014, at 1:37 PM, Scott Duplichan wrote:
>
> GenFw: ERROR 3000: Invalid
> AArch64: R_AARCH64_CALL26 Need to fixup
As Andrew stated. The BDS in EDKII will spawn the shell based on the PCD of
it's GUID.
Add this to the DSC file for your system if you're using the UEFI Shell.
gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04,
0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68,
SetMemorySpaceCapabilities is a GCD extension introduced in PI 1.3.
It is not in the code base even though PiDxeCis.h states PI 1.3 compliancy.
The information contained in this message may be confidential and proprietary
to American Megatrends, Inc. This communication is intended to be read on
> On Oct 30, 2014, at 2:45 PM, Paulo Alcantara wrote:
>
> OK. That would really clarify things a lot more. So, I am wondering where
> exactly such definitions and/or documentations should go?
>
> About the descriptions of UDF bridge and "conventional" UDF I would point out
> to the OSTA and E
On Oct 30, 2014 10:42 AM, "Andrew Fish" wrote:
>
>
>> On Oct 30, 2014, at 6:07 AM, Paulo Alcantara wrote:
>>
>> Hi,
>>
>> On Thu, October 30, 2014 4:38 am, Tian, Feng wrote:
>>>
>>> Andrew, no exact answer till now. Need dig into it further. I suppose
it
>>> should be something resembling Eltori
I don't have a device that supports FS at this point. i.e. the USB i/f has not
been brought up yet.
Can I 1) put the shell.efi and my shell app in FV and 2) run from there before
I got any storage controller up?
I think the answer to q1 is yes because FDF supports such option. What do I do
wit
> On Oct 30, 2014, at 2:07 PM, Calvin (Hao) Guan wrote:
>
> Thanks Scott.
>
> I saw numerous pkg in EDK2 include Shell.efi in the FDF file which
> supposingly places the Shell in the boot FV. How does the shell get started
> in this case?
>
On a PI based system you can just pass in the corr
> On Oct 30, 2014, at 1:37 PM, Scott Duplichan wrote:
>
> GenFw: ERROR 3000: Invalid
> AArch64: R_AARCH64_CALL26 Need to fixup with addend!.
> GenFw: ERROR 3000: Invalid
> AArch64: R_AARCH64_CALL26 Need to fixup with addend!.
> GenFw: ERROR 3000: Invalid
> AArch64: R_AARCH64_CALL26 Need to fixup
On 10/30/2014 03:10 PM, Scott Duplichan wrote:
> Calvin (Hao) Guan [mailto:hg...@broadcom.com] wrote:
>
> ]Hi,
> ]
> ]FDF file allows EFI application to be placed in firmware volume but I can’t
> ]seem to find what to do with these apps if placed in the FV. Because they are
> ]apps, they won’t be d
Thanks Scott.
I saw numerous pkg in EDK2 include Shell.efi in the FDF file which supposingly
places the Shell in the boot FV. How does the shell get started in this case?
Thanks,
Calvin
-Original Message-
From: Scott Duplichan [mailto:sc...@notabs.org]
Sent: Thursday, October 30, 2014
Brainerd, Mike [mailto:mike.brain...@amd.com] wrote:
]All,
]
]My edk2 code use to build without errors.
]I Updated my cross tools
] FROM: ‘gcc-linaro-aarch64-none-elf-4.8-2013.10_win32’
] TO: ‘gcc-linaro-aarch64-none-elf-4.9-2014.09_win32’
]
]Now I have these errors:
Apparently a kno
Calvin (Hao) Guan [mailto:hg...@broadcom.com] wrote:
]Hi,
]
]FDF file allows EFI application to be placed in firmware volume but I can’t
]seem to find what to do with these apps if placed in the FV. Because they are
]apps, they won’t be dispatched. How do I invoke such an application from the
FV?
All,
My edk2 code use to build without errors.
I Updated my cross tools
FROM: 'gcc-linaro-aarch64-none-elf-4.8-2013.10_win32'
TO: 'gcc-linaro-aarch64-none-elf-4.9-2014.09_win32'
Now I have these errors:
Successfully remade target file
`c:\work\wsc4a29d_0010\Build\STYX\DEBUG_ARMGCC\AARCH64\ArmP
Siyuan,
Thanks, this patch fixed the issue for us. Much appreciated.
Reviewed-by: Eugene Cohen
-Original Message-
From: Fu, Siyuan [mailto:siyuan...@intel.com]
Sent: Wednesday, October 29, 2014 7:58 PM
To: Cohen, Eugene
Cc: edk2-devel@lists.sourceforge.net; Tian, Feng
Subject: RE: Snp
Hi,
FDF file allows EFI application to be placed in firmware volume but I can't
seem to find what to do with these apps if placed in the FV. Because they are
apps, they won't be dispatched. How do I invoke such an application from the FV?
Thanks,
Calvin
-
Olivier,
Thank you for the confirmation and the additional background on the errno=-1
changes. I was a bit "confused" by your second mail which I interpreted as
meaning that you were trying to guarantee that errno was set.
I'll handle getting rid of the "'Status' set but not used" error. Woul
Oliver,
Linaro solved this issue.
I changed the *_ARMLINUXGCC_AARCH64_DLINK_PATH to link with gcc in
Conf/tools_def.txt.
Added -lgcc to linker.
Regards,
Mike
From: Olivier Martin [mailto:olivier.mar...@arm.com]
Sent: Thursday, October 30, 2014 11:50 AM
To: edk2-devel@lists.sourceforge.net
Subjec
Hi Bruce,
The only reason for enabling the visual studio environment (using --nt32) is to
build the Nt32Pkg emulation platform.
We discourage using a VS command prompt window for normal development, so that
new, novice EDK II developers (who may do things like including ) will
not be able to bu
Hi Everyone
I have a question related to the PCI information.
I used to use the following way to get some information from a PCI device:
Status = (*prPciBridgeIoDev)->Pci.Read(*prPciBridgeIoDev,
EfiPciWidthUint8,
If we looked at the code that generates the "undefined reference to
`__trunctfdf2'", we find these lines:
if (flags & LONGDBL) {
_double = (double) GETARG(long double);
} else {
_double = GETARG(double);
}
__trunctfdf2 is actually the equivalent of floa
On 10/27/2014 11:27 AM, Hauch, Larry wrote:
> Actually, ORIGINAL_PATH is not a local variable, but is used as a flag so
> that when Edk2Setup (or edksetup) is run multiple times in the same command
> prompt window, the EDK II BaseTools path does not get added more than one
> time, along with oth
I am not sure who should review this file, but the change looks right to me.
Reviewed-by: Jaben Carsey
From: Hauch, Larry [mailto:larry.ha...@intel.com]
Sent: Thursday, October 30, 2014 7:29 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [Patch] Update edksetup.bat to support VS2013
He
Reviewed-by: Jaben Carsey
(I had noticed it anyways)
-Original Message-
From: Olivier Martin [mailto:olivier.mar...@arm.com]
Sent: Thursday, October 30, 2014 7:30 AM
To: Carsey, Jaben
Cc: edk2-devel@lists.sourceforge.net; Mcdaniel, Daryl
Subject: RE: [PATCH] ShellPkg: Fixed variable set
Sorry, I have just realized I sent the patch to the wrong maintainer.
> -Original Message-
> From: Olivier Martin [mailto:olivier.mar...@arm.com]
> Sent: 30 October 2014 11:55
> To: daryl.mcdan...@intel.com
> Cc: edk2-devel@lists.sourceforge.net; Olivier Martin
> Subject: [PATCH] ShellPkg:
When compiling with Clang, we still use GNU as for the assembler,
so we still need to define the GCC_ASM* macros.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin
---
MdePkg/Include/AArch64/ProcessorBind.h | 4 +++-
MdePkg/Include/Arm/ProcessorBind.h | 4
Here's a patch to update edksetup.bat to support Microsoft Visual Studio 2013
when building the Nt32Pkg emulation platform (enabled using the --nt32 flag).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: lhauch
Cheers,
Larry Hauch
Intel Corporation
SSG, STO, Platform Soft
> On Oct 30, 2014, at 6:07 AM, Paulo Alcantara wrote:
>
> Hi,
>
> On Thu, October 30, 2014 4:38 am, Tian, Feng wrote:
>> Andrew, no exact answer till now. Need dig into it further. I suppose it
>> should be something resembling Eltorito or hard drive device node.
>
> I was thinking in somethi
Hi,
On Thu, October 30, 2014 4:38 am, Tian, Feng wrote:
> Andrew, no exact answer till now. Need dig into it further. I suppose it
> should be something resembling Eltorito or hard drive device node.
I was thinking in something like this:
typedef struct {
EFI_DEVICE_PATH_PROTOCOL Header;
UINT6
This warning/error raised by ARM toolchain prevents to build
the EFI Shell for ARM 32-bit with this toolchain.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin
---
ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c | 3 +--
1 file changed, 1 inserti
Yes, I confirm all these errors where triggered by "set but not used"
warnings.
To answer the inline question about this pattern:
Status = pSocketProtocol->pfnListen ( pSocketProtocol,
backlog,
&errno );
+
PI EFI_PEI_PCD_PPI supports DynamicEx PCD. EDKII PCD_PPI supports Dynamic and
DynamicEx PCD both.
If no Dynamic PCD usage, PI EFI_PEI_PCD_PPI should be enough.
Thanks
Liming
From: tiger...@via-alliance.com [mailto:tiger...@via-alliance.com]
Sent: Thursday, October 30, 2014 3:51 PM
To: edk2-devel@
hi, experts:
I found someone had ever asked this question:
PCD peim will install 2 Ppis:
1. PCD_PPI
2. EFI_PEI_PCD_PPI
It seems only EFI_PEI_PCD_PPI follows PI 1.2 Vol3's related definition.
maybe, we just need to install only EFI_PEI_PCD_PPI.
Is it for compatible with previous old edkii
Andrew, no exact answer till now. Need dig into it further. I suppose it
should be something resembling Eltorito or hard drive device node.
Paulo, in your patch, you only handle BEA01, NSR02 and NSR03 volumes. And from
UDF 2.6 spec, looks like BOOT2 is not supported yet. Then how UDF supports
38 matches
Mail list logo
